From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Subject: [PATCH and RFC] gitweb: Remove --full-history from git_history
Date: Wed, 9 Aug 2006 12:57:19 +0200 [thread overview]
Message-ID: <200608091257.19461.jnareb@gmail.com> (raw)
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 reply other threads:[~2006-08-09 10:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-09 10:57 Jakub Narebski [this message]
2006-08-09 11:09 ` [PATCH and RFC] gitweb: Remove --full-history from git_history 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200608091257.19461.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.