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@xxxxxxxxxxxxxx> wrote:
> > > 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
