Re: Git Evolve

> Junio C Hamano <gitster@pobox.com> writes:
>> Stefan Xenos <sxenos@google.com> 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