git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jakub Narebski <jnareb@gmail.com>
Date
Aug 9, 2006, 10:57 UTC
Message-ID
<200608091257.19461.jnareb@gmail.com>

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
Next: Junio C Hamano
Message 1 of 10 in “gitweb: Remove --full-history from git_history”
  1. gitweb: Remove --full-history from git_historyJakub Narebski, Aug 9, 2006
  2. Junio C HamanoAug 9, 2006
  3. Jakub NarebskiAug 9, 2006
  4. Jakub NarebskiAug 9, 2006
  5. Fredrik KuivinenAug 9, 2006
  6. Johannes SchindelinAug 9, 2006
  7. Junio C HamanoAug 9, 2006
  8. Jakub NarebskiAug 10, 2006
  9. Fredrik KuivinenAug 10, 2006
  10. Jakub NarebskiAug 14, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.