Re: git-rerere observations and feature suggestions

From: Ingo Molnar <mingo@elte.hu>
Date: Jun 16, 2008, 19:09 UTC
Message-ID: <20080616190911.GA7047@elte.hu>
In-Reply-To: <7vej6xb4lr.fsf@gitster.siamese.dyndns.org>

* Junio C Hamano <gitster@pobox.com> wrote:

Show 9 quoted lines

> >  - Automation: would be nice to have a git-rerere modus operandi where
> >    it would auto-commit things if and only if all conflicting files were 
> >    resolved.
> 
> I am not sure how safe this is.  rerere as originally designed does 
> not even update the index with merge results so that the application 
> of earlier resolution can be manually inspected, and this is exactly 
> because I consider a blind textual reapplication of previous 
> resolution always iffy, even though I invented the whole mechanism.

We use a 'safe, lazy integration' method in -tip, that basically has external checks against any integration bugs.

Basically, we integrate only about once a day, and we advance the topic branches but do not reintegrate on every topic merge. We merge commits _both_ to their target topic branches, and to the (previous) integration branch.

Then once a day (or every second day) we 'reintegrate': we propagate the topic branches to the linux-next auto-*-next branches [recreating them from scratch] and flush out the messy criss-cross merges from the integration tree.

But that is always an identity transformation as far as the integration result is concerned: the result of the integration run must be exactly the same content (obviously it results in a very different tree structure) as the previous one. We only run it on a perfectly tested tree so we know none of our previous merges were wrong, and we want the git-rerere result to be the same. We repeat the integration until the end result matches.

In fact sometimes git-rerere is able to pick up a conflict resolution from our 'messy' delta-merge into the integration tree, which is an added bonus. (this doesnt always work if the merge order differs from integration order)

Anyway, the gist is that in this workflow it does not hurt at all if git-rerere is "unsafe", and we'd love to have the integration as fast as possible. Right now most of my manual overhead is in making sure that git-rerere has not missed some file.

At a ~100 conflicting files tracked, that is rather error-prone, and i'd love to have further automation here besides a rather lame method of grepping for:

  "Resolved 'kernel/Makefile' using previous resolution."

type of patterns in git-merge output.

So i'd not mind if git-rerere was safe by default, but it would be nice to have some knob to turn it into something fast and automatic. For us it would be much _safer_, because right now most of our manual energy is spent on checking something that could be automated.

We could in theory avoid git-rerere altogether by creating separate conflict resolution branches, and automated their handling - but we thought git-rerere was pretty nice as well and kept the branch count down.

And while asking for an arm i'd also like to ask for a leg, if i may: i'd love it if a "slightly conflicting" octopus merge of 85 topic trees would not result in one huge conflict commit that merges together 1000 commits into a single commit ;-)

So right now in our -tip scripts work around this issue: we 'serialize' the topic merges despite having very nice opportunities for higher-order octopus merges. The integration would be a lot faster if we could use octopus merges and automated git-rerere. (Octopus merges would look much nicer as well in graphical representation as well, which counts too :-) )

	Ingo