git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* combined diff, but not condensed, howto?
@ 2008-09-17  8:00 Johannes Sixt
  2008-09-17 16:58 ` Junio C Hamano
  0 siblings, 1 reply; 9+ messages in thread
From: Johannes Sixt @ 2008-09-17  8:00 UTC (permalink / raw)
  To: Git Mailing List

After a merge conflict, 'git diff' shows a combined diff, which presents
only the parts that conflicted or where there are near-by changes from
different parents (potential conflicts). Is there a command line switch so
that *all* changes are shown, even non-conflicting ones?

'git diff', 'git diff --cc', and 'git diff -c' all show the same output.

-- Hannes

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: combined diff, but not condensed, howto?
  2008-09-17  8:00 combined diff, but not condensed, howto? Johannes Sixt
@ 2008-09-17 16:58 ` Junio C Hamano
  2008-09-18  5:57   ` Johannes Sixt
  0 siblings, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2008-09-17 16:58 UTC (permalink / raw)
  To: Johannes Sixt; +Cc: Git Mailing List

Johannes Sixt <j.sixt@viscovery.net> writes:

> After a merge conflict, 'git diff' shows a combined diff, which presents
> only the parts that conflicted or where there are near-by changes from
> different parents (potential conflicts). Is there a command line switch so
> that *all* changes are shown, even non-conflicting ones?

Like "git diff HEAD"?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: combined diff, but not condensed, howto?
  2008-09-17 16:58 ` Junio C Hamano
@ 2008-09-18  5:57   ` Johannes Sixt
  2008-09-18  6:14     ` Junio C Hamano
  0 siblings, 1 reply; 9+ messages in thread
From: Johannes Sixt @ 2008-09-18  5:57 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Git Mailing List

Junio C Hamano schrieb:
> Johannes Sixt <j.sixt@viscovery.net> writes:
> 
>> After a merge conflict, 'git diff' shows a combined diff, which presents
>> only the parts that conflicted or where there are near-by changes from
>> different parents (potential conflicts). Is there a command line switch so
>> that *all* changes are shown, even non-conflicting ones?
> 
> Like "git diff HEAD"?

No. Something that produces

@@@ -23,5 -23,5 +23,7 @@@
  A
  B
++<<<<<<< HEAD:foo
 +C
++=======
+ D
++>>>>>>> 97d7fee2cb068f215a593c6e5623b265db45d3bc:foo
  E
  F
@@@ -50,4 -50,5 +53,5 @@@
  G
  H
 +I
  J
  K
@@@ -60,5 -61,4 +63,4 @@@
  L
  M
- N
  O
  P

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: combined diff, but not condensed, howto?
  2008-09-18  5:57   ` Johannes Sixt
@ 2008-09-18  6:14     ` Junio C Hamano
  2008-09-18  6:24       ` Johannes Sixt
  0 siblings, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2008-09-18  6:14 UTC (permalink / raw)
  To: Johannes Sixt; +Cc: Git Mailing List

Johannes Sixt <j.sixt@viscovery.net> writes:

> Junio C Hamano schrieb:
>> Johannes Sixt <j.sixt@viscovery.net> writes:
>> 
>>> After a merge conflict, 'git diff' shows a combined diff, which presents
>>> only the parts that conflicted or where there are near-by changes from
>>> different parents (potential conflicts). Is there a command line switch so
>>> that *all* changes are shown, even non-conflicting ones?
>> 
>> Like "git diff HEAD"?
>
> No. Something that produces
...

Ah, I see what you mean.

It all happens inside combine-diff.c::make_hunks().  If you pass dense==0,
you should be able to get all the uninteresting hunks, I think.

Perhaps

	$ git diff --base -c

???

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: combined diff, but not condensed, howto?
  2008-09-18  6:14     ` Junio C Hamano
@ 2008-09-18  6:24       ` Johannes Sixt
  2008-09-18  7:01         ` Junio C Hamano
  0 siblings, 1 reply; 9+ messages in thread
From: Johannes Sixt @ 2008-09-18  6:24 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Git Mailing List

Junio C Hamano schrieb:
> Johannes Sixt <j.sixt@viscovery.net> writes:
> 
>> Junio C Hamano schrieb:
>>> Johannes Sixt <j.sixt@viscovery.net> writes:
>>>
>>>> After a merge conflict, 'git diff' shows a combined diff, which presents
>>>> only the parts that conflicted or where there are near-by changes from
>>>> different parents (potential conflicts). Is there a command line switch so
>>>> that *all* changes are shown, even non-conflicting ones?
>>> Like "git diff HEAD"?
>> No. Something that produces
> ...
> 
> Ah, I see what you mean.
> 
> It all happens inside combine-diff.c::make_hunks().  If you pass dense==0,
> you should be able to get all the uninteresting hunks, I think.
> 
> Perhaps
> 
> 	$ git diff --base -c

Yes, that does it!

