* Re: Revisiting large binary files issue.
From: Linus Torvalds @ 2006-07-11 17:09 UTC (permalink / raw)
To: Carl Baldwin, Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <20060711145527.GA32468@hpsvcnb.fc.hp.com>
On Tue, 11 Jul 2006, Carl Baldwin wrote:
>
> I'd like to get my hands dirty and see for myself where the issue lies.
> I hope to have some time next week to devote to this. Is it reasonable
> to hope for a solution that is at least a lot lighter weight than the
> current status quo?
Ok, I decided to see how nasty an object database change would be.
It doesn't look too bad. The following three patches implement what looks
like a workable model.
NOTE NOTE NOTE! It makes the new "binary headers" the default, and that
will mean that unless you have applied the first two patches, any
repository that has had objects added with the new git version WILL NOT BE
READABLE BY AN OLDER GIT VERSION!
So I think that the first two patches can be added to the main git branch
pretty much immediately (after people have tested this all a _bit_ more,
of course), because the first two patches just add the capability to
_read_ a mixed-format repository.
The third patch is the one that actually starts _writing_ new-format repo.
It should be applied with extreme care, although it can basically be
de-fanged by setting the default initial value of the "use_binary_headers"
to 0, which will make it not write the binary headers by default.
I have _not_ verified that the actual object format is identical to the
pack-file one, but it should be. It's simple enough.
The three patches will be sent as replies to this email.
Linus
^ permalink raw reply
* Re: [PATCH] Install built-ins as symlinks
From: Alp Toker @ 2006-07-11 14:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607111614550.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>> Doing this now will save headache in the long run, avoiding mismatched
>> versions of installed utilities and dangling copies of removed or
>> renamed git commands that still appear to work. It also makes screwups
>> when packaging git or making system backups less likely.
>
> Could we please fix things, which are broken? Not things which work?
There are maybe a dozen arguments for and against the use of symlinks
here, some of which Andreas has helpfully explained in his reply. You,
on the other hand, have managed not to mention a single one of them.
If you don't have the technical background to review a certain patch,
please don't add to the noise.
^ permalink raw reply
* Re: Revisiting large binary files issue.
From: Carl Baldwin @ 2006-07-11 14:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607101623230.5623@g5.osdl.org>
I'd like to get my hands dirty and see for myself where the issue lies.
I hope to have some time next week to devote to this. Is it reasonable
to hope for a solution that is at least a lot lighter weight than the
current status quo?
Carl
On Mon, Jul 10, 2006 at 04:28:24PM -0700, Linus Torvalds wrote:
>
>
> On Mon, 10 Jul 2006, Carl Baldwin wrote:
> >
> > When I set the window to 0 I one more issue. Even though the blobs are
> > already compressed on disk I still seem to pay the penalty of inflating
> > them into memory and then deflating them into the pack. When the window
> > size is 0 this is just wasted cycles. With large binary files these
> > wasted cycles slow down the push/fetch operation considerably. Couldn't
> > the compressed blobs be copied into the pack without first deflating
> > them in this 0 window case?
>
> The problem is that the individual object disk format isn't actually the
> same as the pack-file object format for one object. The header is
> different: a pack-file uses a very dense bit packing, while the individual
> object format is a bit less dense.
>
> Sad, really, but it means that right now you can only re-use data that was
> already packed (when the format matches).
>
> Linus
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin RADCAD (R&D CAD)
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: Revisiting large binary files issue.
From: Peter Baumann @ 2006-07-11 6:20 UTC (permalink / raw)
To: git
In-Reply-To: <7v7j2l833o.fsf@assigned-by-dhcp.cox.net>
On 2006-07-10, Junio C Hamano <junkio@cox.net> wrote:
> Carl Baldwin <cnb@fc.hp.com> writes:
>
>> First, I would like to be able to set the packing window to 0 for all of
>> the git commands. It would be nice if I could set this in a
>> per-repository config file so that any push/fetch operation would honor
>> this window. Is there currently a way to do this?
>
> Should not be hard to add.
>
>> Second, I would like to not pay the penalty to inflate and then deflate
>> the objects into the pack when I use a window of 0. How hard would this
>> be? I am a capable programmer and wouldn't mind getting my hands dirty
>> in the code to implement this if someone could point me in the right
>> direction.
>
> The problem is that unpacked objects have the single line header
> (type followed by its inflated size in decimal) which starts the
> deflated stream, while in-pack representation of non-delta does
> not.
>
> There was an attempt to help doing this, but I haven't pursued it.
>
> http://article.gmane.org/gmane.comp.version-control.git/17368
>
>
Wouldn't it make more sense to convert the unpacked object reprasentation
to the one which is used in the pack files?
This would make it really easy to just copy the object in the non-delta
case to the pack and avoid the inflate/deflate calls.
Peter Baumann
^ permalink raw reply
* Re: merge-base: update the clean-up postprocessing
From: Johannes Schindelin @ 2006-07-11 14:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, A Large Angry SCM
In-Reply-To: <7vpsgc4kze.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 11 Jul 2006, Junio C Hamano wrote:
> * The difference in processing time for 941 two-head merges
> with both versions is lost within margin of error.
You convinced me.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Install built-ins as symlinks
From: Johannes Schindelin @ 2006-07-11 14:16 UTC (permalink / raw)
To: Alp Toker; +Cc: git
In-Reply-To: <11526131792377-git-send-email-alp@atoker.com>
Hi,
On Tue, 11 Jul 2006, Alp Toker wrote:
> Doing this now will save headache in the long run, avoiding mismatched
> versions of installed utilities and dangling copies of removed or
> renamed git commands that still appear to work. It also makes screwups
> when packaging git or making system backups less likely.
Could we please fix things, which are broken? Not things which work?
Ciao,
Dscho
^ permalink raw reply
* Re: Why doesn't git-rerere automatically commit a resolution?
From: Shawn Pearce @ 2006-07-11 13:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xn06310.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Not merging the index after rerere re-applies a previous
> resolution to the working tree file is a deliberate design
> decision. During conflict resolution, "git diff" against
> unmerged index file is the second most useful command to check
> your hand-merge result, and running update-index on these path
> automatically robs this useful tool from the user. So, in order
> to help more disciplined workflow, a bit of convenience for
> lazier people is sacrficed here.
OK, I agree with all of the above. Except in the following case:
git update-ref BACKUP HEAD
git pull . sp/topicA
git pull . sp/topicB
..fix conflicts..
git commit -F .git/MERGE_MSG
git reset --hard BACKUP
git pull . sp/topicA
git pull . sp/topicB
..ah, come on!..
By pulling the exact same two heads together in the exact same
order I would expect the exact same merge result. And since I
have git-rerere enabled I would expect it to autocommit the result
of the merge as I have already checked it before and verified its
correct when I first fixed the conflicts.
After reading your message I agree with you however that pulling in
the reverse direction (e.g. topicB then topicA) shouldn't autocommit
the merge result as I haven't hand verified it to be correct - yet.
However if I do and I merge it again later with the same two commits
then it should still be correct.
Further if I alter sp/topicA by changing a file path which wasn't
conflicted in the merge with sp/topicB I would expect it to
carry out the merge assuming the conflicts were remembered as-is.
Because that's what a trivial in-index merge would do and that will
commit despite conflicts possibly existing between files.
I guess what I'm saying is maybe git-rerere (or git-merge in general)
could benefit from a slightly higher level cache. Store 4 sets
of (mode, sha1) tuples: stage1 stage2 stage3 result in a cache
somewhere. If you get a conflicted merge which has been previously
fixed by hand wherein all 3 stages in the index are found in the
cache then update the index and working directory with the result
(mode, sha1) tuple.
If any of the 3 stages differs then fall back to git-rerere and
attempt a file level merge, stopping before commit to allow the
user to verify (and possibly correct) the resulting merge.
One advantage of this higher level cache is it can be used for
binary files which `merge` can't normally process, as well as for
structual conflicts.
Thoughts? I can prototype this higher level cache into git-rerere
later tonight after I get home from work.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] gitweb: Include a site name in page titles
From: Martin Langhoff @ 2006-07-11 11:48 UTC (permalink / raw)
To: Alp Toker; +Cc: git
In-Reply-To: <1152613179634-git-send-email-alp@atoker.com>
> +# name of your site or organization to appear in page titles
> +our $site_name = "Untitled";
I generally agree, but as a default, $ENV{SERVER_NAME} should be better.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] Install built-ins as symlinks
From: Andreas Ericsson @ 2006-07-11 11:15 UTC (permalink / raw)
To: Alp Toker; +Cc: git
In-Reply-To: <11526131792377-git-send-email-alp@atoker.com>
Alp Toker wrote:
> Doing this now will save headache in the long run, avoiding mismatched
> versions of installed utilities and dangling copies of removed or
> renamed git commands that still appear to work. It also makes screwups
> when packaging git or making system backups less likely.
>
> BusyBox has been doing it this way for years.
>
Git has been doing it for a couple of months, although it uses hardlinks
instead of symlinks. Hardlinks are slightly faster and actually consume
a little less hard-disk space, although the differences are so small you
won't notice it unless you do several thousand invocations.
>
> $(BUILT_INS): git$X
> - rm -f $@ && ln git$X $@
> + ln -sf git$X $@
>
The -f option to ln is not very portable, hence the "rm && ln" construct.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] Install built-ins as symlinks
From: Alp Toker @ 2006-07-11 10:19 UTC (permalink / raw)
To: git
In-Reply-To: <11526131792773-git-send-email-alp@atoker.com>
Doing this now will save headache in the long run, avoiding mismatched
versions of installed utilities and dangling copies of removed or
renamed git commands that still appear to work. It also makes screwups
when packaging git or making system backups less likely.
BusyBox has been doing it this way for years.
Signed-off-by: Alp Toker <alp@atoker.com>
---
Makefile | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 5b7bac8..cb5a5cc 100644
--- a/Makefile
+++ b/Makefile
@@ -538,7 +538,7 @@ git$X: git.c common-cmds.h $(BUILTIN_OBJ
builtin-help.o: common-cmds.h
$(BUILT_INS): git$X
- rm -f $@ && ln git$X $@
+ ln -sf git$X $@
common-cmds.h: Documentation/git-*.txt
./generate-cmdlist.sh > $@+
@@ -748,7 +748,7 @@ install: all
cp '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
'$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
fi
- $(foreach p,$(BUILT_INS), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
+ $(foreach p,$(BUILT_INS), ln -sf 'git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
install-doc:
$(MAKE) -C Documentation install
--
1.4.1.g97c7-dirty
^ permalink raw reply related
* [PATCH] gitweb: Include a site name in page titles
From: Alp Toker @ 2006-07-11 10:19 UTC (permalink / raw)
To: git
In-Reply-To: <11526131781900-git-send-email-alp@atoker.com>
Tip Of The Day:
<title>: the most important element of a quality Web page.
This helps users tell one 'git' bookmark apart from the other in their
browser and improves the indexing of gitweb sites in Web search engines.
Signed-off-by: Alp Toker <alp@atoker.com>
---
gitweb/gitweb.cgi | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index bd9b9de..b12417b 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -46,6 +46,9 @@ if (! -d $git_temp) {
# target of the home link on top of all pages
our $home_link = $my_uri;
+# name of your site or organization to appear in page titles
+our $site_name = "Untitled";
+
# html text to include at home page
our $home_text = "indextext.html";
@@ -280,7 +283,7 @@ sub git_header_html {
my $status = shift || "200 OK";
my $expires = shift;
- my $title = "git";
+ my $title = "$site_name git";
if (defined $project) {
$title .= " - $project";
if (defined $action) {
@@ -1770,7 +1773,7 @@ sub git_opml {
print "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n".
"<opml version=\"1.0\">\n".
"<head>".
- " <title>Git OPML Export</title>\n".
+ " <title>$site_name Git OPML Export</title>\n".
"</head>\n".
"<body>\n".
"<outline text=\"git RSS feeds\">\n";
--
1.4.1.g97c7-dirty
^ permalink raw reply related
* [PATCH] gitweb: Use the git binary in the search path by default
From: Alp Toker @ 2006-07-11 10:19 UTC (permalink / raw)
To: git
In-Reply-To: <1152613179634-git-send-email-alp@atoker.com>
Introduce a sensible default for the location of the git binary used by
gitweb. This means one less option to configure when deploying gitweb if
git is in the search path.
This patch also makes invocations of core git commands go through the
'git' binary itself, which might help system administrators lock down
their CGI environment for security.
Signed-off-by: Alp Toker <alp@atoker.com>
---
gitweb/gitweb.cgi | 61 ++++++++++++++++++++++++-----------------------------
1 files changed, 28 insertions(+), 33 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index b12417b..0bb46b9 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -22,20 +22,15 @@ our $my_url = $cgi->url();
our $my_uri = $cgi->url(-absolute => 1);
our $rss_link = "";
-# location of the git-core binaries
-our $gitbin = "/usr/bin";
+# core git binary to use, optionally specified as an absolute path
+our $GIT = "git";
# absolute fs-path which will be prepended to the project path
#our $projectroot = "/pub/scm";
our $projectroot = "/home/kay/public_html/pub/scm";
-# version of the git-core binaries
-our $git_version = qx($gitbin/git --version);
-if ($git_version =~ m/git version (.*)$/) {
- $git_version = $1;
-} else {
- $git_version = "unknown";
-}
+# version of the core git binary
+our $git_version = qx($GIT --version) =~ m/git version (.*)$/ ? $1 : "unknown";
# location for temporary files needed for diffs
our $git_temp = "/tmp/gitweb";
@@ -391,7 +386,7 @@ sub die_error {
sub git_get_type {
my $hash = shift;
- open my $fd, "-|", "$gitbin/git-cat-file -t $hash" or return;
+ open my $fd, "-|", "$GIT cat-file -t $hash" or return;
my $type = <$fd>;
close $fd or return;
chomp $type;
@@ -403,7 +398,7 @@ sub git_read_head {
my $oENV = $ENV{'GIT_DIR'};
my $retval = undef;
$ENV{'GIT_DIR'} = "$projectroot/$project";
- if (open my $fd, "-|", "$gitbin/git-rev-parse", "--verify", "HEAD") {
+ if (open my $fd, "-|", $GIT, "rev-parse", "--verify", "HEAD") {
my $head = <$fd>;
close $fd;
if (defined $head && $head =~ /^([0-9a-fA-F]{40})$/) {
@@ -443,7 +438,7 @@ sub git_read_tag {
my %tag;
my @comment;
- open my $fd, "-|", "$gitbin/git-cat-file tag $tag_id" or return;
+ open my $fd, "-|", "$GIT cat-file tag $tag_id" or return;
$tag{'id'} = $tag_id;
while (my $line = <$fd>) {
chomp $line;
@@ -515,7 +510,7 @@ sub git_read_commit {
@commit_lines = @$commit_text;
} else {
$/ = "\0";
- open my $fd, "-|", "$gitbin/git-rev-list --header --parents --max-count=1 $commit_id" or return;
+ open my $fd, "-|", "$GIT rev-list --header --parents --max-count=1 $commit_id" or return;
@commit_lines = split '\n', <$fd>;
close $fd or return;
$/ = "\n";
@@ -613,7 +608,7 @@ sub git_diff_print {
if (defined $from) {
$from_tmp = "$git_temp/gitweb_" . $$ . "_from";
open my $fd2, "> $from_tmp";
- open my $fd, "-|", "$gitbin/git-cat-file blob $from";
+ open my $fd, "-|", "$GIT cat-file blob $from";
my @file = <$fd>;
print $fd2 @file;
close $fd2;
@@ -624,7 +619,7 @@ sub git_diff_print {
if (defined $to) {
$to_tmp = "$git_temp/gitweb_" . $$ . "_to";
open my $fd2, "> $to_tmp";
- open my $fd, "-|", "$gitbin/git-cat-file blob $to";
+ open my $fd, "-|", "$GIT cat-file blob $to";
my @file = <$fd>;
print $fd2 @file;
close $fd2;
@@ -843,7 +838,7 @@ sub git_get_project_config {
$key =~ s/^gitweb\.//;
return if ($key =~ m/\W/);
- my $val = qx($gitbin/git-repo-config --get gitweb.$key);
+ my $val = qx($GIT repo-config --get gitweb.$key);
return ($val);
}
@@ -1065,7 +1060,7 @@ sub git_summary {
"<tr><td>owner</td><td>$owner</td></tr>\n" .
"<tr><td>last change</td><td>$cd{'rfc2822'}</td></tr>\n" .
"</table>\n";
- open my $fd, "-|", "$gitbin/git-rev-list --max-count=17 " . git_read_head($project) or die_error(undef, "Open failed.");
+ open my $fd, "-|", "$GIT rev-list --max-count=17 " . git_read_head($project) or die_error(undef, "Open failed.");
my (@revlist) = map { chomp; $_ } <$fd>;
close $fd;
print "<div>\n" .
@@ -1253,7 +1248,7 @@ sub git_blame {
$hash = git_get_hash_by_path($hash_base, $file_name, "blob")
or die_error(undef, "Error lookup file.");
}
- open ($fd, "-|", "$gitbin/git-annotate", '-l', '-t', '-r', $file_name, $hash_base)
+ open ($fd, "-|", $GIT, "annotate", '-l', '-t', '-r', $file_name, $hash_base)
or die_error(undef, "Open failed.");
git_header_html();
print "<div class=\"page_nav\">\n" .
@@ -1448,7 +1443,7 @@ sub git_get_hash_by_path {
my $tree = $base;
my @parts = split '/', $path;
while (my $part = shift @parts) {
- open my $fd, "-|", "$gitbin/git-ls-tree $tree" or die_error(undef, "Open git-ls-tree failed.");
+ open my $fd, "-|", "$GIT ls-tree $tree" or die_error(undef, "Open git-ls-tree failed.");
my (@entries) = map { chomp; $_ } <$fd>;
close $fd or return undef;
foreach my $line (@entries) {
@@ -1535,7 +1530,7 @@ sub git_blob_plain_mimetype {
sub git_blob_plain {
my $type = shift;
- open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or die_error("Couldn't cat $file_name, $hash");
+ open my $fd, "-|", "$GIT cat-file blob $hash" or die_error("Couldn't cat $file_name, $hash");
$type ||= git_blob_plain_mimetype($fd, $file_name);
@@ -1562,7 +1557,7 @@ sub git_blob {
$hash = git_get_hash_by_path($base, $file_name, "blob") || die_error(undef, "Error lookup file.");
}
my $have_blame = git_get_project_config_bool ('blame');
- open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or die_error(undef, "Open failed.");
+ open my $fd, "-|", "$GIT cat-file blob $hash" or die_error(undef, "Open failed.");
my $mimetype = git_blob_plain_mimetype($fd, $file_name);
if ($mimetype !~ m/^text\//) {
close $fd;
@@ -1628,7 +1623,7 @@ sub git_tree {
}
}
$/ = "\0";
- open my $fd, "-|", "$gitbin/git-ls-tree -z $hash" or die_error(undef, "Open git-ls-tree failed.");
+ open my $fd, "-|", "$GIT ls-tree -z $hash" or die_error(undef, "Open git-ls-tree failed.");
chomp (my (@entries) = <$fd>);
close $fd or die_error(undef, "Reading tree failed.");
$/ = "\n";
@@ -1711,7 +1706,7 @@ # " | " . $cgi->a({-href => "$my
sub git_rss {
# http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ
- open my $fd, "-|", "$gitbin/git-rev-list --max-count=150 " . git_read_head($project) or die_error(undef, "Open failed.");
+ open my $fd, "-|", "$GIT rev-list --max-count=150 " . git_read_head($project) or die_error(undef, "Open failed.");
my (@revlist) = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading rev-list failed.");
print $cgi->header(-type => 'text/xml', -charset => 'utf-8');
@@ -1731,7 +1726,7 @@ sub git_rss {
last;
}
my %cd = date_str($co{'committer_epoch'});
- open $fd, "-|", "$gitbin/git-diff-tree -r $co{'parent'} $co{'id'}" or next;
+ open $fd, "-|", "$GIT diff-tree -r $co{'parent'} $co{'id'}" or next;
my @difftree = map { chomp; $_ } <$fd>;
close $fd or next;
print "<item>\n" .
@@ -1819,7 +1814,7 @@ sub git_log {
" | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=tree;h=$hash;hb=$hash")}, "tree") . "<br/>\n";
my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
- open my $fd, "-|", "$gitbin/git-rev-list $limit $hash" or die_error(undef, "Open failed.");
+ open my $fd, "-|", "$GIT rev-list $limit $hash" or die_error(undef, "Open failed.");
my (@revlist) = map { chomp; $_ } <$fd>;
close $fd;
@@ -1910,7 +1905,7 @@ sub git_commit {
$root = " --root";
$parent = "";
}
- open my $fd, "-|", "$gitbin/git-diff-tree -r -M $root $parent $hash" or die_error(undef, "Open failed.");
+ open my $fd, "-|", "$GIT diff-tree -r -M $root $parent $hash" or die_error(undef, "Open failed.");
@difftree = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading diff-tree failed.");
@@ -2152,7 +2147,7 @@ sub git_commitdiff {
if (!defined $hash_parent) {
$hash_parent = $co{'parent'};
}
- open my $fd, "-|", "$gitbin/git-diff-tree -r $hash_parent $hash" or die_error(undef, "Open failed.");
+ open my $fd, "-|", "$GIT diff-tree -r $hash_parent $hash" or die_error(undef, "Open failed.");
my (@difftree) = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading diff-tree failed.");
@@ -2242,14 +2237,14 @@ sub git_commitdiff {
sub git_commitdiff_plain {
mkdir($git_temp, 0700);
- open my $fd, "-|", "$gitbin/git-diff-tree -r $hash_parent $hash" or die_error(undef, "Open failed.");
+ open my $fd, "-|", "$GIT diff-tree -r $hash_parent $hash" or die_error(undef, "Open failed.");
my (@difftree) = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading diff-tree failed.");
# try to figure out the next tag after this commit
my $tagname;
my $refs = read_info_ref("tags");
- open $fd, "-|", "$gitbin/git-rev-list HEAD";
+ open $fd, "-|", "$GIT rev-list HEAD";
chomp (my (@commits) = <$fd>);
close $fd;
foreach my $commit (@commits) {
@@ -2320,7 +2315,7 @@ sub git_history {
print "<div class=\"page_path\"><b>/" . esc_html($file_name) . "</b><br/></div>\n";
open my $fd, "-|",
- "$gitbin/git-rev-list --full-history $hash -- \'$file_name\'";
+ "$GIT rev-list --full-history $hash -- \'$file_name\'";
print "<table cellspacing=\"0\">\n";
my $alternate = 0;
while (my $line = <$fd>) {
@@ -2407,7 +2402,7 @@ sub git_search {
my $alternate = 0;
if ($commit_search) {
$/ = "\0";
- open my $fd, "-|", "$gitbin/git-rev-list --header --parents $hash" or next;
+ open my $fd, "-|", "$GIT rev-list --header --parents $hash" or next;
while (my $commit_text = <$fd>) {
if (!grep m/$searchtext/i, $commit_text) {
next;
@@ -2457,7 +2452,7 @@ sub git_search {
if ($pickaxe_search) {
$/ = "\n";
- open my $fd, "-|", "$gitbin/git-rev-list $hash | $gitbin/git-diff-tree -r --stdin -S\'$searchtext\'";
+ open my $fd, "-|", "$GIT rev-list $hash | $GIT diff-tree -r --stdin -S\'$searchtext\'";
undef %co;
my @files;
while (my $line = <$fd>) {
@@ -2528,7 +2523,7 @@ sub git_shortlog {
" | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=tree;h=$hash;hb=$hash")}, "tree") . "<br/>\n";
my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
- open my $fd, "-|", "$gitbin/git-rev-list $limit $hash" or die_error(undef, "Open failed.");
+ open my $fd, "-|", "$GIT rev-list $limit $hash" or die_error(undef, "Open failed.");
my (@revlist) = map { chomp; $_ } <$fd>;
close $fd;
--
1.4.1.g97c7-dirty
^ permalink raw reply related
* [PATCH] gitweb: Send XHTML as 'application/xhtml+xml' where possible
From: Alp Toker @ 2006-07-11 10:19 UTC (permalink / raw)
To: git
In-Reply-To: <11526131782190-git-send-email-alp@atoker.com>
"The 'text/html' media type [RFC2854] is primarily for HTML, not for
XHTML. In general, this media type is NOT suitable for XHTML."
This patch makes gitweb use content negotiation to conservatively send
pages as Content-Type 'application/xhtml+xml' when the user agent
explicitly claims to support it.
It falls back to 'text/html' even if the user agent appears to
implicitly support 'application/xhtml+xml' due to a '*/*' glob, working
around an insidious bug in Internet Explorer where sending the correct
media type prevents the page from being displayed.
Signed-off-by: Alp Toker <alp@atoker.com>
---
gitweb/gitweb.cgi | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 2e87de4..bd9b9de 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -293,7 +293,17 @@ sub git_header_html {
}
}
}
- print $cgi->header(-type=>'text/html', -charset => 'utf-8', -status=> $status, -expires => $expires);
+ my $content_type;
+ # require explicit support from the UA if we are to send the page as
+ # 'application/xhtml+xml', otherwise send it as plain old 'text/html'.
+ # we have to do this because MSIE sometimes globs '*/*', pretending to
+ # support xhtml+xml but choking when it gets what it asked for.
+ if ($cgi->http('HTTP_ACCEPT') =~ m/(,|;|\s|^)application\/xhtml\+xml(,|;|\s|$)/ && $cgi->Accept('application/xhtml+xml') != 0) {
+ $content_type = 'application/xhtml+xml';
+ } else {
+ $content_type = 'text/html';
+ }
+ print $cgi->header(-type=>$content_type, -charset => 'utf-8', -status=> $status, -expires => $expires);
print <<EOF;
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
@@ -301,7 +311,7 @@ sub git_header_html {
<!-- git web interface v$version, (C) 2005-2006, Kay Sievers <kay.sievers\@vrfy.org>, Christian Gierke -->
<!-- git core binaries version $git_version -->
<head>
-<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
+<meta http-equiv="content-type" content="$content_type; charset=utf-8"/>
<meta name="robots" content="index, nofollow"/>
<title>$title</title>
<link rel="stylesheet" type="text/css" href="$stylesheet"/>
--
1.4.1.g97c7-dirty
^ permalink raw reply related
* [PATCH] git-send-email: Remove redundant Reply-To header
From: Alp Toker @ 2006-07-11 10:19 UTC (permalink / raw)
To: git
In-Reply-To: <11526131791902-git-send-email-alp@atoker.com>
There is no sense in duplicating the sender address in Reply-To as it's
already provided in the From header.
Signed-off-by: Alp Toker <alp@atoker.com>
---
git-send-email.perl | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 64a8eef..1e2777c 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -413,7 +413,6 @@ sub send_message
To: $to
Cc: $cc
Subject: $subject
-Reply-To: $from
Date: $date
Message-Id: $message_id
X-Mailer: git-send-email $gitversion
--
1.4.1.g97c7-dirty
^ permalink raw reply related
* [PATCH] Typo fix
From: Alp Toker @ 2006-07-11 10:19 UTC (permalink / raw)
To: git
Signed-off-by: Alp Toker <alp@atoker.com>
---
Documentation/git-name-rev.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt
index 43f8c25..37fbf66 100644
--- a/Documentation/git-name-rev.txt
+++ b/Documentation/git-name-rev.txt
@@ -33,7 +33,7 @@ EXAMPLE
-------
Given a commit, find out where it is relative to the local refs. Say somebody
-wrote you about that phantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a.
+wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a.
Of course, you look into the commit, but that only tells you what happened, but
not the context.
--
1.4.1.g97c7-dirty
^ permalink raw reply related
* Re: Re : 2 questions on git-send-email usage
From: Franck Bui-Huu @ 2006-07-11 10:08 UTC (permalink / raw)
To: moreau francis, Junio C Hamano; +Cc: jnareb, git
In-Reply-To: <20060711084635.81393.qmail@web25809.mail.ukl.yahoo.com>
moreau francis wrote:
> 2 RETs is missing. One after the Subject line and the other before the
> Signed-off-by line. If I add the first missing RET, all works fine. I guess
> it's missing because of git-cherry-pick command. But I don't understand
> why the last RET is missing
>
> Can anybody tell me why ?
>
Maybe that patch does what you want.
-- >8 --
Subject: [PATCH] Add a newline before appending "Signed-off-by:"
It looks nicer.
Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com>
---
log-tree.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index ebb49f2..2551a3f 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -19,7 +19,7 @@ static int append_signoff(char *buf, int
char *cp = buf;
/* Do we have enough space to add it? */
- if (buf_sz - at <= strlen(signed_off_by) + signoff_len + 2)
+ if (buf_sz - at <= strlen(signed_off_by) + signoff_len + 3)
return at;
/* First see if we already have the sign-off by the signer */
@@ -34,6 +34,7 @@ static int append_signoff(char *buf, int
return at; /* we already have him */
}
+ buf[at++] = '\n';
strcpy(buf + at, signed_off_by);
at += strlen(signed_off_by);
strcpy(buf + at, signoff);
--
1.4.1.g35c6-dirty
^ permalink raw reply related
* [RFC]: Pack-file object format for individual objects (Was: Revisiting large binary files issue.)
From: sf @ 2006-07-11 9:40 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0607101623230.5623@g5.osdl.org>
Linus Torvalds wrote:
...
> The problem is that the individual object disk format isn't actually the
> same as the pack-file object format for one object. The header is
> different: a pack-file uses a very dense bit packing, while the individual
> object format is a bit less dense.
I just stumbled over the same fact and asked myself why there are still
two formats. Wouldn't it make more sense to use the pack-file object
format for individual objects as well?
As it happens individual objects all start with nibble 7 (deflated with
default _zlib_ window size of 32K) whereas in the pack-file object
format nibble 7 indicates delta entries which never occur as individual
files.
Roadmap for using pack-file format as individual object disk format:
Step 1. When reading individual objects from disk check the first nibble
and decode accordingly (see above).
Step 2. When writing individual objects to disk write them in pack-file
object format. Make that optional (config-file parameter, command line
option etc.)?
Step 3. Remove code for (old) individual object disk format.
Please comment.
Regards
Stephan
^ permalink raw reply
* Re: [PATCH] t1400-update-ref: set VISUAL=true as well as EDITOR=true
From: Junio C Hamano @ 2006-07-11 9:15 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <11526072802855-git-send-email-normalperson@yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> I have VISUAL set in my environment, and it caused git-commit to
> spawn my editor during the test.
I think it would be better to remove "EDITOR=: VISUAL=:"
settings from annotate-tests.sh, t1400-update-ref.sh and
t4013-diff-various.sh, and move that to test-lib.sh; there is no
point overriding them differently in each of these automated
tests.
^ permalink raw reply
* Most quality products for anyone who wants to become a champion in bed
From: Andres @ 2006-07-11 9:10 UTC (permalink / raw)
To: git
Good day to you bro!
Achieve astounding results in bed with these products designed to make any man a winner
Most quality products for anyone who wants to become a champion in bed
http://www.xylidinehf.com
The tongue that brings healing is a tree of life, but a deceitful tongue crushes the spirit Feed a cold starve a fever Can one go upon hot coals, and his feet not be burned?
The proof of the pudding is in the eating
^ permalink raw reply
* Re : 2 questions on git-send-email usage
From: moreau francis @ 2006-07-11 8:46 UTC (permalink / raw)
To: moreau francis, jnareb; +Cc: git
moreau francis wrote:
> (please let me CCed when replying)
>
> 2006/7/10, Jakub Narebski <jnareb@gmail.com>:
> > moreau francis wrote:
> >
> > > I'm wondering what am I supposed to answer when git-send-email
> > > is asking me :
> > >
> > > Message-ID to be used as In-Reply-To for the first email?
> > >
> > > I'm running this command:
> > >
> > > $ git-send-email --no-signed-off-by-cc --no-chain-reply-to --to \
> > > foo@bar.com --compose /tmp/patch/
> > >
> > > to write an introductory message, and all patches are sent as replies to
> > > this introductory email sent.
> >
> > Empty string (i.e. RET) should do if you don't want to attach your series of
> > patches somewhere in existing thread.
>
> ok I'll try
>
> --in-reply-to ""
ok it works. But wouldn't it make more sense to have by default --in-reply-to ""
when --compose is set ? That would mean "by default all patches are sent
as replies to the email I'm composing" which is usely what happens, no ?
>
> >
> > > I also noticed that git-send-email removes the commit message of each
> > > patches I sent, I don't think this is the normal behaviour though. What
> > > am I missing ?
> >
> > Are patches formatted using git-format-patch?
> >
>
> yes
>
I think I have found out a clue. The commit message and Signed-off-by are
missing because the header patches are formatted like this:
>From 90df31ca209f85108976d18916f33f352a6ef340 Mon Sep 17 00:00:00 2001
From: Francis <francis.moreau2000@yahoo.fr>
Date: Thu, 8 Jun 2006 09:51:12 +0200
Subject: [PATCH 3/4] step #3: interrupt implementation
(cherry picked from 427778e2e622cdefa2c834edcc19bf102a35bc2d commit)
(cherry picked from fe4692336801fcbb42bb734bb6b6f9c041d63087 commit)
Signed-off-by: Francis <francis_moreau2000@yahoo.fr>
---
2 RETs is missing. One after the Subject line and the other before the
Signed-off-by line. If I add the first missing RET, all works fine. I guess
it's missing because of git-cherry-pick command. But I don't understand
why the last RET is missing
Can anybody tell me why ?
Thanks
Francis
^ permalink raw reply
* [PATCH] t1400-update-ref: set VISUAL=true as well as EDITOR=true
From: Eric Wong @ 2006-07-11 8:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
I have VISUAL set in my environment, and it caused git-commit to
spawn my editor during the test.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t1400-update-ref.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index 6a3515d..4f5b6bd 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -190,7 +190,7 @@ test_expect_success \
GIT_COMMITTER_DATE="2005-05-26 23:41" git-commit -F M -a &&
h_OTHER=$(git-rev-parse --verify HEAD) &&
echo FIXED >F &&
- EDITOR=true \
+ EDITOR=true VISUAL=true \
GIT_AUTHOR_DATE="2005-05-26 23:44" \
GIT_COMMITTER_DATE="2005-05-26 23:44" git-commit --amend &&
h_FIXED=$(git-rev-parse --verify HEAD) &&
--
1.4.1.g710d
^ permalink raw reply related
* Re: merge-base: update the clean-up postprocessing
From: Junio C Hamano @ 2006-07-11 8:13 UTC (permalink / raw)
To: git; +Cc: A Large Angry SCM
In-Reply-To: <7vejx0cwwj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> A fixed up version of this patch, along with your updated test,
> is at the tip of "pu".
>
> It does affect the processing time for cases where there are
> more than one merge bases negatively. To compute all merge-base
> for the 23 merges in the kernel reporitory, the old code with
> the "contaminate the well a bit more" clean-up phase takes 2.5
> seconds, while the new code takes 3.9 seconds.
>
> Processing all 2215 merges in the kernel repository (the other
> 2192 merges have one merge-base between the parents) takes 160
> seconds either way. In other words, multi merge-base merges are
> relatively rare and a bit more time spent to clean-up with the
> new code is lost in the noise.
>
> The numbers are taken from /usr/bin/time on an Athron 64X2 3800.
I did a similar test on git.git repository. Numbers are
interesting.
* I have 941 two-head merges. 89 of them are multi-base
merges. This is unproportionally higher compared to the
kernel repository.
* Both the version in "master" (i.e. the one with the horizon
effect) and this version with updated clean-up code produces
identical set of merge bases for all 941 two-head merges.
* The difference in processing time for 941 two-head merges
with both versions is lost within margin of error.
^ permalink raw reply
* Re: Why doesn't git-rerere automatically commit a resolution?
From: Matthias Kestenholz @ 2006-07-11 7:05 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060711061626.GB11822@spearce.org>
* Shawn Pearce (spearce@spearce.org) wrote:
> I'm curious... I have a pair of topic branches which don't merge
> together cleanly by recursive (due to conflicting hunks in the
> same line segments). I enabled git-rerere, ran the merge, fixed
> up the hunks and committed it. git-rerere built its cache, as
> the next time I pulled the two topic branches together and got
> the same conflicts it correctly regenerated the prior resolution
> (and printed a message saying as much).
>
> But it git-rerere left the files unmerged in the index and it
> doesn't generate a commit for the merge, even though there are no
> merge conflicts remaining. I expected it to update the index (to
> merge the stages) and to generate a commit if possible; especially
> in this case as I was pulling the exact same two commits together
> again with the exact same merge base commit.
>
> So I'm wondering why doesn't it try to finish the merge? Was there
> a really deep rooted reason behind it or was it simply easier/safer
> to let the user sort out the working directory state every time?
>
I am maintaining different websites from one git repository. The
code is almost the same between all versions, but the HTML templates
are not. Sometimes, modified templates in feature branches produce
mismerges which I want to fix up in different ways for different
websites. There, git-rerere doesn't help me at all. It does help
very much with the code and configuration files though.
To conclude, I have rerere enabled, but it does not always do the
right thing, so I am happy that I get a chance to inspect the files
before committing (I could also amend the commit later, but I still
think it's better that the user still needs to acknowledge the
result of the automatic merge.)
Matthias
^ permalink raw reply
* Re: Why doesn't git-rerere automatically commit a resolution?
From: Junio C Hamano @ 2006-07-11 6:58 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060711061626.GB11822@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> I'm curious... I have a pair of topic branches which don't merge
> together cleanly by recursive (due to conflicting hunks in the
> same line segments). I enabled git-rerere, ran the merge, fixed
> up the hunks and committed it. git-rerere built its cache, as
> the next time I pulled the two topic branches together and got
> the same conflicts it correctly regenerated the prior resolution
> (and printed a message saying as much).
After all your merge is conflicting, so it should be sanity
checked. At least you would want to run a compile test and
preferably a whole test cycle if your project has one, before
making the result into a commit.
You _could_ make it to automatically make a commit, and run a
test then if the test does not succeed fix the mismerge with "git
commit --amend", but people are lazy.
> So I'm wondering why doesn't it try to finish the merge? Was there
> a really deep rooted reason behind it or was it simply easier/safer
> to let the user sort out the working directory state every time?
The philosophy is to optimize the tools to support disciplined
workflows better, and make sure that the users do not have to
worry about automated tools makeing mismerges.
Now, I am not against helping lazy workflows per se, but only on
one condition. Doing so should never make more disciplined
workflows harder or more difficult.
Not merging the index after rerere re-applies a previous
resolution to the working tree file is a deliberate design
decision. During conflict resolution, "git diff" against
unmerged index file is the second most useful command to check
your hand-merge result, and running update-index on these path
automatically robs this useful tool from the user. So, in order
to help more disciplined workflow, a bit of convenience for
lazier people is sacrficed here.
^ permalink raw reply
* Reflog support status
From: Shawn Pearce @ 2006-07-11 6:34 UTC (permalink / raw)
To: git
My recent flurry of patches tonight (looks to be 5 total, 6
counting the user.name/user.email bug fix) should now include
reasonably useful information messages anytime a ref which has an
associated reflog gets updated, unless the update was made by one
of the following:
git-archimport
git-cvsimport
git-svnimport
git-receive-pack
Which is pretty reasonable.
I'll try to tackle git-receive-pack tomorrow night, but the reason
I have been putting it off is it would die a horrible death (exit
anyway) if it attempts to update a logged ref and GIT_COMMITTER_IDENT
can't be determined. But if the repository owner has enabled
reflogging exiting is probably the right thing to do in that case...
I'd also like to parameterize git-am's reflog entries the way I
did with git-merge, this way git-rebase will report as 'rebase'
in the log rather than 'am'. Again, I'll see if I can get that
done tomorrow night.
Junio: do you happen to still have that reflog program you put
together? I'm wondering if maybe we shouldn't include a git-reflog
to cat the reflog file in a more human friendly format than the
timestamps contained within the file, not to mention maybe also do
oneline commit pretty printing.
--
Shawn.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox