On Mon, May 12, 2025 at 5:43 PM Martin von Zweigbergk <martinvonz@xxxxxxxxxx> wrote: > > On Mon, 12 May 2025 at 14:07, Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote: > > > > On Sat, May 10, 2025 at 01:31:32PM -0700, Martin von Zweigbergk wrote: > > > To me, the main benefit is being able to refer to an evolving change > > > by a stable ID. That enables things like `jj describe qx -m 'new > > > description'; jj new qx` (update commit message, then switch to it) > > > without having to look up the new commit ID after setting the > > > description. > > > > Notionally this is not different from renaming a file. You have a name > > (file name, commit message subject) and you have the thing it refers to > > (file contents, tree object). > > > > <insert sub-thread about why Git does not have inode numbers for > > files, does not record rename/copy intent, and depends on file > > content similarity checks to detect renames> > > > > If Git can do file content similarity checking to discover renames, then > > surely so can jj and other CR tools do commit similarity checking to > > discover commit message changes. Is there anything that makes the > > preceding statement incorrect? > > That wouldn't work in the `jj describe qx -m 'new description'; jj new > qx` example I used above, right? I think you're suggesting that when > the user runs `jj describe qx -m 'new description'`, we should compare > the reachable commits before the command to the reachable commits > after the command and then record in some storage that the new commit > is part of the same "change" as the old commit. Is that what you > meant? In this particular case, the commit message obviously changed, > so comparing the commit messages will obviously fail. We could of > course make this command record the information itself, however. I didn't follow the entirety of the example (since I think you'd have to have change ID "qx" to start with in that case), but: I think you'd compare commit /contents/ (aka the trees they point to) rather than /messages/, just like how rename detection compares blobs or trees? (Although I seem to recall a recent thread where a heuristic involving the old/new name went wrong because it was too short, so a heuristic in the messages is probably also reasonable. Doesn't range-diff do something similar?) > > > > Given that we already have this stable ID, [...] > > > > "We" == jujutsu? > > Yes, sorry :) > > > How is this stable ID constructed? > > It's just random bytes (16 when using the Git backend, 32 in the > Google backend). > > > How would things other than jj construct these? We spent many messages > > trying to work that out and in my estimate that wasn't settled. > > Random bytes has worked well for jj. -- D. Ben Knoble
