git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH and RFC] gitweb: Remove --full-history from git_history
@ 2006-08-09 10:57 Jakub Narebski
  2006-08-09 11:09 ` Junio C Hamano
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Jakub Narebski @ 2006-08-09 10:57 UTC (permalink / raw)
  To: git

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@gmail.com>
---
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

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

end of thread, other threads:[~2006-08-14 11:10 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-08-09 10:57 [PATCH and RFC] gitweb: Remove --full-history from git_history Jakub Narebski
2006-08-09 11:09 ` Junio C Hamano
2006-08-09 12:04   ` Jakub Narebski
2006-08-09 12:56     ` Jakub Narebski
2006-08-09 19:28 ` Fredrik Kuivinen
2006-08-09 20:08   ` Johannes Schindelin
2006-08-09 21:42   ` Junio C Hamano
2006-08-10 10:46     ` Jakub Narebski
2006-08-10 21:39     ` Fredrik Kuivinen
2006-08-14 11:10 ` Jakub Narebski

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).