Gerrit uses notes and branches of meta-commits internally for its database, but it still uses the change-id footers to associate an uploaded commit with a change within its database. On Thu, Oct 4, 2018 at 9:05 AM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: >> Stefan Xenos <sxenos@xxxxxxxxxx> writes: >> >>> What is the evolve command? >>> ... >>> - Systems like gerrit would no longer need to rely on "change-id" tags >>> in commit comments to associate commits with the change that they >>> edit, since git itself would have that information. >>> ... >>> Is anyone else interested in this? Please email me directly or on this >>> list. Let's chat: I want to make sure that whatever we come up with is >>> at least as good as any similar technology that has come before. >> >> As you listed in the related technologies section, I think the >> underlying machinery that supports "rebase -i", especially with the >> recent addition of redoing the existing merges (i.e. "rebase -i >> -r"), may be enough to rewrite the histories that were built on top >> of a commit that has been obsoleted by amending. >> >> I would imagine that the main design effort you would need to make >> is to figure out a good way to >> >> (1) keep track of which commits are obsoleted by which other ones >> [*1*], and >> >> (2) to figure out what histories are still to be rebuilt in what >> order on top of what commit efficiently. >> >> Once these are done, you should be able to write out the sequence of >> instructions to feed the same sequencer machinery used by the >> "rebase -i" command. > > Well, that assumes that "rebase -i" can correctly recreate merges, if > needed. > >> [Side note] >> >> *1* It is very desirable to keep track of the evolution of a change >> without polluting the commit object with things like Change-Id: >> and other cruft, either in the body or in the header. If we >> lose the Change-Id: footer without adding any new cruft in the >> commit object header, that would be a great success. It would >> be a failure if we end up touching the object header. > > Doesn't Gerrit use git-notes instead of 'Change-Id:' trailer nowadays? > Notes transport is quite easily controlled; the problem with notes merge > does not matter for this use. > > Best, > -- > Jakub Narębski
