Re: git-rerere observations and feature suggestions

[Ingo Molnar <mingo@elte.hu>]

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

> >  - 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