[PATCH] show changed tree objects with recursive git-diff-tree

[PATCH] show changed tree objects with recursive git-diff-tree

[Nicolas Pitre]

When -p is not used, git-diff-tree currently shows changed tree objects
but only when not recursive.  This patch makes the recursive output
show tree objects as well.

This has the immediate benefit of making git-deltafy-script handle
deltafication of tree objects.

Signed-off-by: Nicolas Pitre <nico@cam.org>

diff --git a/diff-tree.c b/diff-tree.c
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -131,7 +131,10 @@ static int compare_tree_entry(void *tree
 
 	if (recursive && S_ISDIR(mode1)) {
 		int retval;
-		char *newbase = malloc_base(base, path1, pathlen1);
+		char *newbase;
+		if (!silent && !generate_patch)
+			diff_change(mode1, mode2, sha1, sha2, base, path1);
+		newbase = malloc_base(base, path1, pathlen1);
 		retval = diff_tree_sha1(sha1, sha2, newbase);
 		free(newbase);
 		return retval;
diff --git a/git-deltafy-script b/git-deltafy-script
--- a/git-deltafy-script
+++ b/git-deltafy-script
@@ -9,8 +9,6 @@
 # NOTE: the "best earlier version" is not implemented in mkdelta yet
 #       and therefore only the next eariler version is used at this time.
 #
-# TODO: deltafy tree objects as well.
-#
 # The -d argument allows to provide a limit on the delta chain depth.
 # If 0 is passed then everything is undeltafied.
 

Re: [PATCH] show changed tree objects with recursive git-diff-tree

[Junio C Hamano]

Although I do not have immediate objections to what it tries to
do, I have to think about the intent of the patch and its
ramifications.

However, I think the patch operates at the wrong level if you
are basing on the tip of Linus tree.  With the new diff core,
you do not filter like this:

-		char *newbase = malloc_base(base, path1, pathlen1);
+		char *newbase;
+		if (!silent && !generate_patch)
+			diff_change(mode1, mode2, sha1, sha2, base, path1);
+		newbase = malloc_base(base, path1, pathlen1);

I'd just say "if (!silent)" there.  The updated diff_change
_should_ do the right thing regardless of generate_patch value
you have there, because it is already told about it with
diff_setup(), and it knows not to say silly things when we are
generating patch.

Re: [PATCH] show changed tree objects with recursive git-diff-tree

[Linus Torvalds]

On Fri, 20 May 2005, Nicolas Pitre wrote:
>
> When -p is not used, git-diff-tree currently shows changed tree objects
> but only when not recursive.  This patch makes the recursive output
> show tree objects as well.

That sounds wrong. That would seem to make diff-helper confused, no? 

		Linus

Re: [PATCH] show changed tree objects with recursive git-diff-tree

[Linus Torvalds]

On Fri, 20 May 2005, Junio C Hamano wrote:
>
> Although I do not have immediate objections to what it tries to
> do, I have to think about the intent of the patch and its
> ramifications.

I really think it should be a totally separate flag to enable showing the
sub-trees if the tree-blobification wants this.

In fact, I can pretty much _guarantee_ that the patch as posted is the
wrong thing to do: it will do horribly wrong things for things like

	git-whatchanged arch/i386/kernel/head.S

(but I haven't tried it - try it yourself. The correct output for the 
kernel archive is just a single commit, and a single blob change in that 
commit).

My bet is that the patch will end up showing every single changeset that 
touches anything under "arch/", since such _trees_ will be marked as 
interesting. Which is absolutely the wrong thing to do.

Nico, try it, maybe you'll prove me wrong.


		Linus

Re: [PATCH] show changed tree objects with recursive git-diff-tree

[Junio C Hamano]

Diff heler _should_ not get confused, but maybe it currently
does.  If that is the case, I would consider that a bug (my
bad).

... goes back to the Linus tip for a while and comes back ...

Yup.  It says a change line containing tree is not something it
recognizes.  Sorry, there is a bug there (and another bug that
partially hides that bug).

I'm doing major rewrite of the diff-core right now but even
after that, diff helper _should_ just ignore trees.

In the meantime, this patch should fix it.  And this should be
the right fix even after the "major rewrite" I am doing now.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
# - linus: [PATCH] delta creation
# + (working tree)
diff --git a/diff-helper.c b/diff-helper.c
--- a/diff-helper.c
+++ b/diff-helper.c
@@ -20,7 +20,8 @@ static int parse_oneside_change(const ch
 		cp++;
 	}
 	*mode = m;
-	if (strncmp(cp, "\tblob\t", 6) && strncmp(cp, " blob ", 6))
+	if (strncmp(cp, "\ttree\t", 6) && strncmp(cp, " tree ", 6) &&
+	    strncmp(cp, "\tblob\t", 6) && strncmp(cp, " blob ", 6))
 		return -1;
 	cp += 6;
 	if (get_sha1_hex(cp, sha1))
@@ -44,11 +45,13 @@ static int parse_diff_raw_output(const c
 		diff_unmerge(cp + 1);
 		break;
 	case '+':
-		parse_oneside_change(cp, &new_mode, new_sha1, path);
+		if (parse_oneside_change(cp, &new_mode, new_sha1, path))
+			return -1;
 		diff_addremove('+', new_mode, new_sha1, path, NULL);
 		break;
 	case '-':
-		parse_oneside_change(cp, &old_mode, old_sha1, path);
+		if (parse_oneside_change(cp, &old_mode, old_sha1, path))
+			return -1;
 		diff_addremove('-', old_mode, old_sha1, path, NULL);
 		break;
 	case '*':
@@ -64,7 +67,8 @@ static int parse_diff_raw_output(const c
 			new_mode = (new_mode << 3) | (ch - '0');
 			cp++;
 		}
-		if (strncmp(cp, "\tblob\t", 6) && strncmp(cp, " blob ", 6))
+		if (strncmp(cp, "\tblob\t", 6) && strncmp(cp, " blob ", 6) &&
+		    (strncmp(cp, "\ttree\t", 6) && strncmp(cp, " tree ", 6)))
 			return -1;
 		cp += 6;
 		if (get_sha1_hex(cp, old_sha1))

Re: [PATCH] show changed tree objects with recursive git-diff-tree

[Nicolas Pitre]

[catching up after a weekind away -- you guys have not been standing still]

On Fri, 20 May 2005, Linus Torvalds wrote:

> On Fri, 20 May 2005, Junio C Hamano wrote:
> >
> > Although I do not have immediate objections to what it tries to
> > do, I have to think about the intent of the patch and its
> > ramifications.
> 
> I really think it should be a totally separate flag to enable showing the
> sub-trees if the tree-blobification wants this.
> 
> In fact, I can pretty much _guarantee_ that the patch as posted is the
> wrong thing to do: it will do horribly wrong things for things like
> 
> 	git-whatchanged arch/i386/kernel/head.S
> 
> (but I haven't tried it - try it yourself. The correct output for the 
> kernel archive is just a single commit, and a single blob change in that 
> commit).

OK.  What about the following patch?  It outputs changed tree objects 
only if -p nor -v nor -s is specified, i.e. whenever what is really 
wanted is output of what changed at the object level.  This makes it 
more coherent with the non-recursive output as well.  Checked that 
git-diff-helper doesn't get confused.

If a separate flag is really needed, then consistency dictates that the 
non recursive output should provide output for tree objects only when 
that flag is given as well, which makes the non recursive output rather 
useless in most cases.  And IMHO this is just too much burden for little 
benefit (the extra flag not the recursive tree object output).

=====

This patch includes output of modified tree objects to recursive output, 
just like non recursive output already does.  When -v, -s or -p  is 
specified then the recursive output supresses modified tree objects 
since they don't make much sense in that case.

Signed-off-by: Nicolas Pitre <nico@cam.org>

diff --git a/diff-tree.c b/diff-tree.c
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -127,6 +127,8 @@ static int compare_tree_entry(void *tree
 	if (recursive && S_ISDIR(mode1)) {
 		int retval;
 		char *newbase = malloc_base(base, path1, pathlen1);
+		if (!silent && !verbose_header && !show_root_diff)
+			diff_change(mode1, mode2, sha1, sha2, base, path1);
 		retval = diff_tree_sha1(sha1, sha2, newbase);
 		free(newbase);
 		return retval;

Re: [PATCH] show changed tree objects with recursive git-diff-tree

[Junio C Hamano]

Sorry, I did not get back to you earlier.

My only hesitation is that I'd rather want to see outputs from
"git-diff-tree -r $O $A" and "git-read-tree $A && git-diff-cache
--cached $O" exactly match by default, but this is quite minor (I
cannot even justify why myself).

As you already know, diff-helper knows it cannot do anything
about trees, so that is not a reason to fear your change.

That said, I have already acquired a habit of running diff-tree
with raw output to see what files have changed between two
trees, relying on the traditional behaviour of showing only
blobs and not trees, so turning this "tree" output on by default
is a minor nuisance to adjust to (it is minor --- I just need to
filter them out by looking at the first 7 bytes of each line).

How about this patch instead?  Does it do what you need?  My
understanding of your needs is that you do not like having to
call diff-tree (w/o recursive) only to get tree IDs involved,
because you are indeed interested in the whole tree and prefer
recursive behaviour; for that reason I made -t to imply -r.

Only lightly tested.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

diff --git a/diff-tree.c b/diff-tree.c
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -6,6 +6,7 @@ static int show_root_diff = 0;
 static int verbose_header = 0;
 static int ignore_merges = 1;
 static int recursive = 0;
+static int show_tree_entry_in_recursive = 0;
 static int read_stdin = 0;
 static int diff_output_format = DIFF_FORMAT_HUMAN;
 static int detect_rename = 0;
@@ -123,6 +124,8 @@ static int compare_tree_entry(void *tree
 	if (recursive && S_ISDIR(mode1)) {
 		int retval;
 		char *newbase = malloc_base(base, path1, pathlen1);
+		if (show_tree_entry_in_recursive)
+			diff_change(mode1, mode2, sha1, sha2, base, path1);
 		retval = diff_tree_sha1(sha1, sha2, newbase);
 		free(newbase);
 		return retval;
@@ -463,7 +466,7 @@ static int diff_tree_stdin(char *line)
 }
 
 static char *diff_tree_usage =
-"git-diff-tree [-p] [-r] [-z] [--stdin] [-M] [-C] [-R] [-S<string>] [-m] [-s] [-v] <tree-ish> <tree-ish>";
+"git-diff-tree [-p] [-r] [-z] [--stdin] [-M] [-C] [-R] [-S<string>] [-m] [-s] [-v] [-t] <tree-ish> <tree-ish>";
 
 int main(int argc, const char **argv)
 {
@@ -498,6 +501,10 @@ int main(int argc, const char **argv)
 			recursive = 1;
 			continue;
 		}
+		if (!strcmp(arg, "-t")) {
+			recursive = show_tree_entry_in_recursive = 1;
+			continue;
+		}
 		if (!strcmp(arg, "-R")) {
 			reverse_diff = 1;
 			continue;

diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -9,7 +9,7 @@ git-diff-tree - Compares the content and
 
 SYNOPSIS
 --------
-'git-diff-tree' [-p] [-r] [-z] [--stdin] [-M] [-R] [-C] [-S<string>] [-m] [-s] [-v] <tree-ish> <tree-ish> [<pattern>]\*
+'git-diff-tree' [-p] [-r] [-z] [--stdin] [-M] [-R] [-C] [-S<string>] [-m] [-s] [-v] [-t] <tree-ish> <tree-ish> [<pattern>]\*
 
 DESCRIPTION
 -----------
@@ -48,6 +48,9 @@ OPTIONS
 -r::
 	recurse
 
+-t::
+	show tree entry itself as well as subtrees.  Implies -r.
+
 -z::
 	\0 line termination on output
 

Re: [PATCH] show changed tree objects with recursive git-diff-tree

[Nicolas Pitre]

On Tue, 24 May 2005, Junio C Hamano wrote:

> How about this patch instead?  Does it do what you need?  My
> understanding of your needs is that you do not like having to
> call diff-tree (w/o recursive) only to get tree IDs involved,
> because you are indeed interested in the whole tree and prefer
> recursive behaviour; for that reason I made -t to imply -r.

Yes, that does what I need, thanks.

Now there is only the minor inconsistency that the recursive output 
without -t doesn't display tree objects while the non recursive output 
does output tree objects regardless.  Do we care?


Nicolas

Re: [PATCH] show changed tree objects with recursive git-diff-tree

[Junio C Hamano]

>>>>> "NP" == Nicolas Pitre <nico@cam.org> writes:

NP> Now there is only the minor inconsistency that the recursive output 
NP> without -t doesn't display tree objects while the non recursive output 
NP> does output tree objects regardless.  Do we care?

Hmph.  I agree, although I do not care about that much myself
enough to start coding right now.  With luck I may have
something by tomorrow morning US Pacific time though.