Problems with binary patches (pull) and spaces in filenames (gitk)

Problems with binary patches (pull) and spaces in filenames (gitk)

[Peter Eriksen]

Hello,

I've got a nice project, where I am tracking both binary files and
filenames with spaces.  So, I've noticed two small cosmetic bugs:

1) When pulling an updated binary files, I guess it still tries to 
   print this update summary by making and processing patches, and so
   gives this error:

       Updating from ab1c4033ba98c043e13da3446e7f244ac7f79942 to
       c164231f6b59fd80171e95f31d762a80d884c708.
       Fast forward
       fatal: patch with only garbage at line 3249

2) When there are spaces in filenames, gitk only shows the first part of
   the name in the filelist at the buttom right.


Regards,

Peter

Re: Problems with binary patches (pull) and spaces in filenames (gitk)

[Junio C Hamano]

"Peter Eriksen" <s022018@student.dtu.dk> writes:

> 1) When pulling an updated binary files, I guess it still tries to 
>    print this update summary by making and processing patches, and so
>    gives this error:
>
>        Updating from ab1c4033ba98c043e13da3446e7f244ac7f79942 to
>        c164231f6b59fd80171e95f31d762a80d884c708.
>        Fast forward
>        fatal: patch with only garbage at line 3249

Hmm.  Perhaps a suboption to git-apply --stat to tell it not to
barf is helpful?  In the meantime, could you pull with -n flag?

> 2) When there are spaces in filenames, gitk only shows the first part of
>    the name in the filelist at the buttom right.

Another minor gitk gripe I have is that it does not look at
subdirectories of refs/{heads,tags}/ so I do not get labels to
my topic branch heads.

Re: Problems with binary patches (pull) and spaces in filenames (gitk)

[Linus Torvalds]

On Wed, 9 Nov 2005, Peter Eriksen wrote:
> 
> 1) When pulling an updated binary files, I guess it still tries to 
>    print this update summary by making and processing patches, and so
>    gives this error:
> 
>        Updating from ab1c4033ba98c043e13da3446e7f244ac7f79942 to
>        c164231f6b59fd80171e95f31d762a80d884c708.
>        Fast forward
>        fatal: patch with only garbage at line 3249

Yes, this is "git-apply --stat" being unhappy about an empty patch.

Maybe we should only be unhappy when actually trying to apply (or check) 
the patch.

So a patch like the appended may or may not be the right solution.

> 2) When there are spaces in filenames, gitk only shows the first part of
>    the name in the filelist at the buttom right.

Can't help you there, that's more tcl/tk than I know. Paul?

		Linus

