>>>>> "BS" == Barry Silverman <[EMAIL PROTECTED]> writes:
I have not thought about remote issues at all, other than the
distribution mechanism vaguely outlined in my previous mail (not
cc'ed to git list but I would not mind if you reproduced it here
if somebody asked), so I am not qualified to comment on that
part of your message.
BS> The way Junio has done it, no intermediate trees or commits
BS> are used...
BS> Is this a bug or a feature?
I would call that a feature in that there is no need to look at
intermediate state. I also might call that a misfeature in that
it may have resulted in a better merge if it looked at
intermediate state.
I just have this fuzzy feeling that, when doing this merge:
A-1 --- A-2 --- A-3
/ \
Common Ancestor Merge Result
\ /
B-1 --- B-2 --- B-3
looking at diff(Common Ancestor, A-1), diff(Common Ancestor,
B-1), diff(A-1, A-2), ... might give you richer context than
just merging 3-way using Common Ancestor, A-3, and B-3 to derive
the Merge Result. It might not. I honestly do not know.
BTW, Pasky, the above paragraph is my answer to your question in
the other message <[EMAIL PROTECTED]>:
> But one different thing to note here.
>
> You say "merge these two trees" above (I take it that you mean
> "merge these two trees, taking account of this tree as their
> common ancestor", so actually you are dealing with three trees),
> and I am tending to agree with the notion of merging trees not
> commits. However you might get richer context and more sensible
> resulting merge if you say "merge these two commits". Since
> commit chaining is part of the fundamental git object model you
> may as well use it.
Pasky> Could you be more particular on the richer context etc?
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
