Re: [PATCH] builtin-commit: avoid using reduce_heads()

From: Jakub Narebski <jnareb@gmail.com>
Date: Sep 29, 2008, 18:44 UTC
Message-ID: <200809292044.24799.jnareb@gmail.com>
In-Reply-To: <20080929181856.GX23137@genesis.frugalware.org>

Dnia poniedziałek 29. września 2008 20:18, Miklos Vajna napisał:

> On Mon, Sep 29, 2008 at 05:07:22PM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:

Show 15 quoted lines

> > > Currently parents of merge commits are 'reduce(HEAD + MERGE_HEAD)'
> > > in symbolic equation; I propose they would be simply 'MERGE_HEAD'.
> > > then we set this branch to new commit
> > 
> > Yes. Currently - after a merge conflict - you are able to check what
> > heads caused were merged, which caused the conflict, but with this
> > approach you would not be able to. I think this would be a step back...
> 
> Uh, I should read my mail before sending it next time.
> 
> I just wanted to say that in case, for example, I merge A^ and A, but I
> get a conflict after octopus tried to merge A^ then it can be a useful
> info to see that A^ was a head. Putting reduce(HEAD + MERGE_HEAD) to
> MERGE_HEAD would hide this info, which would make the situation worse,
> IMHO.

I don't understand: I thought that merge strategy gets _reduced_ heads. Moreover, if head reduction reduces number of heads to two, you would use twohead merge (recursive) instead of octopus, and fast-forward if there is only one head after reduction.

All that I proposed is to put those reduced heads into MERGE_HEAD. I did not proposed to put yet unresolved heads in MERGE_HEAD in case of octopus merge conflict. I think either you misunderstood me, or I misunderstood you.

Take for example the following case of [H@repo]$ git merge a b c

   .---.---.---.---H                   <-- H <-- HEAD
                    \
                     \.---.---.---a    <-- a
                           \
                            \-b        <-- b
                               \                              
                                \--c   <-- c

Currently after failed merge we have:
HEAD: 
  refs: refs/heads/H
MERGE_HEAD
  sha1(a)
  sha1(b)
  sha1(c)

I propose it to be
HEAD:
  refs: refs/heads/H
MERGE_HEAD
  sha1(a)
  sha1(c)

And merge strategy chosen would be twohead one (recursive).

If the situation was slightly different

   .---.---.---.---.--.---.---.---H    <-- H <-- HEAD
                    \
                     \.---.---.---a    <-- a
                           \
                            \-b        <-- b
                               \                              
                                \--c   <-- c

I propose it to be
HEAD:
  refs: refs/heads/H
MERGE_HEAD
  sha1(H)
  sha1(a)
  sha1(c)

And merge strategy chosen would be octopus.

-- 
Jakub Narebski
Poland