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
