prototype implementation for topics #3402

[noahmayr]

This is still a very rough draft, but I think it's at least at a point where it can be played around with to move the discussion further along.

Any feedback is welcome, there's probably some unused code in there from various attempts at keeping commit and view metadata in sync.

First basic implementation of #3402 adding basic crud, revset and commit template integration. There's still a lot to be done though.

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, demos/)
• I have updated the config schema (cli/src/config-schema.json)
• I have added tests to cover my changes

[martinvonz]

there's probably some unused code in there from various attempts at keeping commit and view metadata in sync.

Why do we need to store the information in both places? I would have thought that it would be enough to have it just on the commit. Mercurial ignores topics once a commit has become public, which is the equivalent of immutable for us. I'm guessing (I haven't checked the code) that you're storing topics in the view for quick access to all (?) topics. Maybe we can look up topics only among the mutable commits and get it fast enough?

Also, I noticed in the code that there can be multiple topics per commit. I think Mercurial restricts it to at most one topic per commit. Did it seem like the conclusion on #3402 was that there are use cases for multiple topics? I didn't read all of it.

[PhilipMetzger]

It's off to a good start and all toplevel stuff SGTM. But if we want to have general metadata, we need change the approach.

[necauqua]

I think Mercurial restricts it to at most one topic per commit

I don't think completely copying mercurial was a goal in the first place.
The main discussion was "how much if at all do we want to restrict the idea of a topic being a non-git-but-string-tag on a commit" I think - having only one topic on a commit barely came up if at all.

Other restrictions, like do we want to allow them being disjointed, or for a set of commits under a topic having >1 head, did come up, but imo we could always restrict them later (and I'm also against restrictions anyway).

[yuja]

Perhaps, Topics will have to be a RevsetFilterPredicate, not a resolvable commit ref. Suppose topics are relevant only in mutable commits, queries like heads(topics(..)) wouldn't need a persistent index.

[noahmayr]

Why do we need to store the information in both places?

After some discussion with @PhilipMetzger we came to the conclusion that we can't actually store topics on commits, since a change to a commits topics would equal rebasing the commit meaning you couldn't even remove topics from commits when they become immutable without mutating them.

Mercurial ignores topics once a commit has become public, which is the equivalent of immutable for us.

I'm not sure if that limitation makes sense here, I think the consensus on #3402 was that topics could be how jj represents branches which the git backend would then transparently map to branches so they can be made into PRs. Since we're not limiting branches from being put on immutable commits, I would not put that constraint on topics either.

Did it seem like the conclusion on #3402 was that there are use cases for multiple topics?

Yes, noone has advocated for topics necessarily being exclusive while there have been votes for multiple topics.

I updated the implementation to only store topics in the view. New commits get their parents topics, rewritten commits move their topics to their successor(s) (can be more than one for e.g. jj split).

Restoring the previous topics also only seems to work for jj op restore and not jj undo which I still need to look into.
Also not sure yet whether things like jj new --insert-before would need special handling to inherit the topics of the descendant instead.

[martinvonz]

After some discussion with @PhilipMetzger we came to the conclusion that we can't actually store topics on commits, since a change to a commits topics would equal rebasing the commit meaning you couldn't even remove topics from commits when they become immutable without mutating them.

Why would you want to remove a topic from an immutable commit?

[joyously]

Why would you want to remove a topic from an immutable commit?

If it's called work in progress?

[noahmayr]

Why would you want to remove a topic from an immutable commit?

Well in general changing topics on immutable commits becomes impossible, I'm not sure if we want that limitation.

If we work around that by simply ignoring/hiding topics on immutable commits, they would still resurface when the definition of imutable_heads() changes which seems like unexpected behavior.