---
diff --git a/apply.c b/apply.c
index 3e53b34..da1416a 100644
--- a/apply.c
+++ b/apply.c
@@ -890,7 +890,7 @@ static int parse_chunk(char *buffer, uns
 
 	patchsize = parse_single_patch(buffer + offset + hdrsize, size - offset - hdrsize, patch);
 
-	if (!patchsize && !metadata_changes(patch))
+	if ((check ||apply) && !patchsize && !metadata_changes(patch))
 		die("patch with only garbage at line %d", linenr);
 
 	return offset + hdrsize + patchsize;

Re: Problems with binary patches (pull) and spaces in filenames (gitk)

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Hmm.  Perhaps a suboption to git-apply --stat to tell it not to
> barf is helpful?  In the meantime, could you pull with -n flag?

Would this help?

-- >8 -- cut here -- >8 --
[PATCH] git-apply: do not barf on binary diff when not applying.

Instead, just mark the patch as binary, and keep going when
doing --stat and --summary.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/apply.c b/apply.c
index 3e53b34..6d756f7 100644
--- a/apply.c
+++ b/apply.c
@@ -53,7 +53,7 @@ struct fragment {
 struct patch {
 	char *new_name, *old_name, *def_name;
 	unsigned int old_mode, new_mode;
-	int is_rename, is_copy, is_new, is_delete;
+	int is_rename, is_copy, is_new, is_delete, is_binary;
 	int lines_added, lines_deleted;
 	int score;
 	struct fragment *fragments;
@@ -890,8 +890,18 @@ static int parse_chunk(char *buffer, uns
 
 	patchsize = parse_single_patch(buffer + offset + hdrsize, size - offset - hdrsize, patch);
 
-	if (!patchsize && !metadata_changes(patch))
-		die("patch with only garbage at line %d", linenr);
+	if (!patchsize && !metadata_changes(patch)) {
+		static const char binhdr[] = "Binary files ";
+
+		if (sizeof(binhdr) - 1 < size - offset - hdrsize &&
+		    !memcmp(binhdr, buffer + hdrsize, sizeof(binhdr)-1))
+			patch->is_binary = 1;
+
+		if (patch->is_binary && !apply)
+			;
+		else
+			die("patch with only garbage at line %d", linenr);
+	}
 
 	return offset + hdrsize + patchsize;
 }
@@ -949,9 +959,12 @@ static void show_stats(struct patch *pat
 		add = (add * max + max_change / 2) / max_change;
 		del = total - add;
 	}
-	printf(" %s%-*s |%5d %.*s%.*s\n", prefix,
-		len, name, patch->lines_added + patch->lines_deleted,
-		add, pluses, del, minuses);
+	if (patch->is_binary)
+		printf(" %s%-*s |  Bin\n", prefix, len, name);
+	else
+		printf(" %s%-*s |%5d %.*s%.*s\n", prefix,
+		       len, name, patch->lines_added + patch->lines_deleted,
+		       add, pluses, del, minuses);
 	if (qname)
 		free(qname);
 }

Re: Problems with binary patches (pull) and spaces in filenames (gitk)

[Jan Harkes]

On Wed, Nov 09, 2005 at 02:09:41PM -0800, Junio C Hamano wrote:
> Another minor gitk gripe I have is that it does not look at
> subdirectories of refs/{heads,tags}/ so I do not get labels to
> my topic branch heads.

I've been using the following gitk 'customization'. ISTR that it can be
cleaned up a bit further and do everything in a single scan of the refs/
subtree. I'll take another look at that tonight.

Jan

diff --git a/gitk b/gitk
index a9d37d9..cd0b84f 100755
--- a/gitk
+++ b/gitk
@@ -237,16 +237,27 @@ proc parsecommit {id contents listed old
 			     $comname $comdate $comment]
 }
 
+# recursively list all files in a directory
+proc listTree {root} {
+    set files [glob -nocomplain -directory $root -types f *]
+    set nodes [glob -nocomplain -directory $root -types d *]
+    foreach node $nodes {
+	set children [listTree $node]
+	set files [concat $files $children]
+    }
+    return $files
+}
+
 proc readrefs {} {
     global tagids idtags headids idheads tagcontents
 
-    set tags [glob -nocomplain -types f [gitdir]/refs/tags/*]
+    set tags [listTree [gitdir]/refs/tags]
     foreach f $tags {
 	catch {
 	    set fd [open $f r]
 	    set line [read $fd]
 	    if {[regexp {^[0-9a-f]{40}} $line id]} {
-		set direct [file tail $f]
+		regexp {[gitdir]/refs/tags/(.*)} $f match direct
 		set tagids($direct) $id
 		lappend idtags($id) $direct
 		set tagblob [exec git-cat-file tag $id]
@@ -271,13 +282,13 @@ proc readrefs {} {
 	    close $fd
 	}
     }
-    set heads [glob -nocomplain -types f [gitdir]/refs/heads/*]
+    set heads [listTree [gitdir]/refs/heads]
     foreach f $heads {
 	catch {
 	    set fd [open $f r]
 	    set line [read $fd 40]
 	    if {[regexp {^[0-9a-f]{40}} $line id]} {
-		set head [file tail $f]
+		regexp {[gitdir]/refs/heads/(.*)} $f match head
 		set headids($head) $line
 		lappend idheads($line) $head
 	    }

Re: Problems with binary patches (pull) and spaces in filenames (gitk)

[Peter Eriksen]

On Wed, Nov 09, 2005 at 02:36:09PM -0800, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
> 
> > Hmm.  Perhaps a suboption to git-apply --stat to tell it not to
> > barf is helpful?  In the meantime, could you pull with -n flag?
> 
> Would this help?
> 
> -- >8 -- cut here -- >8 --
> [PATCH] git-apply: do not barf on binary diff when not applying.

Yes, it seems to work.  With my example it now shows the diff stats and
puts a "Bin" instead of the number of line changed.  It could show the
change in the size, but as it is, it's fine with me.  Please apply.

Peter