Thanks,
-- Hannes

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: combined diff, but not condensed, howto?
  2008-09-18  6:24       ` Johannes Sixt
@ 2008-09-18  7:01         ` Junio C Hamano
  2008-09-18  7:30           ` Johannes Sixt
  0 siblings, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2008-09-18  7:01 UTC (permalink / raw)
  To: Johannes Sixt; +Cc: Git Mailing List

Johannes Sixt <j.sixt@viscovery.net> writes:

> Junio C Hamano schrieb:
> ...
>> It all happens inside combine-diff.c::make_hunks().  If you pass dense==0,
>> you should be able to get all the uninteresting hunks, I think.
>> 
>> Perhaps
>> 
>> 	$ git diff --base -c
>
> Yes, that does it!

It may do so, but I do not necessarily agree with the logic.

It is very much Ok and useful for "git diff" to default to "--cc -p", and
it may be fine for "git diff-files -p" to default to "--cc".

But I think ideally an explicit "git diff -c" and "git diff-files -c -p"
should not turn the "dense combined" mode on.

The commonality of these two functions is striking and calls for proper
refactoring, but aside from that, I think a patch like this should be
applied.  What do you think?

---

 builtin-diff-files.c |    7 ++++++-
 builtin-diff.c       |    7 ++++++-
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git i/builtin-diff-files.c w/builtin-diff-files.c
index 9bf10bb..2b578c7 100644
--- i/builtin-diff-files.c
+++ w/builtin-diff-files.c
@@ -50,7 +50,12 @@ int cmd_diff_files(int argc, const char **argv, const char *prefix)
 	    3 < rev.max_count)
 		usage(diff_files_usage);
 
-	if (rev.max_count == -1 &&
+	/*
+	 * "diff-files --base -p" should not combine merges because it
+	 * was not asked to.  "diff-files -c -p" should not densify
+	 * (the user should ask with "diff-files --cc" explicitly).
+	 */
+	if (rev.max_count == -1 && !rev.combine_merges &&
 	    (rev.diffopt.output_format & DIFF_FORMAT_PATCH))
 		rev.combine_merges = rev.dense_combined_merges = 1;
 
diff --git i/builtin-diff.c w/builtin-diff.c
index 037c303..9fb30c6 100644
--- i/builtin-diff.c
+++ w/builtin-diff.c
@@ -223,7 +223,12 @@ static int builtin_diff_files(struct rev_info *revs, int argc, const char **argv
 		argv++; argc--;
 	}
 
-	if (revs->max_count == -1 &&
+	/*
+	 * "diff --base" should not combine merges because it was not
+	 * asked to.  "diff -c" should not densify (the user should ask
+	 * with "diff --cc" explicitly.
+	 */
+	if (revs->max_count == -1 && !revs->combine_merges &&
 	    (revs->diffopt.output_format & DIFF_FORMAT_PATCH))
 		revs->combine_merges = revs->dense_combined_merges = 1;
 

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: combined diff, but not condensed, howto?
  2008-09-18  7:01         ` Junio C Hamano
@ 2008-09-18  7:30           ` Johannes Sixt
  2008-09-18  9:08             ` [PATCH] diff/diff-files: do not use --cc too aggressively Junio C Hamano
  0 siblings, 1 reply; 9+ messages in thread
From: Johannes Sixt @ 2008-09-18  7:30 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Git Mailing List

Junio C Hamano schrieb:
> It is very much Ok and useful for "git diff" to default to "--cc -p", and
> it may be fine for "git diff-files -p" to default to "--cc".
> 
> But I think ideally an explicit "git diff -c" and "git diff-files -c -p"
> should not turn the "dense combined" mode on.
> 
> The commonality of these two functions is striking and calls for proper
> refactoring, but aside from that, I think a patch like this should be
> applied.  What do you think?

This makes a lot of sense. As I mention in my initial post, I was
wondering why 'diff -c' was the same as 'diff --cc'.

