* Re: Starting to think about sha-256?
From: Linus Torvalds @ 2006-08-28 18:06 UTC (permalink / raw)
To: David Lang
Cc: Johannes Schindelin, Krzysztof Halasa, Jeff Garzik,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0608281034440.27779@g5.osdl.org>
On Mon, 28 Aug 2006, Linus Torvalds wrote:
>
> - The attacker kind of collision because somebody broke (or brute-forced)
> SHA1.
>
> This one is clearly a _lot_ more likely than the inadvertent kind, but
> by definition it's always a "remote" repository. If the attacker had
> access to the local repository, he'd have much easier ways to screw you
> up.
>
> So in this case, the collision is entirely a non-issue: you'll get a
> "bad" repository that is different from what the attacker intended, but
> since you'll never actually use his colliding object, it's _literally_
> no different from the attacker just not having found a collision at
> all, but just using the object you already had (ie it's 100% equivalent
> to the "trivial" collision of the identical file generating the same
> SHA1).
Btw, this is obviously only true for the native git protocol itself.
If the attacker can fool you into generating the new file _yourself_, he
can cause your checked-out copy to not match the git object database any
more.
In other words, one "interesting" attack vector is to feed you the
colliding SHA1 not through a git-to-git transfer, but by generating a
_patch_ that when applied will generate the collision, so that when you
then commit that patch, you get something else than you expected.
And _this_ is where it's important that the hash that git uses be a
non-trivial one - ie we don't want people to be able to generate two files
that look superficially "ok".
So here's the rule: If you ever get a patch that looks like line-noise,
especially from somebody you don't trust, DON'T APPLY IT!
Now, that is obviously something you should never do _regardless_ of any
git issues, so I don't think this is really a problem either. If you apply
patches from people you don't have a good reason to trust without
sanity-checking them, you deserve whatever you get, and quite frankly, a
SHA1 hash collision is the _least_ of your problems ;)
(This ends up boiling down to one common issue: it's generally _much_
easier to attack a project through _other_ means than through a hash
collision. And I pretty much guarantee that that is the case even if we
were to use a much weaker hash, like MD5. Hash collisions fundamentally
just aren't good attack vectors, and it's a hell of a lot easier to try
to insert bad code by other means)
Linus
^ permalink raw reply
* Re: Starting to think about sha-256?
From: Linus Torvalds @ 2006-08-28 17:56 UTC (permalink / raw)
To: David Lang
Cc: Johannes Schindelin, Krzysztof Halasa, Jeff Garzik,
Git Mailing List
In-Reply-To: <656C30A1EFC89F6B2082D9B6@localhost>
On Mon, 28 Aug 2006, David Lang wrote:
>
> just to double check.
>
> if you already have a file A in git with hash X is there any condition where a
> remote file with hash X (but different contents) would overwrite the local
> version?
Nope. If it has the same SHA1, it means that when we receive the object
from the other end, we will _not_ overwrite the object we already have.
So what happens is that if we ever see a collision, the "earlier" object
in any particular repository will always end up overriding. But note that
"earlier" is obviously per-repository, in the sense that the git object
network generates a DAG that is not fully ordered, so while different
repositories will agree about what is "earlier" in the case of direct
ancestry, if the object came through separate and not directly related
branches, two different repos may obviously have gotten the two objects in
different order.
However, the "earlier will override" is very much what you want from a
security standpoint: remember that the git model is that you should
primarily trust only your _own_ repository. So if you do a "git pull", the
new incoming objects are by definition less trustworthy than the objects
you already have, and as such it would be wrong to allow a new object to
replace an old one.
So you have two cases of collision:
- the inadvertent kind, where you somehow are very very unlucky, and two
files end up having the same SHA1. At that point, what happens is that
when you commit that file (or do a "git-update-index" to move it into
the index, but not committed yet), the SHA1 of the new contents will be
computed, but since it matches an old object, a new object won't be
created, and the commit-or-index ends up pointing to the _old_ object.
You won't notice immediately (since the index will match the old object
SHA1, and that means that something like "git diff" will use the
checked-out copy), but if you ever do a tree-level diff (or you
do a clone or pull, or force a checkout) you'll suddenly notice that
that file has changed to something _completely_ different than what you
expected. So you would generally notice this kind of collision fairly
quickly.
In related news, the question is what to do about the inadvertent
collision.. First off, let me remind people that the inadvertent kind
of collision is really really _really_ damn unlikely, so we'll quite
likely never ever see it in the full history of the universe. But _if_
it happens, it's not the end of the world: what you'd most likely have
to do is just change the file that collided slightly, and just force a
new commit with the changed contents (add a comment saying "/* This
line added to avoid collision */") and then teach git about the magic
SHA1 that has been shown to be dangerous.
So over a couple of million years, maybe we'll have to add one or two
"poisoned" SHA1 values to git. It's very unlikely to be a maintenance
problem ;)
- The attacker kind of collision because somebody broke (or brute-forced)
SHA1.
This one is clearly a _lot_ more likely than the inadvertent kind, but
by definition it's always a "remote" repository. If the attacker had
access to the local repository, he'd have much easier ways to screw you
up.
So in this case, the collision is entirely a non-issue: you'll get a
"bad" repository that is different from what the attacker intended, but
since you'll never actually use his colliding object, it's _literally_
no different from the attacker just not having found a collision at
all, but just using the object you already had (ie it's 100% equivalent
to the "trivial" collision of the identical file generating the same
SHA1).
> what would happen if you ended up with two packs that both contained a file
> with hash X but with different contents and then did a repack on them? (either
> packs from different sources, or packs downloaded through some mechanism other
> then the git protocol are two ways this could happen that I can think of)
See above. The only _dangerous_ kind of collision is the inadvertent kind,
but that's obviously also the very very unlikely kind.
Linus
^ permalink raw reply
* Re: Starting to think about sha-256?
From: David Lang @ 2006-08-28 17:27 UTC (permalink / raw)
To: Linus Torvalds, Johannes Schindelin
Cc: Krzysztof Halasa, Jeff Garzik, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0608271522390.27779@g5.osdl.org>
--On Sunday, August 27, 2006 03:35:20 PM -0700 Linus Torvalds
<torvalds@osdl.org> wrote:
>
> On Mon, 28 Aug 2006, Johannes Schindelin wrote:
>> Even if the breakthrough really comes to full SHA-1, you still have to
>> add _at least_ 20 bytes of gibberish. Which would be harder to spot,
>> but it would be spotted.
>
> Yeah, I don't think this is at all critical, especially since git really
> on a security level doesn't _depend_ on the hashes being
> cryptographically secure. As I explained early on (ie over a year ago,
> back when the whole design of git was being discussed), the _security_
> of git actually depends on not cryptographic hashes, but simply on
> everybody being able to secure their own _private_ repository.
>
> So the only thing git really _requires_ is a hash that is _unique_ for
> the developer (and there we are talking not of an _attacker_, but a
> benign participant).
>
> That said, the cryptographic security of SHA-1 is obviously a real bonus.
> So I'd be disappointed if SHA-1 can be broken more easily (and I
> obviously already argued against using MD5, exactly because generating
> duplicates of that is fairly easy). But it's not "fundamentally
> required" in git per se.
>> This made me think about the use of hashes in git. Why do we need a hash
>> here (in no particular order):
>>
>> 1) integrity checking,
>> 2) fast lookup,
>> 3) identifying objects (related to (2)),
>> 4) trust.
>>
>> Except for (4), I do not see why SHA-1 -- even if broken -- should not
>> be adequate. It is not like somebody found out that all JPGs tend to
>> have similar hashes so that collisions are more likely.
>
> Correct. I'm pretty sure we had exactly this discussion around May 2005,
> but I'm too lazy to search ;)
just to double check.
if you already have a file A in git with hash X is there any condition
where a remote file with hash X (but different contents) would overwrite
the local version?
what would happen if you ended up with two packs that both contained a file
with hash X but with different contents and then did a repack on them?
(either packs from different sources, or packs downloaded through some
mechanism other then the git protocol are two ways this could happen that I
can think of)
David Lang
^ permalink raw reply
* Re: [PATCH 0/5] gitweb: Additions to commitdiff view
From: Linus Torvalds @ 2006-08-28 17:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <11567692943154-git-send-email-jnareb@gmail.com>
On Mon, 28 Aug 2006, Jakub Narebski wrote:
>
> This series of patches makes signoff lines to be not removed in commitdiff and log
> views, adds author information to comittdiff view, and adds diff tree with links
> to patches in commitdiff view.
>
> You will be able to see it at work at
> http://front.fuw.edu.pl/cgi-bin/jnareb/gitweb.cgi
Goodie, that looks exactly like I envisioned. And the shortcuts to find
the patch to a specific file (when the patch is larger) works beautifully.
Now I think "commit-diff" is prettier than the "commit" view (the latter
ends up showing the "--pretty=full" information, which can be useful, but
usually is just distracting). That's as it should be - I consider
"commit-diff" to be the _normal_ thing, and then the "commit" view is the
"give me all the ugly details in just the commit".
I've got _one_ small beef with gitweb still, which is that it seems to
like always showing things in UTC rather than the "native" timezone, but I
can see why people would sometimes want that. So I'm not actually sure
it's wrong.
I think it _may_ be worth showing the native timezone in the "commit-diff"
view (when you see only one commit), and then show the UTC time in the
"log" view (when you see a lot of commits, and might want to compare times
in different timezones more easily).
But I think that timezone thing is probably a matter of taste rather than
much anything else.
Thanks,
Linus
^ permalink raw reply
* Re: Packfile can't be mapped
From: Nicolas Pitre @ 2006-08-28 17:19 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git, Jon Smirl
In-Reply-To: <20060828164222.GA22451@spearce.org>
On Mon, 28 Aug 2006, Shawn Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > On Sun, 27 Aug 2006, Shawn Pearce wrote:
> >
> > > I'm going to try to get tree deltas written to the pack sometime this
> > > week. That should compact this intermediate pack down to something
> > > that git-pack-objects would be able to successfully mmap into a
> > > 32 bit address space. A complete repack with no delta reuse will
> > > hopefully generate a pack closer to 400 MB in size. But I know
> > > Jon would like to get that pack even smaller. :)
> >
> > One thing to consider in your code (if you didn't implement that
> > already) is to _not_ attempt any delta on any object whose size is
> > smaller than 50 bytes, and then limit the maximum delta size to
> > object_size/2 - 20 (use that for the last argument to diff-delta() and
> > store the undeltified object when diff-delta returns NULL). This way
> > you'll avoid creating delta objects that are most likely to end up being
> > _larger_ than the undeltified object.
>
> So I added Nico's suggestions to fast-import and ran it on a small
> subset of the Mozilla repository (3424 blobs):
>
> naive always delta: 6652 KiB
> Nico's suggestion: 6842 KiB
Hmmm...
> So Nico's suggestion of limiting delta size to (orig_len/2)-20 or
> not using deltas on blobs < 50 bytes actually added 190 KB to the
> output pack. Since this sample is probably fairly representative
> of the rest of the repository's blobs I'm thinking we may see a 2.8%
> increase in size over the current 930 MB blob pack. That's another
> 26 MB in our intermediate pack. I don't think this suggestion is
> really worth including in fast-import right now...
The above is based on the assumption that undeltified blobs usually
deflates to 50% the undeflated size or more, and that pure object data
deflates better than delta data. Then there is the 20 byte base object
reference overhead for any deltas. The 20 bytes is a hard fact. The
50% factor is a wild guess. What I forgot to consider in the above
formula is the fact that delta data gets deflated as well so the /2
divisor is probably a bit too much (you could try orig_len*2/3 - 20, or
orig-len - 20, and adjust the initial treshold so the limit value
doesn't go negative).
If you are IO bound (I recall Jon mentioning something to that effect)
then you could probably use some CPU cycles to always deflate the
object, deflate the resulting delta, and pick the smallest between the
two (don't forget the additional 20 bytes in the delta case). Maybe the
increased CPU usage won't justify this solution though.
Nicolas
^ permalink raw reply
* Re: Packfile can't be mapped
From: Shawn Pearce @ 2006-08-28 16:48 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, git, Jon Smirl
In-Reply-To: <Pine.LNX.4.64.0608281026110.3683@localhost.localdomain>
Nicolas Pitre <nico@cam.org> wrote:
> On Mon, 28 Aug 2006, Shawn Pearce wrote:
> > Of course the major problem with pack-local, stream global
> > dictionaries is it voids the ability to reuse that zlib'd content
> > from that pack in another pack without wholesale copying the
> > dictionary as well. This is an issue for servers which want to
> > copy out the pack entry without recompressing it but also want the
> > storage savings from the global dictionaries.
>
> Why would copying the dictionary as well be a problem? How large might
> it be? Can it be stored deflated itself?
Largest size is like 200 bytes smaller than the window size. Times 3
as we would want to store 3 dictionaries, though maybe only 2 if the
blob dictionary proves to be worse than not having one at all for a
given project. Since its just a binary buffer holding bytes which
frequently appear in our compressed objects its easily deflatable;
especially when you consider its primarily storing US-ASCII text.
I was definately planning on the dictionary being deflated in the
pack.
We could alawys use the SHA1 of a dictionary to signal to the client
what dictionary was in use. If the dictionary itself was treated
like any other SHA1 object then we might be able to transfer the
server's current dictionaries to the client along with everything
else in the same pack if the client doesn't have the necessary
dictionary yet.
--
Shawn.
^ permalink raw reply
* Re: Packfile can't be mapped
From: Nicolas Pitre @ 2006-08-28 16:43 UTC (permalink / raw)
To: Jon Smirl; +Cc: Shawn Pearce, Linus Torvalds, git
In-Reply-To: <9e4733910608280844q41ea1a61r33c3eadc3e942604@mail.gmail.com>
On Mon, 28 Aug 2006, Jon Smirl wrote:
> On 8/28/06, Nicolas Pitre <nico@cam.org> wrote:
> > > Of course the major problem with pack-local, stream global
> > > dictionaries is it voids the ability to reuse that zlib'd content
> > > from that pack in another pack without wholesale copying the
> > > dictionary as well. This is an issue for servers which want to
> > > copy out the pack entry without recompressing it but also want the
> > > storage savings from the global dictionaries.
> >
> > Why would copying the dictionary as well be a problem? How large might
> > it be? Can it be stored deflated itself?
>
> The dictionaries are only 4KB. But they have to match up with the
> objects compressed using them. If you bring an object straight down
> out of a dictionary based pack and make it standalone you won't be
> able to read it. You need the dictionary to decode it. What if the
> local and remote packs have been packed using two different
> dictionaries? You can't directly move objects between them.
I guess we'll be able to reuse the same dictionary when objects are all
from the same pack.
If not then they could be recompressed which is costly but never as much
as delta matching initially was when it was always done.
Anyway let's look at the size saving first. The implied costs could
then be evaluated and weighted accordingly.
Nicolas
^ permalink raw reply
* Re: Packfile can't be mapped
From: Shawn Pearce @ 2006-08-28 16:42 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Jon Smirl
In-Reply-To: <Pine.LNX.4.64.0608280014190.3683@localhost.localdomain>
Nicolas Pitre <nico@cam.org> wrote:
> On Sun, 27 Aug 2006, Shawn Pearce wrote:
>
> > I'm going to try to get tree deltas written to the pack sometime this
> > week. That should compact this intermediate pack down to something
> > that git-pack-objects would be able to successfully mmap into a
> > 32 bit address space. A complete repack with no delta reuse will
> > hopefully generate a pack closer to 400 MB in size. But I know
> > Jon would like to get that pack even smaller. :)
>
> One thing to consider in your code (if you didn't implement that
> already) is to _not_ attempt any delta on any object whose size is
> smaller than 50 bytes, and then limit the maximum delta size to
> object_size/2 - 20 (use that for the last argument to diff-delta() and
> store the undeltified object when diff-delta returns NULL). This way
> you'll avoid creating delta objects that are most likely to end up being
> _larger_ than the undeltified object.
So I added Nico's suggestions to fast-import and ran it on a small
subset of the Mozilla repository (3424 blobs):
naive always delta: 6652 KiB
Nico's suggestion: 6842 KiB
So Nico's suggestion of limiting delta size to (orig_len/2)-20 or
not using deltas on blobs < 50 bytes actually added 190 KB to the
output pack. Since this sample is probably fairly representative
of the rest of the repository's blobs I'm thinking we may see a 2.8%
increase in size over the current 930 MB blob pack. That's another
26 MB in our intermediate pack. I don't think this suggestion is
really worth including in fast-import right now...
--
Shawn.
^ permalink raw reply
* [PATCH (amend)] gitweb: Use --git-dir parameter instead of setting $ENV{'GIT_DIR'}
From: Jakub Narebski @ 2006-08-28 15:49 UTC (permalink / raw)
To: git; +Cc: Dennis Stosberg, Jakub Narebski
In-Reply-To: <20060824151246.G465d67c8@leonov.stosberg.net>
From: Dennis Stosberg <dennis@stosberg.net>
This makes it possible to run gitweb under mod_perl's Apache::Registry.
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Updated to the 'next' version (v1.4.2-gc6063de).
It needs fairly new git version, with --git-dir=<path> parameter
to git wrapper, i.e. post v1.4.2-rc2-g6acbcb9 version.
Dennis, could you check that it works for you in 'next'
version of gitweb? The patch you sent is pre-rename even...
gitweb/gitweb.perl | 90 +++++++++++++++++++++++++++++++---------------------
1 files changed, 54 insertions(+), 36 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ef09cf5..f421825 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -157,6 +157,9 @@ require $GITWEB_CONFIG if -e $GITWEB_CON
# version of the core git binary
our $git_version = qx($GIT --version) =~ m/git version (.*)$/ ? $1 : "unknown";
+# path to the current git repository
+our $git_dir;
+
$projects_list ||= $projectroot;
# ======================================================================
@@ -184,7 +187,7 @@ if (defined $project) {
if (!(-e "$projectroot/$project/HEAD")) {
die_error(undef, "No such project");
}
- $ENV{'GIT_DIR'} = "$projectroot/$project";
+ $git_dir = "$projectroot/$project";
}
our $file_name = $cgi->param('f');
@@ -572,21 +575,31 @@ sub format_diff_line {
## ----------------------------------------------------------------------
## git utility subroutines, invoking git commands
+# returns path to the core git executable and the --git-dir parameter as list
+sub git_cmd {
+ return $GIT, '--git-dir='.$git_dir;
+}
+
+# returns path to the core git executable and the --git-dir parameter as string
+sub git_cmd_str {
+ return join(' ', git_cmd());
+}
+
# get HEAD ref of given project as hash
sub git_get_head_hash {
my $project = shift;
- my $oENV = $ENV{'GIT_DIR'};
+ my $o_git_dir = $git_dir;
my $retval = undef;
- $ENV{'GIT_DIR'} = "$projectroot/$project";
- if (open my $fd, "-|", $GIT, "rev-parse", "--verify", "HEAD") {
+ $git_dir = "$projectroot/$project";
+ if (open my $fd, "-|", git_cmd(), "rev-parse", "--verify", "HEAD") {
my $head = <$fd>;
close $fd;
if (defined $head && $head =~ /^([0-9a-fA-F]{40})$/) {
$retval = $1;
}
}
- if (defined $oENV) {
- $ENV{'GIT_DIR'} = $oENV;
+ if (defined $o_git_dir) {
+ $git_dir = $o_git_dir;
}
return $retval;
}
@@ -595,7 +608,7 @@ # get type of given object
sub git_get_type {
my $hash = shift;
- open my $fd, "-|", $GIT, "cat-file", '-t', $hash or return;
+ open my $fd, "-|", git_cmd(), "cat-file", '-t', $hash or return;
my $type = <$fd>;
close $fd or return;
chomp $type;
@@ -609,7 +622,7 @@ sub git_get_project_config {
$key =~ s/^gitweb\.//;
return if ($key =~ m/\W/);
- my @x = ($GIT, 'repo-config');
+ my @x = (git_cmd(), 'repo-config');
if (defined $type) { push @x, $type; }
push @x, "--get";
push @x, "gitweb.$key";
@@ -625,7 +638,7 @@ sub git_get_hash_by_path {
my $tree = $base;
- open my $fd, "-|", $GIT, "ls-tree", $base, "--", $path
+ open my $fd, "-|", git_cmd(), "ls-tree", $base, "--", $path
or die_error(undef, "Open git-ls-tree failed");
my $line = <$fd>;
close $fd or return undef;
@@ -756,7 +769,7 @@ sub git_get_references {
open $fd, "$projectroot/$project/info/refs"
or return;
} else {
- open $fd, "-|", $GIT, "ls-remote", "."
+ open $fd, "-|", git_cmd(), "ls-remote", "."
or return;
}
@@ -777,7 +790,7 @@ sub git_get_references {
sub git_get_rev_name_tags {
my $hash = shift || return undef;
- open my $fd, "-|", $GIT, "name-rev", "--tags", $hash
+ open my $fd, "-|", git_cmd(), "name-rev", "--tags", $hash
or return;
my $name_rev = <$fd>;
close $fd;
@@ -825,7 +838,7 @@ sub parse_tag {
my %tag;
my @comment;
- open my $fd, "-|", $GIT, "cat-file", "tag", $tag_id or return;
+ open my $fd, "-|", git_cmd(), "cat-file", "tag", $tag_id or return;
$tag{'id'} = $tag_id;
while (my $line = <$fd>) {
chomp $line;
@@ -866,7 +879,7 @@ sub parse_commit {
@commit_lines = @$commit_text;
} else {
$/ = "\0";
- open my $fd, "-|", $GIT, "rev-list", "--header", "--parents", "--max-count=1", $commit_id
+ open my $fd, "-|", git_cmd(), "rev-list", "--header", "--parents", "--max-count=1", $commit_id
or return;
@commit_lines = split '\n', <$fd>;
close $fd or return;
@@ -1971,7 +1984,7 @@ sub git_project_list {
if (!defined $head) {
next;
}
- $ENV{'GIT_DIR'} = "$projectroot/$pr->{'path'}";
+ $git_dir = "$projectroot/$pr->{'path'}";
my %co = parse_commit($head);
if (!%co) {
next;
@@ -2090,7 +2103,8 @@ sub git_summary {
}
print "</table>\n";
- open my $fd, "-|", $GIT, "rev-list", "--max-count=17", git_get_head_hash($project)
+ open my $fd, "-|", git_cmd(), "rev-list", "--max-count=17",
+ git_get_head_hash($project)
or die_error(undef, "Open git-rev-list failed");
my @revlist = map { chomp; $_ } <$fd>;
close $fd;
@@ -2168,7 +2182,7 @@ sub git_blame2 {
if ($ftype !~ "blob") {
die_error("400 Bad Request", "Object is not a blob");
}
- open ($fd, "-|", $GIT, "blame", '-l', $file_name, $hash_base)
+ open ($fd, "-|", git_cmd(), "blame", '-l', $file_name, $hash_base)
or die_error(undef, "Open git-blame failed");
git_header_html();
my $formats_nav =
@@ -2233,7 +2247,7 @@ sub git_blame {
$hash = git_get_hash_by_path($hash_base, $file_name, "blob")
or die_error(undef, "Error lookup file");
}
- open ($fd, "-|", $GIT, "annotate", '-l', '-t', '-r', $file_name, $hash_base)
+ open ($fd, "-|", git_cmd(), "annotate", '-l', '-t', '-r', $file_name, $hash_base)
or die_error(undef, "Open git-annotate failed");
git_header_html();
my $formats_nav =
@@ -2354,7 +2368,7 @@ sub git_blob_plain {
}
}
my $type = shift;
- open my $fd, "-|", $GIT, "cat-file", "blob", $hash
+ open my $fd, "-|", git_cmd(), "cat-file", "blob", $hash
or die_error(undef, "Couldn't cat $file_name, $hash");
$type ||= blob_mimetype($fd, $file_name);
@@ -2396,7 +2410,7 @@ sub git_blob {
}
}
my $have_blame = gitweb_check_feature('blame');
- open my $fd, "-|", $GIT, "cat-file", "blob", $hash
+ open my $fd, "-|", git_cmd(), "cat-file", "blob", $hash
or die_error(undef, "Couldn't cat $file_name, $hash");
my $mimetype = blob_mimetype($fd, $file_name);
if ($mimetype !~ m/^text\//) {
@@ -2461,7 +2475,7 @@ sub git_tree {
}
}
$/ = "\0";
- open my $fd, "-|", $GIT, "ls-tree", '-z', $hash
+ open my $fd, "-|", git_cmd(), "ls-tree", '-z', $hash
or die_error(undef, "Open git-ls-tree failed");
my @entries = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading tree failed");
@@ -2564,7 +2578,8 @@ sub git_snapshot {
-content_disposition => "inline; filename=\"$filename\"",
-status => '200 OK');
- open my $fd, "-|", "$GIT tar-tree $hash \'$project\' | $command" or
+ my $git_command = git_cmd_str();
+ open my $fd, "-|", "$git_command tar-tree $hash \'$project\' | $command" or
die_error(undef, "Execute git-tar-tree failed.");
binmode STDOUT, ':raw';
print <$fd>;
@@ -2584,7 +2599,7 @@ sub git_log {
my $refs = git_get_references();
my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
- open my $fd, "-|", $GIT, "rev-list", $limit, $hash
+ open my $fd, "-|", git_cmd(), "rev-list", $limit, $hash
or die_error(undef, "Open git-rev-list failed");
my @revlist = map { chomp; $_ } <$fd>;
close $fd;
@@ -2639,7 +2654,7 @@ sub git_commit {
if (!defined $parent) {
$parent = "--root";
}
- open my $fd, "-|", $GIT, "diff-tree", '-r', @diff_opts, $parent, $hash
+ open my $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts, $parent, $hash
or die_error(undef, "Open git-diff-tree failed");
my @difftree = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading git-diff-tree failed");
@@ -2746,7 +2761,7 @@ sub git_blobdiff {
if (defined $hash_base && defined $hash_parent_base) {
if (defined $file_name) {
# read raw output
- open $fd, "-|", $GIT, "diff-tree", '-r', @diff_opts, $hash_parent_base, $hash_base,
+ open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts, $hash_parent_base, $hash_base,
"--", $file_name
or die_error(undef, "Open git-diff-tree failed");
@difftree = map { chomp; $_ } <$fd>;
@@ -2760,7 +2775,7 @@ sub git_blobdiff {
# try to find filename from $hash
# read filtered raw output
- open $fd, "-|", $GIT, "diff-tree", '-r', @diff_opts, $hash_parent_base, $hash_base
+ open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts, $hash_parent_base, $hash_base
or die_error(undef, "Open git-diff-tree failed");
@difftree =
# ':100644 100644 03b21826... 3b93d5e7... M ls-files.c'
@@ -2794,7 +2809,7 @@ sub git_blobdiff {
}
# open patch output
- open $fd, "-|", $GIT, "diff-tree", '-r', @diff_opts,
+ open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
'-p', $hash_parent_base, $hash_base,
"--", $file_name
or die_error(undef, "Open git-diff-tree failed");
@@ -2830,7 +2845,7 @@ sub git_blobdiff {
}
# open patch output
- open $fd, "-|", $GIT, "diff", '-p', @diff_opts, $hash_parent, $hash
+ open $fd, "-|", git_cmd(), "diff", '-p', @diff_opts, $hash_parent, $hash
or die_error(undef, "Open git-diff failed");
} else {
die_error('404 Not Found', "Missing one of the blob diff parameters")
@@ -2915,7 +2930,7 @@ sub git_commitdiff {
my $fd;
my @difftree;
if ($format eq 'html') {
- open $fd, "-|", $GIT, "diff-tree", '-r', @diff_opts,
+ open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
"--patch-with-raw", "--full-index", $hash_parent, $hash
or die_error(undef, "Open git-diff-tree failed");
@@ -2926,7 +2941,7 @@ sub git_commitdiff {
}
} elsif ($format eq 'plain') {
- open $fd, "-|", $GIT, "diff-tree", '-r', @diff_opts,
+ open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
'-p', $hash_parent, $hash
or die_error(undef, "Open git-diff-tree failed");
@@ -3027,7 +3042,8 @@ sub git_history {
git_print_page_path($file_name, $ftype, $hash_base);
open my $fd, "-|",
- $GIT, "rev-list", "--full-history", $hash_base, "--", $file_name;
+ git_cmd(), "rev-list", "--full-history", $hash_base, "--", $file_name;
+
git_history_body($fd, $refs, $hash_base, $ftype);
close $fd;
@@ -3067,7 +3083,7 @@ sub git_search {
my $alternate = 0;
if ($commit_search) {
$/ = "\0";
- open my $fd, "-|", $GIT, "rev-list", "--header", "--parents", $hash or next;
+ open my $fd, "-|", git_cmd(), "rev-list", "--header", "--parents", $hash or next;
while (my $commit_text = <$fd>) {
if (!grep m/$searchtext/i, $commit_text) {
next;
@@ -3119,7 +3135,9 @@ sub git_search {
if ($pickaxe_search) {
$/ = "\n";
- open my $fd, "-|", "$GIT rev-list $hash | $GIT diff-tree -r --stdin -S\'$searchtext\'";
+ my $git_command = git_cmd_str();
+ open my $fd, "-|", "$git_command rev-list $hash | " .
+ "$git_command diff-tree -r --stdin -S\'$searchtext\'";
undef %co;
my @files;
while (my $line = <$fd>) {
@@ -3186,7 +3204,7 @@ sub git_shortlog {
my $refs = git_get_references();
my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
- open my $fd, "-|", $GIT, "rev-list", $limit, $hash
+ open my $fd, "-|", git_cmd(), "rev-list", $limit, $hash
or die_error(undef, "Open git-rev-list failed");
my @revlist = map { chomp; $_ } <$fd>;
close $fd;
@@ -3214,7 +3232,7 @@ ## feeds (RSS, OPML)
sub git_rss {
# http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ
- open my $fd, "-|", $GIT, "rev-list", "--max-count=150", git_get_head_hash($project)
+ open my $fd, "-|", git_cmd(), "rev-list", "--max-count=150", git_get_head_hash($project)
or die_error(undef, "Open git-rev-list failed");
my @revlist = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading git-rev-list failed");
@@ -3237,7 +3255,7 @@ XML
last;
}
my %cd = parse_date($co{'committer_epoch'});
- open $fd, "-|", $GIT, "diff-tree", '-r', @diff_opts,
+ open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
$co{'parent'}, $co{'id'}
or next;
my @difftree = map { chomp; $_ } <$fd>;
@@ -3295,7 +3313,7 @@ XML
if (!defined $head) {
next;
}
- $ENV{'GIT_DIR'} = "$projectroot/$proj{'path'}";
+ $git_dir = "$projectroot/$proj{'path'}";
my %co = parse_commit($head);
if (!%co) {
next;
--
1.4.1.1
^ permalink raw reply related
* Re: Packfile can't be mapped
From: Jon Smirl @ 2006-08-28 15:44 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn Pearce, Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0608281026110.3683@localhost.localdomain>
On 8/28/06, Nicolas Pitre <nico@cam.org> wrote:
> > Of course the major problem with pack-local, stream global
> > dictionaries is it voids the ability to reuse that zlib'd content
> > from that pack in another pack without wholesale copying the
> > dictionary as well. This is an issue for servers which want to
> > copy out the pack entry without recompressing it but also want the
> > storage savings from the global dictionaries.
>
> Why would copying the dictionary as well be a problem? How large might
> it be? Can it be stored deflated itself?
The dictionaries are only 4KB. But they have to match up with the
objects compressed using them. If you bring an object straight down
out of a dictionary based pack and make it standalone you won't be
able to read it. You need the dictionary to decode it. What if the
local and remote packs have been packed using two different
dictionaries? You can't directly move objects between them.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* We can credit you
From: affidavit @ 2006-08-28 15:39 UTC (permalink / raw)
To: git
Yo!
Your credit doesn't matter to us!
If you OWN real estate and want IMMEDIATE cash to spend ANY way you
like, or simply wish to LOWER your monthly payments by a third or more, here are the deals we have TODAY:
$488,000.00 at a 3.67% fixed-rate
$372,000.00 at a 3.90% variable-rate
$492,000.00 at a 3.21% interest-only
$248,000.00 at a 3.36% fixed-rate
$198,000.00 at a 3.55% variable-rate
Hurry, we have requests limits, so when these deals are gone, they are
gone!
We have one-mimute form to apply the request,
please CLICK HERE
http://3M3RN.expresshomecredit.us/?ncache=103380
Don't worry about approval, your credit will not disqualify you!
Approval Manager.
^ permalink raw reply
* Re: Packfile can't be mapped
From: Nicolas Pitre @ 2006-08-28 14:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn Pearce, git, Jon Smirl
In-Reply-To: <Pine.LNX.4.64.0608272133390.27779@g5.osdl.org>
On Sun, 27 Aug 2006, Linus Torvalds wrote:
>
>
> On Mon, 28 Aug 2006, Nicolas Pitre wrote:
> >
> > Good job indeed. Oh and you probably should not bother trying to
> > deltify commit objects at all since that would be a waste of time.
>
> It might not necessarily always be a waste of time.
[...]
> It's probably not worth doing for the fast importer unless it just
> happens to fall out of the code very easily.
... which is what my comment was all about.
Nicolas
^ permalink raw reply
* Re: Packfile can't be mapped
From: Nicolas Pitre @ 2006-08-28 14:40 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Linus Torvalds, git, Jon Smirl
In-Reply-To: <20060828060029.GB25285@spearce.org>
On Mon, 28 Aug 2006, Shawn Pearce wrote:
> Linus Torvalds <torvalds@osdl.org> wrote:
> >
> > On Mon, 28 Aug 2006, Nicolas Pitre wrote:
> > >
> > > Good job indeed. Oh and you probably should not bother trying to
> > > deltify commit objects at all since that would be a waste of time.
> >
> > It might not necessarily always be a waste of time. Especially if you have
> > multiple branches tracking a "maintenance" branch, you often end up having
> > the same commit message repeated several times in "unrelated" commits
> > (they're really the same commit, applied to another branch).
> >
> > Also, I could imagine that some automated system generates very verbose
> > (and possibly very regular) commit messages, so under certain
> > circumstances it may well make sense to see if the commits migth delta
> > against each other.
> >
> > But I'll agree that in normal use it's not likely to be a huge saving,
> > though. It's probably not worth doing for the fast importer unless it just
> > happens to fall out of the code very easily.
>
> Does git-pack-objects attempt to delta commits against each other?
Yes it does. But simply because it requires no special case in the code
for that and it can afford spending more time trying to tighten a pack
given that it wastes a lot of cycles with delta windows already. In the
context of an intermediate pack from fast-import I doubt it is worth it
since the extra time spent on that won't give you a significant size
reduction.
> I've been thinking about applying a pack-local but zlib-stream
> global dictionary. If we added three global dicationaries to the
> front of the pack file, one for commits, one for trees and one
> for blobs, and use those as the global dictionaries for the zlib
> streams stored within that pack we could probably get a good space
> savings for trees and commits.
>
> I'd suspect that for many projects the commit global dictionary
> would contain the common required strings such as:
>
> 'tree ', 'parent ', 'committer ', 'author ', 'Signed-off-by: '
>
> plus the top author/committer name/email combination strings.
> For GIT I'd expect 'Junio C Hamano <junkio@cox.net>' to be way up
> there in terms of frequency within commit objects. Finding the most
> common authors and committer strings would be trivial, as would
> finding the most common 'footer' strings such as 'Signed-off-by: '
> and 'Acked-by: '.
>
> I think the same is true of trees, with '10644 ', '10755 ', '40000 '
> being way up there, but also file names that commonly appear within
> trees, e.g. "Makefile.in\0".
Indeed.
> Blobs would be more difficult to generate a reasonable global
> dictionary for. But for some projects a crude estimated dictionary
> can shave off at least 4% of pack size (true in both GIT and Mozilla
> sources it seems).
>
>
> Of course the major problem with pack-local, stream global
> dictionaries is it voids the ability to reuse that zlib'd content
> from that pack in another pack without wholesale copying the
> dictionary as well. This is an issue for servers which want to
> copy out the pack entry without recompressing it but also want the
> storage savings from the global dictionaries.
Why would copying the dictionary as well be a problem? How large might
it be? Can it be stored deflated itself?
> But then again, if we just delta against a commit which uses the
> same author and committer, or against the same tree but different
> version then there should be a lot of delta copying from the base...
> which easily allows entry reuse and should provide similiar space
> savings, providing the delta depth is deep enough (or the delta graph
> is wide enough) to minimize the number of base objects containing
> repeated occurrances of the common strings.
This is already attempted by pack-objects and used when it provides a
gain. It is just much less likely to happen than with trees or blobs.
Nicolas
^ permalink raw reply
* Re: Packfile can't be mapped
From: Jon Smirl @ 2006-08-28 14:15 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Linus Torvalds, Nicolas Pitre, git
In-Reply-To: <20060828060029.GB25285@spearce.org>
On 8/28/06, Shawn Pearce <spearce@spearce.org> wrote:
> Of course the major problem with pack-local, stream global
> dictionaries is it voids the ability to reuse that zlib'd content
> from that pack in another pack without wholesale copying the
> dictionary as well. This is an issue for servers which want to
> copy out the pack entry without recompressing it but also want the
> storage savings from the global dictionaries.
If you copy an entire pack with a dictionary embedded in it everything
is fine. But if you pull objects out of the pack for transmission it
looks like they will need to be unpacked and repacked without the
dictionary. My plan was to only use dictionaries in archival packs
that would be used in a read only manner and copied around whole.
So there would need to something like an archive flag on git-repack
which would spend extra CPU time trying to make the pack as small as
possible. Normal use of git-repack wouldn't touch packs marked with
the archive flag since they were already in optimal form.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] Add --relative-date option to the revision interface
From: Jonas Fonseca @ 2006-08-28 13:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodu5qqd3.fsf@assigned-by-dhcp.cox.net>
Exposes the infrastructure from 9a8e35e98793af086f05d1ca9643052df9b44a74.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Junio C Hamano <junkio@cox.net> wrote Mon, Aug 28, 2006:
> - The internal is readied to be able to say "32 hours ago" in
> "git log" and friends by Linus; we do not have an UI to
> enable it yet.
Since nobody else has posted a patch, here is one.
Documentation/git-rev-list.txt | 5 +++++
builtin-rev-list.c | 2 +-
builtin-show-branch.c | 2 +-
commit.c | 20 ++++++++++++++------
commit.h | 2 +-
log-tree.c | 4 +++-
revision.c | 4 ++++
revision.h | 3 ++-
8 files changed, 31 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index dd9fff1..a446a6b 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -128,6 +128,11 @@ OPTIONS
After a failed merge, show refs that touch files having a
conflict and don't exist on all heads to merge.
+--relative-date::
+ Show dates relative to the current time, e.g. "2 hours ago".
+ Only takes effect for dates shown in human-readable format,
+ such as when using "--pretty".
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index bc48a3e..ac648e9 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -85,7 +85,7 @@ static void show_commit(struct commit *c
static char pretty_header[16384];
pretty_print_commit(revs.commit_format, commit, ~0,
pretty_header, sizeof(pretty_header),
- revs.abbrev, NULL, NULL);
+ revs.abbrev, NULL, NULL, revs.relative_date);
printf("%s%c", pretty_header, hdr_termination);
}
fflush(stdout);
diff --git a/builtin-show-branch.c b/builtin-show-branch.c
index 18786f8..d7de18e 100644
--- a/builtin-show-branch.c
+++ b/builtin-show-branch.c
@@ -261,7 +261,7 @@ static void show_one_commit(struct commi
struct commit_name *name = commit->util;
if (commit->object.parsed)
pretty_print_commit(CMIT_FMT_ONELINE, commit, ~0,
- pretty, sizeof(pretty), 0, NULL, NULL);
+ pretty, sizeof(pretty), 0, NULL, NULL, 0);
else
strcpy(pretty, "(unavailable)");
if (!strncmp(pretty, "[PATCH] ", 8))
diff --git a/commit.c b/commit.c
index 307883f..3f4bc31 100644
--- a/commit.c
+++ b/commit.c
@@ -482,7 +482,8 @@ static int add_rfc2047(char *buf, const
return bp - buf;
}
-static int add_user_info(const char *what, enum cmit_fmt fmt, char *buf, const char *line)
+static int add_user_info(const char *what, enum cmit_fmt fmt, char *buf,
+ const char *line, int relative_date)
{
char *date;
int namelen;
@@ -522,14 +523,16 @@ static int add_user_info(const char *wha
}
switch (fmt) {
case CMIT_FMT_MEDIUM:
- ret += sprintf(buf + ret, "Date: %s\n", show_date(time, tz, 0));
+ ret += sprintf(buf + ret, "Date: %s\n",
+ show_date(time, tz, relative_date));
break;
case CMIT_FMT_EMAIL:
ret += sprintf(buf + ret, "Date: %s\n",
show_rfc2822_date(time, tz));
break;
case CMIT_FMT_FULLER:
- ret += sprintf(buf + ret, "%sDate: %s\n", what, show_date(time, tz, 0));
+ ret += sprintf(buf + ret, "%sDate: %s\n", what,
+ show_date(time, tz, relative_date));
break;
default:
/* notin' */
@@ -572,7 +575,10 @@ static int add_merge_info(enum cmit_fmt
return offset;
}
-unsigned long pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit, unsigned long len, char *buf, unsigned long space, int abbrev, const char *subject, const char *after_subject)
+unsigned long pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
+ unsigned long len, char *buf, unsigned long space,
+ int abbrev, const char *subject,
+ const char *after_subject, int relative_date)
{
int hdr = 1, body = 0;
unsigned long offset = 0;
@@ -661,12 +667,14 @@ unsigned long pretty_print_commit(enum c
if (!memcmp(line, "author ", 7))
offset += add_user_info("Author", fmt,
buf + offset,
- line + 7);
+ line + 7,
+ relative_date);
if (!memcmp(line, "committer ", 10) &&
(fmt == CMIT_FMT_FULL || fmt == CMIT_FMT_FULLER))
offset += add_user_info("Commit", fmt,
buf + offset,
- line + 10);
+ line + 10,
+ relative_date);
continue;
}
diff --git a/commit.h b/commit.h
index 779ed82..fc13de9 100644
--- a/commit.h
+++ b/commit.h
@@ -52,7 +52,7 @@ enum cmit_fmt {
};
extern enum cmit_fmt get_commit_format(const char *arg);
-extern unsigned long pretty_print_commit(enum cmit_fmt fmt, const struct commit *, unsigned long len, char *buf, unsigned long space, int abbrev, const char *subject, const char *after_subject);
+extern unsigned long pretty_print_commit(enum cmit_fmt fmt, const struct commit *, unsigned long len, char *buf, unsigned long space, int abbrev, const char *subject, const char *after_subject, int relative_date);
/** Removes the first commit from a list sorted by date, and adds all
* of its parents.
diff --git a/log-tree.c b/log-tree.c
index 031af88..54cdaa4 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -194,7 +194,9 @@ void show_log(struct rev_info *opt, cons
/*
* And then the pretty-printed message itself
*/
- len = pretty_print_commit(opt->commit_format, commit, ~0u, this_header, sizeof(this_header), abbrev, subject, extra_headers);
+ len = pretty_print_commit(opt->commit_format, commit, ~0u, this_header,
+ sizeof(this_header), abbrev, subject,
+ extra_headers, opt->relative_date);
if (opt->add_signoff)
len = append_signoff(this_header, sizeof(this_header), len,
diff --git a/revision.c b/revision.c
index 1d89d72..b588f74 100644
--- a/revision.c
+++ b/revision.c
@@ -816,6 +816,10 @@ int setup_revisions(int argc, const char
revs->simplify_history = 0;
continue;
}
+ if (!strcmp(arg, "--relative-date")) {
+ revs->relative_date = 1;
+ continue;
+ }
opts = diff_opt_parse(&revs->diffopt, argv+i, argc-i);
if (opts > 0) {
revs->diff = 1;
diff --git a/revision.h b/revision.h
index 0c3b8d9..d289781 100644
--- a/revision.h
+++ b/revision.h
@@ -55,7 +55,8 @@ struct rev_info {
/* Format info */
unsigned int shown_one:1,
- abbrev_commit:1;
+ abbrev_commit:1,
+ relative_date:1;
unsigned int abbrev;
enum cmit_fmt commit_format;
struct log_info *loginfo;
--
1.4.2.g6e47-dirty
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH] Refactor sha1_pack_index_name and sha1_pack_name to use a common backend
From: Jonas Fonseca @ 2006-08-28 13:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkp9tquz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote Sun, Aug 27, 2006:
> Jonas Fonseca <fonseca@diku.dk> writes:
>
> > This adds another pair of static buffers, if that's a problem and the
> > cleanup is still wanted I can change it to use malloc.
>
> As a clean-up, I'd rather see a patch that removes the need for
> these two functions and one struct member, rather than keeping
> these two misguided functions and consolidating their
> implementations.
Thanks for the outline, I will look into removing this limitation.
--
Jonas Fonseca
^ permalink raw reply
* Re: gitweb filter for patches by a specific person in a specific timeframe
From: Jakub Narebski @ 2006-08-28 13:13 UTC (permalink / raw)
To: Kai Blin, git
In-Reply-To: <200608281459.26643.kai.blin@gmail.com>
Kai Blin wrote:
> I have just completed my Google Summer of Code[1] project[2] working for the
> Wine project. Now, as I was submitting patches to a git repository, I don't
> have a branch solely containing my patches or something like that. Google
> seems to want something like this, so I figured maybe I could get gitweb to
> filter for my patches during the SoC period. Is that possible?
> If not, does it sound like something feasible to add?
It is possible. Simply enter "author:Kai Blin" (without space between ':'
and your name as it appears in author field) in the searchbox, and you
would get an URL similar to the URL below:
http://www.kernel.org/git/?p=git%2Fgit.git&a=search&h=HEAD&s=author%3AJonas+Fonseca
Of course you should first go to proper branch. If you are giving the link,
you can write it in more human-friendly form, e.g.
http://www.kernel.org/git/?p=git/git.git;a=search;h=HEAD;s=author:Jonas+Fonseca
Or you can just search for your name, which gives URL like this one
http://www.kernel.org/git/?p=git/git.git;a=search;h=HEAD;s=Jonas+Fonseca
which will find all commits in the lineage of given branch (HEAD is
the current branch) which have specified phrase in commit log (which
includes signoff lines)
> PS: Please CC me, as I'm not on the list.
You can always read the list using one of the many archives
of git@vger.kernel.org list, or using Usenet (news) client via NNTP
gateway at GMane (nntp://news.gmane.org/gmane.comp.version-control.git).
See http://git.or.cz/gitwiki/GitCommunity
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* gitweb filter for patches by a specific person in a specific timeframe
From: Kai Blin @ 2006-08-28 12:59 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 773 bytes --]
Hi folks,
I have just completed my Google Summer of Code[1] project[2] working for the
Wine project. Now, as I was submitting patches to a git repository, I don't
have a branch solely containing my patches or something like that. Google
seems to want something like this, so I figured maybe I could get gitweb to
filter for my patches during the SoC period. Is that possible?
If not, does it sound like something feasible to add?
Cheers,
Kai
PS: Please CC me, as I'm not on the list.
[1] http://code.google.com/soc/
[2] http://wiki.winehq.org/NtlmSigningAndSealing
--
Kai Blin, <kai Dot blin At gmail Dot com>
WorldForge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin/
--
Will code for cotton.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 4/5] gitweb: git_print_log: signoff line is non-empty line
From: Jakub Narebski @ 2006-08-28 12:48 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11567692943154-git-send-email-jnareb@gmail.com>
This correct minor error in git_print_log that didn't add final empty
line when requested, if commit log ended with signoff.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 81d3e76..8987967 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1394,6 +1394,7 @@ sub git_print_log ($;%) {
foreach my $line (@$log) {
if ($line =~ m/^ *(signed[ \-]off[ \-]by[ :]|acked[ \-]by[ :]|cc[ :])/i) {
$signoff = 1;
+ $empty = 0;
if (! $opts{'-remove_signoff'}) {
print "<span class=\"signoff\">" . esc_html($line) . "</span><br/>\n";
next;
--
1.4.1.1
^ permalink raw reply related
* [PATCH 3/5] gitweb: Add author information to commitdiff view
From: Jakub Narebski @ 2006-08-28 12:48 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11567692943154-git-send-email-jnareb@gmail.com>
Add subroutine git_print_authorship to print author and date of
commit, div.author_date style to CSS, and use them in git_commitdiff.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.css | 7 +++++++
gitweb/gitweb.perl | 11 +++++++++++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index afd9e8a..eb9fc38 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -116,6 +116,13 @@ div.list_head {
font-style: italic;
}
+div.author_date {
+ padding: 8px;
+ border: solid #d9d8d1;
+ border-width: 0px 0px 1px 0px;
+ font-style: italic;
+}
+
a.list {
text-decoration: none;
color: #000000;
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c2dcc6c..81d3e76 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1341,6 +1341,16 @@ sub git_print_header_div {
"\n</div>\n";
}
+#sub git_print_authorship (\%) {
+sub git_print_authorship {
+ my $co = shift;
+
+ my %ad = parse_date($co->{'author_epoch'});
+ print "<div class=\"author_date\">" .
+ esc_html($co->{'author_name'}) .
+ " [$ad{'rfc2822'}]</div>\n";
+}
+
sub git_print_page_path {
my $name = shift;
my $type = shift;
@@ -2914,6 +2924,7 @@ sub git_commitdiff {
git_header_html(undef, $expires);
git_print_page_nav('commitdiff','', $hash,$co{'tree'},$hash, $formats_nav);
git_print_header_div('commit', esc_html($co{'title'}) . $ref, $hash);
+ git_print_authorship(\%co);
print "<div class=\"page_body\">\n";
print "<div class=\"log\">\n";
git_print_simplified_log($co{'comment'}, 1); # skip title
--
1.4.1.1
^ permalink raw reply related
* [PATCH 0/5] gitweb: Additions to commitdiff view
From: Jakub Narebski @ 2006-08-28 12:48 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
This series of patches makes signoff lines to be not removed in commitdiff and log
views, adds author information to comittdiff view, and adds diff tree with links
to patches in commitdiff view.
You will be able to see it at work at
http://front.fuw.edu.pl/cgi-bin/jnareb/gitweb.cgi
Shortlog:
---------
1/5 gitweb: Make git_print_log generic; git_print_simplified_log uses it
2/5 gitweb: Do not remove signoff lines in git_print_simplified_log
3/5 gitweb: Add author information to commitdiff view
4/5 gitweb: git_print_log: signoff line is non-empty line
5/5 gitweb: Add diff tree, with links to patches, to commitdiff view
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* [PATCH 1/5] gitweb: Make git_print_log generic; git_print_simplified_log uses it
From: Jakub Narebski @ 2006-08-28 12:48 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11567692943154-git-send-email-jnareb@gmail.com>
Collapse git_print_log and git_print_simplified_log into one
subroutine git_print_log. git_print_simplified_log now simply calls
git_print_log with proper options.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 63 ++++++++++++++++++++++++++--------------------------
1 files changed, 31 insertions(+), 32 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 59f1a87..e318f50 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1364,9 +1364,15 @@ sub git_print_page_path {
}
}
-sub git_print_log {
+# sub git_print_log (\@;%) {
+sub git_print_log ($;%) {
my $log = shift;
+ my %opts = @_;
+ if ($opts{'-remove_title'}) {
+ # remove title, i.e. first line of log
+ shift @$log;
+ }
# remove leading empty lines
while (defined $log->[0] && $log->[0] eq "") {
shift @$log;
@@ -1376,6 +1382,19 @@ sub git_print_log {
my $signoff = 0;
my $empty = 0;
foreach my $line (@$log) {
+ if ($line =~ m/^ *(signed[ \-]off[ \-]by[ :]|acked[ \-]by[ :]|cc[ :])/i) {
+ $signoff = 1;
+ if (! $opts{'-remove_signoff'}) {
+ print "<span class=\"signoff\">" . esc_html($line) . "</span><br/>\n";
+ next;
+ } else {
+ # remove signoff lines
+ next;
+ }
+ } else {
+ $signoff = 0;
+ }
+
# print only one empty line
# do not print empty line after signoff
if ($line eq "") {
@@ -1384,13 +1403,13 @@ sub git_print_log {
} else {
$empty = 0;
}
- if ($line =~ m/^ *(signed[ \-]off[ \-]by[ :]|acked[ \-]by[ :]|cc[ :])/i) {
- $signoff = 1;
- print "<span class=\"signoff\">" . esc_html($line) . "</span><br/>\n";
- } else {
- $signoff = 0;
- print format_log_line_html($line) . "<br/>\n";
- }
+
+ print format_log_line_html($line) . "<br/>\n";
+ }
+
+ if ($opts{'-final_empty_line'}) {
+ # end with single empty line
+ print "<br/>\n" unless $empty;
}
}
@@ -1398,30 +1417,10 @@ sub git_print_simplified_log {
my $log = shift;
my $remove_title = shift;
- shift @$log if $remove_title;
- # remove leading empty lines
- while (defined $log->[0] && $log->[0] eq "") {
- shift @$log;
- }
-
- # simplify and print log
- my $empty = 0;
- foreach my $line (@$log) {
- # remove signoff lines
- if ($line =~ m/^ *(signed[ \-]off[ \-]by[ :]|acked[ \-]by[ :]|cc[ :])/i) {
- next;
- }
- # print only one empty line
- if ($line eq "") {
- next if $empty;
- $empty = 1;
- } else {
- $empty = 0;
- }
- print format_log_line_html($line) . "<br/>\n";
- }
- # end with single empty line
- print "<br/>\n" unless $empty;
+ git_print_log($log,
+ -final_empty_line=> 1,
+ -remove_signoff => 1,
+ -remove_title => $remove_title);
}
## ......................................................................
--
1.4.1.1
^ permalink raw reply related
* [PATCH 5/5] gitweb: Add diff tree, with links to patches, to commitdiff view
From: Jakub Narebski @ 2006-08-28 12:48 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11567692943154-git-send-email-jnareb@gmail.com>
Added/uncommented git_difftree_body invocation in git_commitdiff.
Added anchors (via 'id' attribute) to patches in patchset.
git_difftree_body is modified to link to patch anchor when called from
git_commitdiff, instead of link to blobdiff.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 71 ++++++++++++++++++++++++++++++++++++----------------
1 files changed, 49 insertions(+), 22 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8987967..ef09cf5 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1447,6 +1447,7 @@ sub git_difftree_body {
print "<table class=\"diff_tree\">\n";
my $alternate = 0;
+ my $patchno = 0;
foreach my $line (@{$difftree}) {
my %diff = parse_difftree_raw_line($line);
@@ -1487,8 +1488,14 @@ sub git_difftree_body {
"<td class=\"link\">" .
$cgi->a({-href => href(action=>"blob", hash=>$diff{'to_id'},
hash_base=>$hash, file_name=>$diff{'file'})},
- "blob") .
- "</td>\n";
+ "blob");
+ if ($action == "commitdiff") {
+ # link to patch
+ $patchno++;
+ print " | " .
+ $cgi->a({-href => "#patch$patchno"}, "patch");
+ }
+ print "</td>\n";
} elsif ($diff{'status'} eq "D") { # deleted
my $mode_chng = "<span class=\"file_status deleted\">[deleted $from_file_type]</span>";
@@ -1502,8 +1509,14 @@ sub git_difftree_body {
$cgi->a({-href => href(action=>"blob", hash=>$diff{'from_id'},
hash_base=>$parent, file_name=>$diff{'file'})},
"blob") .
- " | " .
- $cgi->a({-href => href(action=>"history", hash_base=>$parent,
+ " | ";
+ if ($action == "commitdiff") {
+ # link to patch
+ $patchno++;
+ print " | " .
+ $cgi->a({-href => "#patch$patchno"}, "patch");
+ }
+ print $cgi->a({-href => href(action=>"history", hash_base=>$parent,
file_name=>$diff{'file'})},
"history") .
"</td>\n";
@@ -1539,16 +1552,23 @@ sub git_difftree_body {
print "</td>\n" .
"<td>$mode_chnge</td>\n" .
"<td class=\"link\">" .
- $cgi->a({-href => href(action=>"blob", hash=>$diff{'to_id'},
- hash_base=>$hash, file_name=>$diff{'file'})},
- "blob");
+ $cgi->a({-href => href(action=>"blob", hash=>$diff{'to_id'},
+ hash_base=>$hash, file_name=>$diff{'file'})},
+ "blob");
if ($diff{'to_id'} ne $diff{'from_id'}) { # modified
- print " | " .
- $cgi->a({-href => href(action=>"blobdiff",
- hash=>$diff{'to_id'}, hash_parent=>$diff{'from_id'},
- hash_base=>$hash, hash_parent_base=>$parent,
- file_name=>$diff{'file'})},
- "diff");
+ if ($action == "commitdiff") {
+ # link to patch
+ $patchno++;
+ print " | " .
+ $cgi->a({-href => "#patch$patchno"}, "patch");
+ } else {
+ print " | " .
+ $cgi->a({-href => href(action=>"blobdiff",
+ hash=>$diff{'to_id'}, hash_parent=>$diff{'from_id'},
+ hash_base=>$hash, hash_parent_base=>$parent,
+ file_name=>$diff{'file'})},
+ "diff");
+ }
}
print " | " .
$cgi->a({-href => href(action=>"history",
@@ -1578,12 +1598,19 @@ sub git_difftree_body {
hash=>$diff{'to_id'}, file_name=>$diff{'to_file'})},
"blob");
if ($diff{'to_id'} ne $diff{'from_id'}) {
- print " | " .
- $cgi->a({-href => href(action=>"blobdiff",
- hash=>$diff{'to_id'}, hash_parent=>$diff{'from_id'},
- hash_base=>$hash, hash_parent_base=>$parent,
- file_name=>$diff{'to_file'}, file_parent=>$diff{'from_file'})},
- "diff");
+ if ($action == "commitdiff") {
+ # link to patch
+ $patchno++;
+ print " | " .
+ $cgi->a({-href => "#patch$patchno"}, "patch");
+ } else {
+ print " | " .
+ $cgi->a({-href => href(action=>"blobdiff",
+ hash=>$diff{'to_id'}, hash_parent=>$diff{'from_id'},
+ hash_base=>$hash, hash_parent_base=>$parent,
+ file_name=>$diff{'to_file'}, file_parent=>$diff{'from_file'})},
+ "diff");
+ }
}
print "</td>\n";
@@ -1616,7 +1643,7 @@ sub git_patchset_body {
# first patch in patchset
$patch_found = 1;
}
- print "<div class=\"patch\">\n";
+ print "<div class=\"patch\" id=\"patch". ($patch_idx+1) ."\">\n";
if (ref($difftree->[$patch_idx]) eq "HASH") {
$diffinfo = $difftree->[$patch_idx];
@@ -2958,8 +2985,8 @@ TEXT
# write patch
if ($format eq 'html') {
- #git_difftree_body(\@difftree, $hash, $hash_parent);
- #print "<br/>\n";
+ git_difftree_body(\@difftree, $hash, $hash_parent);
+ print "<br/>\n";
git_patchset_body($fd, \@difftree, $hash, $hash_parent);
close $fd;
--
1.4.1.1
^ permalink raw reply related
* [PATCH 2/5] gitweb: Do not remove signoff lines in git_print_simplified_log
From: Jakub Narebski @ 2006-08-28 12:48 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11567692943154-git-send-email-jnareb@gmail.com>
Remove '-remove_signoff => 1' option to git_print_log call in the
git_print_simplified_log subroutine. This means that in "log" and
"commitdiff" views (git_log and git_commitdiff subroutines) signoff
lines will be shown.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e318f50..c2dcc6c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1419,7 +1419,6 @@ sub git_print_simplified_log {
git_print_log($log,
-final_empty_line=> 1,
- -remove_signoff => 1,
-remove_title => $remove_title);
}
--
1.4.1.1
^ permalink raw reply related
* What's in git.git
From: Junio C Hamano @ 2006-08-28 7:19 UTC (permalink / raw)
To: git; +Cc: linux-kernel
This is CC'ed to the kernel list as well because the "master"
update is rather large.
On the "maint" front, I've been wanting to cut 1.4.2.1 for some
time, but various time constraints prevented me doing so so far.
I have a vague suspicion that 1.4.3 might happen before that.
Also I have been sort-of waiting for the x86-32 machine at
kernel.org to become available again so that I can do an RPM for
end users, which unfortunately hasn't happened yet.
* The 'maint' branch has these fixes since the last announcement.
Johannes Schindelin:
git-mv: special case destination "."
git-mv: fix off-by-one error
builtin-mv: readability patch
* The 'master' branch has these since the last announcement.
- Johannes's reimplementation of merge-recursive in C is in
'master' for early adopter testing. Currently it is called
'merge-recur', so you either (1) invoke it explicitly with
the -s option to 'git pull' and/or 'git merge', or (2) have
an environment variable GIT_USE_RECUR_FOR_RECURSIVE set to
non-empty string, in which case places that call
'git-merge-recursive' would use 'git-merge-recur' instead.
This has been tested in 'next' for some time, and Johannes
ran tests to reproduce all merges in post 2.6.12-rc2 kernel
history to validate it produces the same result as the
current merge-recursive. The only difference is that it is
about 6x-10x faster and you do not have to have Python
installed.
I intend to retire the current merge-recursive.py and
replace it with merge-recur before 1.4.3 happens.
- Various calls to memcmp/memcpy/memset with length '20' to
compare, copy and clear object names have been abstracted
out to hashcmp/hashcpy/hashclr wrappers, spearheaded by
David Rientjes. This would make it easier to migrate the
code to hashes of other lengths if it is ever needed.
Obviously migrating the existing data is another story.
- Updates to git-svn by Eric Wong.
- git-apply can be given --reject to produce *.rej files,
instead of failing the whole patch atomically. It also can
be given --verbose to report what it is doing.
- Rene Scharfe helped git-tar-tree find its soulmate
git-zip-tree.
- Tilman Sauerbeck taught git-daemon to setuid/setgid before
serving the clients.
- Various small fixes and clean-ups by Haavard Skinnemoen, Jakub
Narebski, Jonas Fonseca, Pierre Habouzit, Rene Scharfe,
Shawn Pearce, and Tilman Sauerbeck.
- Various documentation clean-ups by Jonas Fonseca, and Rene
Scharfe.
- The internal is readied to be able to say "32 hours ago" in
"git log" and friends by Linus; we do not have an UI to
enable it yet.
* The 'next' branch, in addition, has these.
- Various gitweb updates by Jakub Narebski with help from
Aneesh Kumar, Luben Tuikov, and Martin Waitz. The most
attractive thing these updates have is that we finally got
rid of having to use temporary files to show diffs.
I'd like to push this out to "master" soonish. You can get
a taste of how it works at the site Jakub maintains
http://front.fuw.edu.pl/cgi-bin/jnareb/gitweb.cgi
- Git.pm by Pasky with help from Dennis Stosberg, Eric Wong,
Johannes, and Pavel Roskin. During the next round I'd like
to push this out to "master" to see who screams ;-).
- upload-pack has a bit of updates still held back.
- git-daemon is taught to optionally serve git-tar-tree
output.
* In the 'pu' branch, I have my WIP of a library to walk the
index, the working tree, and zero or more tree objects in
parallel. Its test program does something that vaguely looks
like diff-index with and without --cached in parallel, but it
is not polished enough for public testing/consumption yet.
^ 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