Hi Peff,
First, thanks for correcting my diff-without-NEXT-and-WTREE to
diff-with-NEXT-and-WTREE pairing.
Second, I agree that the index is more than just NEXT. There were
good reasons behind calling it "NEXT" and not "INDEX".
Third, I didn't know for sure that "git diff" during a merge conflict
would produce a three-way-diff result, but I suspected it would. (You
really didn't have to produce all that code - I would have accepted
your word as an expert. But thanks!) So, yes, the two-way merge
result of "git diff NEXT WTREE" would be different.
I could argue that git should allow a 4-way diff where "git diff NEXT
WTREE OURS THEIR" prints all the unresolved changes as coming from
OURS or THEIR or neither. But I think that's silly.
I will say that "git diff NEXT WTREE" will tell you what's left
unresolved and most of it is in <<<<====>>>>> blocks that tell you
whether it came from OURS or THEIRS. If the user has any discipline,
they won't introduce unnecessary changes that were not necessary for
the merge. If they don't have discipline, we really can't help them.
I'm not saying there is no use for a 3-way merge. In fact, I'd guess
it's a requirement so that Alice can check Bob's merge before Bob
commits. But I'm fine with making it "git diff --3-way" or the silly
"git diff NEXT WTREE OURS THEIRS" because I think its "git diff NEXT
WTREE" will be good enough 99% of the time.
On Wed, Jun 8, 2011 at 8:43 PM, Jeff King <peff@xxxxxxxx> wrote:
> On Wed, Jun 08, 2011 at 02:57:09PM -0400, Michael Nahas wrote:
>
>> > Isn't this going to be behavior change, since your NEXT is not quite the
>> > same as the index? How do I now get an n-way combined diff of the
>> > unmerged files in the index?
>>
>> The index is a file in .git/ that serves many purposes. NEXT is an
>> image of the whole project. NEXT can be computed from the index and
>> HEAD.
>>
>> During a conflicted merge, stage 0 of the index holds the resolved
>> files. WTREE holds all merge files: the resolved and the unresolved
>> (which have <<<< ==== >>>> blocks in them). I propose that during a
>> conflicted merge, that NEXT be computed as HEAD plus the resolved
>> files, that is, the files in stage 0 of the index.
>
> OK. So NEXT actually has less information than the whole index, because
> it doesn't contain information on what was on either side of the merge
> originally (or in the merge base).
>
>> "git diff HEAD NEXT" would print the resolved changes.
>> "git diff NEXT WTREE" would print the unresolved changes
>> "git diff HEAD WTREE" would print all changes.
>>
>> I believe that is the same behaviour as "git diff", "git diff
>> --cached" and "git diff HEAD" during a conflicted merge.
>
> I assume you don't mean respectively here, but rather:
>
> git diff => git diff NEXT WTREE
> git diff --cached => git diff HEAD NEXT
> git diff HEAD => git diff HEAD WTREE
>
> But even still, I don't think "git diff" is the same. Try this:
>
> git init repo && cd repo
> echo one >file && git add file && git commit -m one &&
> echo two >file && git add file && git commit -m two &&
> git checkout -b other HEAD^ &&
> echo three >file && git add file && git commit -m three &&
> ! git merge master &&
> git diff
>
> I get:
>
> diff --cc file
> index 2bdf67a,f719efd..0000000
> --- a/file
> +++ b/file
> @@@ -1,1 -1,1 +1,5 @@@
> ++<<<<<<< HEAD
> +three
> ++=======
> + two
> ++>>>>>>> master
>
> Note that this is _not_ a diff between NEXT and the working tree. It is a
> 3-way "combined" diff of what's in the working tree compared to each side of
> the merge.
>
> If NEXT is a tree that contains HEAD plus stage 0 files, then we would
> see a 2-way diff of the HEAD version of "file" and the working tree
> version. I.e., the same as "git diff HEAD -- file":
>
> diff --git a/file b/file
> index 2bdf67a..087e97e 100644
> --- a/file
> +++ b/file
> @@ -1 +1,5 @@
> +<<<<<<< HEAD
> three
> +=======
> +two
> +>>>>>>> master
>
> which looks similar, because we haven't started resolving anything yet.
> But try resolving it like this:
>
> cat >file <<'EOF'
> three
> and
> two
> EOF
>
> Now try "git diff" again. You should get:
>
> diff --cc file
> index 2bdf67a,f719efd..0000000
> --- a/file
> +++ b/file
> @@@ -1,1 -1,1 +1,3 @@@
> +three
> ++and
> + two
>
> This shows us that "three" came from one side of the merge, "two" from
> the other, and that "and" was found in neither side.
>
> Compare to the 2-way that shows:
>
> diff --git a/file b/file
> index 2bdf67a..1ecff7e 100644
> --- a/file
> +++ b/file
> @@ -1 +1,3 @@
> three
> +and
> +two
>
> There's nothing to distinguish added code pulled from the other side of
> the merge versus changes that were made as part of the resolution.
>
> I think this is what Junio was talking about when he said that the index
> is more than a tree. There may be times when you want to treat the items
> in stage 0 as a tree, but diffing against the index is more than just
> diffing against that tree.
>
>> I do not know how "n-way" merge works. I saw somewhere that indicated
>> that it was a series of N-1 two-way merges.
>
> Git history can represent a merge of any number of branches (an "octopus
> merge"), because the commits store only the final state and a list of
> parent commits. The combined diff format is capable of handling an
> arbitrary number of parents.
>
> I should have just said "3-way", though, because it's not relevant here.
> The index only has 2 stage bits, so we can only represent four stages
> ("resolved", "base", "ours", and "theirs"). So you can't represent an
> n-way merge in the index.
>
> So "git merge" just punts on an octopus merge if there are actual merge
> conflicts that would need to go in the index. So in practice, people
> just tend to do N-1 pair-wise merges.
>
> You can see some example octopus merges (and their combined diff) if you
> have a recent git (that supports --min-parents) with:
>
> git log --min-parents=3 -p --cc
>
> in both git.git and linux-2.6.git.
>
> -Peff
>
--
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