gitweb: Fix "Use of uninitialized value" error in 'history' view

When asked for history of a file with no $hash ('h') parameter set, and which file is not present in current branch ("HEAD" or given by $hash_hase ('hb') parameter), but is present deeper in the full history of a branch, gitweb would spew multiple of "Use of uninitialized value" warnings, and some links would be missing. This commit fixes this bug.

This bug occurs in the rare cases when "git log -- <path>" is empty and "git log --full-history -- <path>" is not. Gitweb tried to get file type (it means if it is 'tree' or 'blob' or even 'commit', as 'history' view is for single path which can be any of given types) from the commit we start searching from, and not among found commits.

While we are it, return error if there is _no_ history; it means that file or directory was not found (for given branch). Also error out if type of item could not be found: it should not happen now, but better be sure.

---
There should be no noticeable changes in performance for situation when bug described above does not occur; gitweb would use one git command invocation than strictly necessary in the situation which previosly generated bug. As it should be rare situation (handcrafted URL, or "current version" URL for file which got deleted) I think it is not worth complicating the code to avoid it.

BTW. the t9500-gitweb-standalone-no-errors test does not catch this bug, unfortunately...

 gitweb/gitweb.perl |   18 +++++++++++++++---
 1 files changed, 15 insertions(+), 3 deletions(-)

index 50922bc..1be75c6 100755
@@ -5238,14 +5238,26 @@ sub git_history {
 	my $refs = git_get_references();
 	my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
 
+	my @commitlist = parse_commits($hash_base, 101, (100 * $page),
+	                               $file_name, "--full-history");
+	if (!@commitlist) {
+		die_error(undef, "No such path");
+	}
+
 	if (!defined $hash && defined $file_name) {
-		$hash = git_get_hash_by_path($hash_base, $file_name);
+		# some commits could have deleted file in question,
+		# and not have it in tree, but one of them has to have it
+		for (my $i = 0; $i <= @commitlist; $i++) {
+			$hash = git_get_hash_by_path($commitlist[$i]{'id'}, $file_name);
+			last if defined $hash;
+		}
 	}
 	if (defined $hash) {
 		$ftype = git_get_type($hash);
 	}
-
-	my @commitlist = parse_commits($hash_base, 101, (100 * $page), $file_name, "--full-history");
+	if (!defined $ftype) {
+		die_error(undef, "Unknown type of object");
+	}
 
 	my $paging_nav = '';
 	if ($page > 0) {

1.5.4.4

Do you know whether this fixes http://bugs.debian.org/469083 too? I took a short look back then to fix it, but didn't manage it in a reasonable amount of time.

Thanks, Gerrit.

No it does not.

I have found what causes this bug. When adding is_deleted() subroutine I have forgot about old/legacy URL support[1], where gitweb doesn't have enough information to get raw diff info, and gitweb has to generate required info itself, i.e. the part in git_blobdiff(), around

	# old/legacy style URI
	if (!%diffinfo && # if new style URI failed
	    defined $hash && defined $hash_parent) {
		# fake git-diff-tree raw output
		$diffinfo{'from_mode'} = $diffinfo{'to_mode'} = "blob";
		$diffinfo{'from_id'} = $hash_parent;
		$diffinfo{'to_id'}   = $hash;

This code does not, and cannot, fill 'status_str' ('status' is faked). I'd send in a bit patch fixing this bug (making is_deleted() more robust).

Footnotes:
==========
[1] Note that example URL in http://bugs.debian.org/469083 does not have 'hpb' ($hash_parent_base) parameter set... and that is what causes this bug.

P.S. Gerrit, are you maintainer of git-core debian package?

Jakub Narebski
Poland

It should be enough to revert commit 6aa6f92 (gitweb: Add 'status_str' to parse_difftree_raw_line output); it should fix this bug.

P.S. Mentioned commit was done for micro-optimization: "<str> =~ /D/" is a bit faster than "<str> eq ('0' x 40)" in the case when it doesn't match.

Jakub Narebski
Poland

This reverts commit 6aa6f92fda47cc4ee5f599895e8a5a327fb6f9ab.

It caused is_deleted() subroutine to output warnings when dealing with old, legacy gitweb blobdiff URLs without either 'hb' or 'hpb' parameters.

This fixes http://bugs.debian.org/469083

---

And here it is...

 gitweb/gitweb.perl |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

index 1be75c6..1501ec8 100755
@@ -2204,7 +2204,7 @@ sub parse_difftree_raw_line {
 		$res{'to_mode'} = $2;
 		$res{'from_id'} = $3;
 		$res{'to_id'} = $4;
-		$res{'status'} = $res{'status_str'} = $5;
+		$res{'status'} = $5;
 		$res{'similarity'} = $6;
 		if ($res{'status'} eq 'R' || $res{'status'} eq 'C') { # renamed or copied
 			($res{'from_file'}, $res{'to_file'}) = map { unquote($_) } split("\t", $7);

@@ -2220,7 +2220,6 @@ sub parse_difftree_raw_line {
 		$res{'to_mode'} = pop @{$res{'from_mode'}};
 		$res{'from_id'} = [ split(' ', $3) ];
 		$res{'to_id'} = pop @{$res{'from_id'}};
-		$res{'status_str'} = $4;
 		$res{'status'} = [ split('', $4) ];
 		$res{'to_file'} = unquote($5);
 	}

@@ -3068,7 +3067,7 @@ sub fill_from_file_info {
 sub is_deleted {
 	my $diffinfo = shift;
 
-	return $diffinfo->{'status_str'} =~ /D/;
+	return $diffinfo->{'to_id'} eq ('0' x 40);
 }
 
 # does patch correspond to [previous] difftree raw line

1.5.4.4

Thanks a lot.

Yes, I take responsibility for the git Debian packages.

Regards, Gerrit.

Thanks, does gitweb itself generate such a link?

I can _artificially_ reproduce this, and I can also see that the patch would solve it, so I do not mind applying it, but I am curious how this was originally triggered.

Actually I came across this error when testing the "context-sensitive feed links" patch, and was hand-crafting (munging) gitweb URLs.

But after thinking about this bug a bit I have realized that this situation _can_ happen with link generated by gitweb, only in very rare cases. It is enough if you use 'history' view link without $hash ('h') parameter, and with transient $hash_base ('hb') parameter, i.e. either name of branch, or "HEAD", or not set (implies "HEAD"), and happen into situation where file was _deleted_ *between* gitweb link creation and following (accessing) this link. For example 'history' links in 'tree' and 'commitdiff' views doesn't have 'h' parameter. Also the 'history' link in navigation bar wouldn't have 'h' parameter if 'blob' or 'tree' view where it is in doesn't have it.

Jakub Narebski
Poland