design: what should bookmarks do in the longterm

[PhilipMetzger]

This is primarily a design discussion around what bookmarks could or should model.

Unrelated to this PR: I'm not sure what the long-term behavior should be. As history becomes more accessible, I hope people will want to refer to hidden commits (and thus maybe label them) more and more often.

One long-term possibility I like would be to forbid bookmarks from pointing to hidden commits entirely, but have good support for tags pointing to hidden commits (as well as pushing/fetching tags). Perhaps a bookmark could even become a pointer to a change id, while tags would continue pointing to commit ids. This would extend the common use of tags for labeling releases. Obviously, this would require a lot more redesign and work (especially if we also introduce the third concept of topics in the meantime).

In the shorter term, I'd consider allowing jj abandon to keep bookmarks at the hidden commits instead of deleting (or sliding) them. However, I don't think this is urgent; for now people seem to refer to hidden commits quite rarely.

Originally posted by @ilyagr in #5050 (comment)

[PhilipMetzger]

Here was my previous answer to continue the conversation (#5050 (comment)).

Unrelated to this PR: I'm not sure what the long-term behavior should be. As history becomes more accessible, I hope people will want to refer to hidden commits (and thus maybe label them) more and more often.

One long-term possibility I like would be to forbid bookmarks from pointing to hidden commits entirely, but have good support for tags pointing to hidden commits (as well as pushing/fetching tags). Perhaps a bookmark could even become a pointer to a change id, while tags would continue pointing to commit ids. This would extend the common use of tags for labeling releases. Obviously, this would require a lot more redesign and work (especially if we also introduce the third concept of topics in the meantime).

I think long-term the goal should be to make it (bookmarking a hidden commit) an error, like I outlined in the Discord discussion and initial version of this patch. I am also of the opinion that a native Jujutsu has no need for tags, see this Discord message. Since most of this is unrelated to this patch, we should move the discussion to a new issue.

In the shorter term, I'd consider allowing jj abandon to keep bookmarks at the hidden commits instead of deleting (or sliding) them. However, I don't think this is urgent; for now people seem to refer to hidden commits quite rarely.

That wouldn't match my model, so I'd disallow relatively soon.

edit: @joyously here's the Discord message:

@PhilipMetzger: we're clear that we don't want them as a toplevel thing as it makes the semantics ambiguous (like the previous discussion about branches and bookmarks). OTOH, I think people would like a jj git tag command

[joyously]

I can't see the Discord message, so I'm just going to ask if you had proposed some other way than tags to label a release.

I think we should look at the big picture of the jj future, instead of cobbling together ideas from various VCSs to interop while it's not done yet. But I think that includes allowing for additional backends that aren't written yet. That means that we should

• list the needs of a user for labels,
• design those in terms of a "change" the user works on,
• and only then see how to implement that to interop with the existing backends.

I wrote a short list in some other comment (not sure where). I didn't really consider hidden commits. I'm not sure if they are useful, but would they be considered in commands like fix, run, or bisect?
Does the current implementation of bookmarks have special cases regarding trunk() or root()?

[PhilipMetzger]

Does the current implementation of bookmarks have special cases regarding trunk() or root()?

root() is a special "virtual commit" which cannot be made a bookmark. trunk() is not special since it will resolve to a single Change.

I think we should look at the big picture of the jj future, instead of cobbling together ideas from various VCSs to interop while it's not done yet. But I think that includes allowing for additional backends that aren't written yet. That means that we should

• list the needs of a user for labels,
• design those in terms of a "change" the user works on,
• and only then see how to implement that to interop with the existing backends.

Yes, my essential idea is to make bookmarks a "tag" on the "Change" which can then be used as "releases" and other things which Git tags currently are used for.

I wrote a short list in some other comment (not sure where). I didn't really consider hidden commits. I'm not sure if they are useful, but would they be considered in commands like fix, run, or bisect?

I think they should not but Martin should probably chime in.

[joyously]

root() is a special "virtual commit" which cannot be made a bookmark. trunk() is not special since it will resolve to a single Change.

What I meant was if you split the change with the bookmark that trunk() resolves to, is it a special case for where the bookmark goes? My assumption is there is no special cases coded in, but looking at the big picture of what a user really needs, does the generic bookmark handling fit all cases?

Yes, my essential idea is to make bookmarks a "tag" on the "Change" which can then be used as "releases" and other things which Git tags currently are used for.

This makes me think of requests to be able to fetch refspecs.
I see a need for labeling a repo state for releases, testing, bisect, comparison, pushing, and repo navigation. Some of these need to be permanent, some need to be ephemeral, some need to be mobile.

In regard to hidden commits, if my boss asked me for a monthly report of how many lines of code were changed, I would want to get information from the hidden ones too.