[PATCH and RFC] gitweb: Remove --full-history from git_history

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stop pretending that gitweb is rename-aware, and remove --full-history
option to git-rev-list in git_history (for "history" action):

 * gitweb cannot handle renames as of yet; it uses constant original
   $file_name as 'f' argument in links
 * at least for git 1.4.1.1 --full-history option doesn't follow
   renames (check 'git rev-list next -- gitweb/test/file+plus+sign'
   with and without --full-history option and compare to
   'git rev-list next -- gitweb/test/file+plus+sign test/file+plus+sign')
   and is three times slower than git-rev-list without --full-history

Signed-off-by: Jakub Narebski <jnareb@xxxxxxxxx>
---
This is call for better rename support in git (better than --full-history).
There was such an attempt in "[RFC, PATCH] Teach revision.c about renames"
by Fredrik Kuivinen
  http://marc.theaimsgroup.com/?l=git&m=114772921317920
but IIRC patch was dropped in the favor of --full-history option.

What is needed by gitweb is for git-rev-list to not only follow revisions
of file contents across renames, and return more revisions, but also
return _how_ filename changes, without need to call git-diff-tree on each
returned revision.

PROPOSAL:
---------

Implement --follow/--follow-path/--follow-contents option to git-rev-list,
which would output besides revision ids also current path limit; the format
could be for example:

  <commit> [ -- <paths>...]

for example:
$ git rev-list --follow db58b69ba -- gitweb/test/file+plus+sign
0a8f4f0020cb35095005852c0797f0b90e9ebb74 -- gitweb/test/file+plus+sign
85852d44e48c1d1c6d815cc5fccf1b580f2f2cad -- test/file+plus+sign
cc3245b6512a01d74c0fd460d762ba8a1e8b968a -- test/file+plus+sign

There might be better format, as the proposed isn't best for copying
detections support, as path limit gets larger and one cannot immediately
get which element of new <paths>... correspond to which original <paths>...
element. Same with splitting file vs. simply creating file.

It should be not that hard to implement, just detecting copying, renaming
and filename vanishing, and updating current path limit; or putting
modified path limit and revision to start modified path-limit from to
the queue...


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

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ae13e3e..59222c2 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2284,7 +2284,7 @@ sub git_history {
 	git_print_page_path($file_name, $ftype);
 
 	open my $fd, "-|",
-		$GIT, "rev-list", "--full-history", $hash_base, "--", $file_name;
+		$GIT, "rev-list", $hash_base, "--", $file_name;
 	print "<table cellspacing=\"0\">\n";
 	my $alternate = 0;
 	while (my $line = <$fd>) {
-- 
1.4.1.1

-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]