jj-vcs
FR: don't assign working copy IDs to commits in `main`
Is your feature request related to a problem? Please describe. at work we have a monorepo with almost 12k commits in the trunk branch. the working copy ids are getting a little hard to remember - this makes some operations slightly more effort than desired (i have to copy and paste??? in the year of our lord 2024???)
working copy IDs don't need to be assigned to commits in an immutable branch! since the branch can only move forwards, jujutsu doesn't need another way to track working copies besides the git ref. this should de-pollute the working copy ID space and keep those sweet, sweet 1-3 character working copy IDs available :)
Describe the solution you'd like for immutable revsets, don't assign a working copy id
Describe alternatives you've considered none. this is for convenience, and (without any experience in this codebase) might be the simplest way to de-pollute the working copy ID space
Additional context n/a
I'm pretty sure this is solvable by configuring a revsets.short-prefixes revset to better suit your repo.
And immutable "branch" is just another similar configurable(!) revset which just prevents the user from accidents, "immutable commits" are not part of the core model, hence every commit has a change id 🤷
Actually to have almost exactly what you described, you need revsets.short-prefixes to be an inverse of revset-aliases."immutable_heads()" (also btw whoah those two are inconsistent with one-another, hmm)?. I don't know the defaults there
You could also configure jj log template to not show change ids for immutable ids. Though, I don't think you should do it; the change id is useful enough that "wasting" a few characters (8?) to show it helps. (Update: Though, I haven't tested this theory.)
IIUC that the commits you don't care about make the prefixes longer for the commits you do care about. If so, @necaqua pretty much covered what can currently be done. The other problem is that, it seems, our current default for revsets.short-prefixes doesn't work well for every use case, which is not very surprising.
If anybody experiments and finds interesting values to set the revset to, it'd be nice to share them. It would be wonderful if we find ways to improve the default, or if we could providing a few alternative good options for different workflows that we could ship with jj. This is not necessarily easy, though.
A separate, weird, idea: would it help if we made the "short" prefixes for change ids you don't care about the same length (it'd probably be 7-8 in large repos)? This would not make the short prefixes for the commits you care about any shorter, but maybe it'll make things look more consistent?
I'm not sure what you mean by "undo"ing something in the immutable branch.
It is true that, for immutable commits, the change ids are not very important, since their commit id shouldn't change. From this perspective, it makes sense not to show them if you prefer not to see them, it doesn't really limit what you can do or how much you have to remember.
However, I don't think it'd be a good idea to get rid of them entirely. I also think we should show change ids for all commits by default.
Why I think we should have change ids for immutable commits
You might change the set of immutable commits from time to time. If we didn't store change ids for such commits, this would mean that a commit with the same commit id could have different change ids at different points of time. This seems confusing, at least unless there is a very good reason.
(Aside: I actually can think of one reason: perhaps storing fewer change ids would help with https://github.com/martinvonz/jj/issues/2193. It seems unlikely though. I'll ping @yuja, just in case)
If we believe this argument, the only thing that is left for us to do AFAICT is to play with how long the prefixes for change ids are, depending on whether a commit is more or less relevant. Also, we need better ways for telling which commits are relevant.
Aside: Why I think we should show change ids for all commits by default
-
I'd like to show them by default simply for consistency. I don't want new users to wonder why some commits have change ids and other don't.
-
For at least a subset of non-beginners, I think not showing the change ids would be a minor annoyance. I'd have to look at a different part of my screen depending on what commit I'm looking at, and use a different alphabet to refer to them.
Minor aside: If the prefix length for change ids is based in part on immutable commits (which seems fine), I'd prefer it if we gave short id prefixes to parents of "relevant" commits, even if they are immutable. This is a very minor detail, though.
I think we already default the revsets.short-prefixes setting to be the based on mutable commits, so I think you should only have to configure the immutable set to include your main branch. See https://martinvonz.github.io/jj/prerelease/config/#set-of-immutable-commits
I'm pretty sure this is solvable by configuring a revsets.short-prefixes revset to better suit your repo.
from the doc
# Prioritize the current branch
revsets.short-prefixes = "(main..@)::"
i think this is what i want. i'll play around with it a bit. thank you!
You could also configure jj log template to not show change ids for immutable ids.
i don't think this is what i want? i want to exclude immutable ids from being considered for operations like jj new. just because the change ids aren't printed in jj log, i'll still have the really long "shortest" id right?
If the prefix length for change ids is based in part on immutable commits (which seems fine), I'd prefer it if we gave short id prefixes to parents of "relevant" commits, even if they are immutable. This is a very minor detail, though.
i'm ok with that. but far more often am i doing jj new etc on a mutable commit, so i think it makes sense to prioritize those commits for shortest-matching prefix
I think we already default the revsets.short-prefixes setting to be the based on mutable commits, so I think you should only have to configure the immutable set to include your main branch
jj log -r 'immutable_heads()' shows the main branch, so i think this is already taken care of? do you mean i have to set all commits in the main branch to be included in immutable_heads?