> diff --git i/builtin-diff-files.c w/builtin-diff-files.c
> index 9bf10bb..2b578c7 100644
> --- i/builtin-diff-files.c
> +++ w/builtin-diff-files.c
> @@ -50,7 +50,12 @@ int cmd_diff_files(int argc, const char **argv, const char *prefix)
>  	    3 < rev.max_count)
>  		usage(diff_files_usage);
>  
> -	if (rev.max_count == -1 &&
> +	/*
> +	 * "diff-files --base -p" should not combine merges because it
> +	 * was not asked to.  "diff-files -c -p" should not densify
> +	 * (the user should ask with "diff-files --cc" explicitly).
> +	 */
> +	if (rev.max_count == -1 && !rev.combine_merges &&
>  	    (rev.diffopt.output_format & DIFF_FORMAT_PATCH))
>  		rev.combine_merges = rev.dense_combined_merges = 1;

Hm... In my tests, a bare 'git diff-files --cc' produces a combined diff,
but 'git diff-files -c' does not.

> diff --git i/builtin-diff.c w/builtin-diff.c
> index 037c303..9fb30c6 100644
> --- i/builtin-diff.c
> +++ w/builtin-diff.c
> @@ -223,7 +223,12 @@ static int builtin_diff_files(struct rev_info *revs, int argc, const char **argv
>  		argv++; argc--;
>  	}
>  
> -	if (revs->max_count == -1 &&
> +	/*
> +	 * "diff --base" should not combine merges because it was not
> +	 * asked to.  "diff -c" should not densify (the user should ask
> +	 * with "diff --cc" explicitly.

I don't see why you add "the user should ask with 'diff --cc'" when this
becomes the default anyway.

> +	 */
> +	if (revs->max_count == -1 && !revs->combine_merges &&
>  	    (revs->diffopt.output_format & DIFF_FORMAT_PATCH))
>  		revs->combine_merges = revs->dense_combined_merges = 1;

-- Hannes

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH] diff/diff-files: do not use --cc too aggressively
  2008-09-18  7:30           ` Johannes Sixt
@ 2008-09-18  9:08             ` Junio C Hamano
  2008-09-18  9:30               ` Johannes Sixt
  0 siblings, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2008-09-18  9:08 UTC (permalink / raw)
  To: Git Mailing List; +Cc: Johannes Sixt

Textual diff output for unmerged paths was too eager to give condensed
combined diff.  This has two problems:

 (1) "diff --base/--ours/--theirs" (and "diff-files -p" with the same) is
     a request to compare with the named stage.  We showed "-c -p" output
     instead;

 (2) "diff -c" (and "diff-files -c -p") is a request to view combined diff
     without condensing (otherwise the user would have explicitly asked
     for --cc, not -c).  We showed "--cc" output anyway.

0fe7c1d (built-in diff: assorted updates, 2006-04-29) claimed to be
careful about doing this, but its breakage was hidden because back then
"git diff" was still a shell script that did not use the codepath it
introduced fully.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 builtin-diff-files.c |    7 ++++++-
 builtin-diff.c       |    8 +++++++-
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/builtin-diff-files.c b/builtin-diff-files.c
index 9bf10bb..2b578c7 100644
--- a/builtin-diff-files.c
+++ b/builtin-diff-files.c
@@ -50,7 +50,12 @@ int cmd_diff_files(int argc, const char **argv, const char *prefix)
 	    3 < rev.max_count)
 		usage(diff_files_usage);
 
-	if (rev.max_count == -1 &&
+	/*
+	 * "diff-files --base -p" should not combine merges because it
+	 * was not asked to.  "diff-files -c -p" should not densify
+	 * (the user should ask with "diff-files --cc" explicitly).
+	 */
+	if (rev.max_count == -1 && !rev.combine_merges &&
 	    (rev.diffopt.output_format & DIFF_FORMAT_PATCH))
 		rev.combine_merges = rev.dense_combined_merges = 1;
 
diff --git a/builtin-diff.c b/builtin-diff.c
index 037c303..d5fe775 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -223,7 +223,13 @@ static int builtin_diff_files(struct rev_info *revs, int argc, const char **argv
 		argv++; argc--;
 	}
 
-	if (revs->max_count == -1 &&
+	/*
+	 * "diff --base" should not combine merges because it was not
+	 * asked to.  "diff -c" should not densify (if the user wants
+	 * dense one, --cc can be explicitly asked for, or just rely
+	 * on the default).
+	 */
+	if (revs->max_count == -1 && !revs->combine_merges &&
 	    (revs->diffopt.output_format & DIFF_FORMAT_PATCH))
 		revs->combine_merges = revs->dense_combined_merges = 1;
 
-- 
1.6.0.2.412.g0bc80

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] diff/diff-files: do not use --cc too aggressively
  2008-09-18  9:08             ` [PATCH] diff/diff-files: do not use --cc too aggressively Junio C Hamano
@ 2008-09-18  9:30               ` Johannes Sixt
  0 siblings, 0 replies; 9+ messages in thread
From: Johannes Sixt @ 2008-09-18  9:30 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Git Mailing List

Junio C Hamano schrieb:
> Textual diff output for unmerged paths was too eager to give condensed
> combined diff.  This has two problems:
> 
>  (1) "diff --base/--ours/--theirs" (and "diff-files -p" with the same) is
>      a request to compare with the named stage.  We showed "-c -p" output
>      instead;

I cannot reproduce what you describe here. "diff --base/--ours/--theirs"
works as expected with and without this patch.

>  (2) "diff -c" (and "diff-files -c -p") is a request to view combined diff
>      without condensing (otherwise the user would have explicitly asked
>      for --cc, not -c).  We showed "--cc" output anyway.

The patch fixes this:

Tested-by: Johannes Sixt <johannes.sixt@telecom.at>

-- Hannes

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2008-09-18  9:31 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-09-17  8:00 combined diff, but not condensed, howto? Johannes Sixt
2008-09-17 16:58 ` Junio C Hamano
2008-09-18  5:57   ` Johannes Sixt
2008-09-18  6:14     ` Junio C Hamano
2008-09-18  6:24       ` Johannes Sixt
2008-09-18  7:01         ` Junio C Hamano
2008-09-18  7:30           ` Johannes Sixt
2008-09-18  9:08             ` [PATCH] diff/diff-files: do not use --cc too aggressively Junio C Hamano
2008-09-18  9:30               ` Johannes Sixt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).