threads / discuss / 17567

Confused about diff-tree --cc output

Subject: Confused about diff-tree --cc output

## tl;dr

5 messages between Feb 4, 2009 and Feb 5, 2009.

replies: 4people: 2as markdown or json

Jay Soffian· Feb 4, 2009, 21:13 UTC · lore

I'm a bit confused about the output of "git show 8554af" (i.e. git diff-tree --cc 8554af) on the git tree.

This is a merge of a topic branch of two patches I submitted. If I understand what Junio did, he branched js/maint-remote-remove-mirror from maint, applied the two patches I sent via email, then merged that to next. (Given the topic name he chose, after cooking for a while, I guess it will eventually merge to maint.)

My understanding of "git show <merge commit>" is that it should only show changes if the merge resulted in a conflict that needed to be touched up (ignoring the possibility of an evil merge). Yet git show on this commit shows this diff:

diff --cc builtin-remote.c index abc8dd8,07cfdac..db18bcf

--- a/builtin-remote.c
+++ b/builtin-remote.c
@@@ -539,11 -362,14 +549,14 @@@ static int rm(int argc, const char **ar
  		OPT_END()
  	};
  	struct remote *remote;
 -	struct strbuf buf;
 +	struct strbuf buf = STRBUF_INIT;
  	struct known_remotes known_remotes = { NULL, NULL };
  	struct string_list branches = { NULL, 0, 0, 1 };
- 	struct branches_for_remote cb_data = { NULL, &branches, &known_remotes };
- 	int i;
+ 	struct string_list skipped = { NULL, 0, 0, 1 };
+ 	struct branches_for_remote cb_data = {
+ 		NULL, &branches, &skipped, &known_remotes
+ 	};
+ 	int i, result;

  	if (argc != 2)
  		usage_with_options(builtin_remote_usage, options);

This is the same output shown here:

  http://repo.or.cz/w/git.git?a=commitdiff;h=8554af

However, kernel.org's git shows something different (and more what I
would expect, if any output is to be shown):

  http://git.kernel.org/?p=git/git.git;a=commitdiff;h=8554af

(I guess kernel.org is using something like diff-tree -p 3613d1 8554af
--, but I'm not sure why.)

I don't see any other changes to builtin-remote.c that would have
caused a merge conflict, so, color me confused.

j.
Junio C Hamano· Feb 4, 2009, 21:56 UTC · re: Jay Soffian · lore

Re: Confused about diff-tree --cc output

Jay Soffian <jaysoffian@gmail.com> writes:
> My understanding of "git show <merge commit>" is that it should only
> show changes if the merge resulted in a conflict that needed to be
> touched up (ignoring the possibility of an evil merge). Yet git show
> on this commit shows this diff:
I think this is "more than two versions", in
    http://thread.gmane.org/gmane.comp.version-control.git/15486/focus=15491
Nothing new to see here, I think.
Jay Soffian· Feb 5, 2009, 03:49 UTC · re: Junio C Hamano · lore

Re: Confused about diff-tree --cc output

On Wed, Feb 4, 2009 at 4:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 5 quoted lines
> I think this is "more than two versions", in
>
>    http://thread.gmane.org/gmane.comp.version-control.git/15486/focus=15491
>
> Nothing new to see here, I think.
Okay, let me just make sure I understand. The output of git show has:

diff --cc builtin-remote.c index abc8dd8,07cfdac..db18bcf

So, I can do:

git diff abc8dd8 db18bcf > parent1.diff git diff 07cfdac db18bcf > parent2.diff

Then look at each for overlapping hunks. If I do so, I find that this hunk in parent1.diff (I've annotated w/line numbers):

@@ -542,8 +552,11 @@ static int rm(int argc, const char **argv)
552 	struct strbuf buf = STRBUF_INIT;
553 	struct known_remotes known_remotes = { NULL, NULL };
554 	struct string_list branches = { NULL, 0, 0, 1 };
   -	struct branches_for_remote cb_data = { NULL, &branches, &known_remotes };
   -	int i;
555+	struct string_list skipped = { NULL, 0, 0, 1 };
556+	struct branches_for_remote cb_data = {
557+		NULL, &branches, &skipped, &known_remotes
558+	};
559+	int i, result;
560
561 	if (argc != 2)
562 		usage_with_options(builtin_remote_usage, options);

and this hunk in parent2.diff:

@@ -362,7 +549,7 @@ static int rm(int argc, const char **argv)
549 		OPT_END()
550 	};
551 	struct remote *remote;
   -	struct strbuf buf;
552+	struct strbuf buf = STRBUF_INIT;
553 	struct known_remotes known_remotes = { NULL, NULL };
554 	struct string_list branches = { NULL, 0, 0, 1 };
555 	struct string_list skipped = { NULL, 0, 0, 1 };

overlap (lines 552-555). Since the hunks overlap, and each introduces
a unique change, both hunks are shown in the combined format. I guess
this makes sense now that I know how it works, but my expectation had
been that I'd only see output if there was a merge conflict.

I also note that "git diff-tree -U2 --cc 8554af" produces no output,
and this is because there is no longer overlap (well, the context
lines overlap, but are identical, which I guess is good enough).

Is that about right?

(Aside, to reconstruct the merge manually I did the following, but I
bet there is an easier way:

git show 3613d1d:builtin-remote.c > mine
git show 441adf0:builtin-remote.c > other
git show $(git merge-base 3613d1d 441adf0):builtin-remote.c > base
git merge-file -p mine base other
)

j.
Junio C Hamano· Feb 5, 2009, 08:38 UTC · re: Jay Soffian · lore

Re: Confused about diff-tree --cc output

Jay Soffian <jaysoffian@gmail.com> writes:
> Is that about right?
Yes, not just about right but it is how it works.
The patch in:
    http://article.gmane.org/gmane.comp.version-control.git/15500
gave the final implementation of the rule.

The rule is that if there are only one or two variations to choose from, and the result matches one of them, it is not interesting. Otherwise it is interesting.

In an octopus where more than two parents disagree, no matter what the result is, it is interesting.

In an extreme case, even if both parents in a two-parent merge had the same contents (i.e. only one to choose from), if you amend the merge result to make it different from it, it becomes interesting.

In your example, two pieces, each of which took everything from one parent (hence is uninteresting by itself), happened to lie within the context range. It is not very interesting, and it automerges cleanly, but it is rare that these merges happen close together, and that "close miss" is what makes this case "interesting".

It is exactly the same as the example in the message I referred you to. In the same thread:

    http://article.gmane.org/gmane.comp.version-control.git/15598

has a very clear explanation about this exact kind of borderline "is it really interesting?" case.

Also the follow-up to it:
    http://article.gmane.org/gmane.comp.version-control.git/15600

would give you further insights, the most interesting of which is that what is shown in --cc output does *NOT* have anything to do with "did the merge result in a manual conflict resolution?"

By the way, the latter message talks about gitk not showing the right thing, but that was an ancient story. These days gitk just shows what diff --cc feeds it and there is no discrepancy between the two.

Jay Soffian· Feb 5, 2009, 08:57 UTC · re: Junio C Hamano · lore

Re: Confused about diff-tree --cc output

On Thu, Feb 5, 2009 at 3:38 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 5 quoted lines
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> Is that about right?
>
> Yes, not just about right but it is how it works.

Got it. I did read the thread you pointed me to earlier, but I had to work through it w/my example to make sure I understood completely. I appreciate your patience.

j.

← back to recent threads