* 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: gitweb filter for patches by a specific person in a specific timeframe
From: Jeff King @ 2006-08-28 18:16 UTC (permalink / raw)
To: Kai Blin; +Cc: git
In-Reply-To: <200608281459.26643.kai.blin@gmail.com>
On Mon, Aug 28, 2006 at 02:59:21PM +0200, 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?
You can create an mbox of all of the changes you made. Unfortunately
git-rev-list doesn't do author/committer matching, so you'll need a
short perl script:
-- >8 --
$ cat >match-who.pl <<'EOF'
#!/usr/bin/perl
my $name = shift;
my $match = qr/$name/i;
my $commit;
while(<>) {
chomp;
next unless $_;
next if /^\s/;
my ($k, $v) = split / /, $_, 2;
if($k eq 'commit') {
$commit = $v;
}
if($commit && ($k eq 'author' || $k eq 'committer') && $v =~ $match) {
print "$commit\n";
$commit = undef;
}
}
-- >8 --
Then you should be able to do:
$ git-rev-list --pretty=raw master |
perl match-who.pl kai.blin@gmail.com |
git-diff-tree -p --stdin --pretty=email \
> my-patches
You can either look through that, or you can try applying the patches
with git-am (though if your patches depend on changes not by you that
happened in the intervening time, you'll probably have some rejects).
-Peff
^ permalink raw reply
* Re: Starting to think about sha-256?
From: Jeff King @ 2006-08-28 18:32 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Lang, Johannes Schindelin, Krzysztof Halasa, Jeff Garzik,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0608281034440.27779@g5.osdl.org>
On Mon, Aug 28, 2006 at 10:56:01AM -0700, Linus Torvalds wrote:
> 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
This concept breaks down somewhat if you are pulling from two
repositories (one good and one evil). If I pull from the evil repo
first, that will become my "earlier" object, and I will never get the
colliding object from the good repo.
Executing such an attack might not be that hard, either (once we get
over that little hump of creating collisions at will!). The owner of
'evil' has to know a SHA1 that will be in 'good' before it makes it to
'good'. However, I imagine we frequently see SHA1s migrate from more
central repos (like .../torvalds/linux-2.6.git) to less central ones
(subsystem / port maintainers, etc).
-Peff
^ permalink raw reply
* Re: Starting to think about sha-256?
From: Linus Torvalds @ 2006-08-28 18:46 UTC (permalink / raw)
To: Jeff King
Cc: David Lang, Johannes Schindelin, Krzysztof Halasa, Jeff Garzik,
Git Mailing List
In-Reply-To: <20060828183252.GC2950@coredump.intra.peff.net>
On Mon, 28 Aug 2006, Jeff King wrote:
>
> On Mon, Aug 28, 2006 at 10:56:01AM -0700, Linus Torvalds wrote:
>
> > 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
>
> This concept breaks down somewhat if you are pulling from two
> repositories (one good and one evil). If I pull from the evil repo
> first, that will become my "earlier" object, and I will never get the
> colliding object from the good repo.
Sure. But if you are pulling from an untrusted source, you'd better at
least check the result.
In fact, that's partly why "git pull" will do a diffstat after the pull.
Exactly to force people to at least be minimally aware of what they
pulled. And "gitk ORIG_HEAD.." is a great thing to always run when you
pull from somebody you don't know and trust really well.
Of course, that all was done mostly not because I don't "trust" the people
I work with, but more because I didn't always trust that they'd do the
right thing with git (ie they'd screw up the repo not because they were
evil, but because they made a mistake).
So even if you pull from an "evil" repo first, and you somehow get a "bad"
object, the point is, the bad object _should_ be the one that overrides.
Why? Because once you find out that the evil repo was bad (which you'll
eventually find simply because it caused some bug - if the evil repo only
helps you, it's obviously not evil at all), what you need to do is reset
to _before_ the evil repo happened, do a "git repack -a -d" and finally a
"git prune" to clean out all the bad cruft, and then pull the good repo
without pulling the bad one first.
After that, you apologize to everybody for screwing up and pulling from
somebody you didn't trust, and then ask them to re-clone (or give them the
appropriate "git reset" + "git repack -a" + "git prune" + "git pull"
sequence so that they can fix their existing repos).
The point being, a hash attack is really no worse than an attack that
fools you into applying a really bad diff (regardless of SCM), and it's a
hell of a lot harder to do. Both a hash attack and a diff attack mean that
the person merging data should either trust his source or inspect the end
result.
Anybody who just blindly accepts data from untrusted sources is screwed in
so many other ways that the hash attack simply isn't even on the radar.
Linus
^ permalink raw reply
* Re: Starting to think about sha-256?
From: Jeff King @ 2006-08-28 19:00 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Lang, Johannes Schindelin, Krzysztof Halasa, Jeff Garzik,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0608281137530.27779@g5.osdl.org>
On Mon, Aug 28, 2006 at 11:46:39AM -0700, Linus Torvalds wrote:
> Sure. But if you are pulling from an untrusted source, you'd better at
> least check the result.
I completely agree; however, even discussing "earlier takes precedence"
entails that you are somehow pulling from an untrusted source. I just
wanted to point out that "earlier" does not always mean "more trusted
than the thing you're pulling now" (since it might have just been pulled
earlier, not created or verified by you).
> Anybody who just blindly accepts data from untrusted sources is screwed in
> so many other ways that the hash attack simply isn't even on the radar.
Agreed.
-Peff
^ permalink raw reply
* Re: gitweb filter for patches by a specific person in a specific timeframe
From: Linus Torvalds @ 2006-08-28 19:04 UTC (permalink / raw)
To: Jeff King; +Cc: Kai Blin, git
In-Reply-To: <20060828181626.GB2950@coredump.intra.peff.net>
On Mon, 28 Aug 2006, Jeff King wrote:
>
> You can create an mbox of all of the changes you made. Unfortunately
> git-rev-list doesn't do author/committer matching, so you'll need a
> short perl script:
The author/committer matching is something that people have talked about
for a long time, so maybe we should just add it?
It shouldn't be that hard at all. Just add logic to revision.c:
get_revision(), something like the appended (fleshed out and fixed, of
course, with all the command line flags added to actually allow setting of
"revs->author_pattern" etc..)
A good thing for some beginning git hacker to try doing. Hint, hint.
(The only subtle thing might be to make sure that "save_commit_buffer" is
set if author/committer matching is on, so that the "commit->buffer" thing
is actually saved after parsing, so that you can match it)
This trivial approach doesn't allow "gitk" to show the results sanely,
though (to do that, you'd need to make the commit matching be part of the
parent simplification instead - that would be extra bonus points for the
intrpid git hacker-wannabe)
Linus
---
diff --git a/revision.c b/revision.c
index 1d89d72..88cc1e3 100644
--- a/revision.c
+++ b/revision.c
@@ -1011,6 +1011,13 @@ static void mark_boundary_to_show(struct
}
}
+static int commit_match(struct commit *commit, const char *field, const char *pattern)
+{
+ if (!pattern)
+ return 1;
+ .. match it here ..
+}
+
struct commit *get_revision(struct rev_info *revs)
{
struct commit_list *list = revs->commits;
@@ -1070,6 +1077,10 @@ struct commit *get_revision(struct rev_i
if (revs->no_merges &&
commit->parents && commit->parents->next)
continue;
+ if (!commit_match(commit, "author", revs->author_pattern))
+ continue;
+ if (!commit_match(commit, "committer", revs->committer_pattern))
+ continue;
if (revs->prune_fn && revs->dense) {
/* Commit without changes? */
if (!(commit->object.flags & TREECHANGE)) {
^ permalink raw reply related
* Re: Starting to think about sha-256?
From: Krzysztof Halasa @ 2006-08-28 20:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Lang, Johannes Schindelin, Jeff Garzik, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0608281034440.27779@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> 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.
Actually I think we may see it when somebody tries to put a real
example of conflicting SHA-1 pair into git repository.
--
Krzysztof Halasa
^ permalink raw reply
* Re: Starting to think about sha-256?
From: Linus Torvalds @ 2006-08-28 20:20 UTC (permalink / raw)
To: Krzysztof Halasa
Cc: David Lang, Johannes Schindelin, Jeff Garzik, Git Mailing List
In-Reply-To: <m34pvwfwl5.fsf@defiant.localdomain>
On Mon, 28 Aug 2006, Krzysztof Halasa wrote:
>
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > 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.
>
> Actually I think we may see it when somebody tries to put a real
> example of conflicting SHA-1 pair into git repository.
Well, by definition, I wouldn't call that "inadvertent" ;)
Anyway, the way to do it (if you want to use git to document SHA1 hash
mismatches) is to just check the files that have an identical SHA1 in. It
will magically work!
Why? Because a git SHA1 is actually _not_ the SHA1 of the file itself,
it's the SHA1 of the file _with_the_git_header_added_.
So if you find two files that have the same SHA1, they would also have to
have the same length in order to actually generate the same object name.
If they have different lenths, you can just check them into git, and
they'll get two different git SHA1 names and you'll have a cool git
archive that when you check the files out, they checked-out files will
share the same SHA1 ;)
Linus
^ permalink raw reply
* Re: Starting to think about sha-256?
From: Krzysztof Halasa @ 2006-08-28 21:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Lang, Johannes Schindelin, Jeff Garzik, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0608281317070.27779@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Anyway, the way to do it (if you want to use git to document SHA1 hash
> mismatches) is to just check the files that have an identical SHA1 in. It
> will magically work!
>
> Why? Because a git SHA1 is actually _not_ the SHA1 of the file itself,
> it's the SHA1 of the file _with_the_git_header_added_.
>
> So if you find two files that have the same SHA1, they would also have to
> have the same length in order to actually generate the same object name.
Well, conflicting files will most probably have the same size,
like with MD5 cases :-)
--
Krzysztof Halasa
^ permalink raw reply
* [PATCH] gitweb: Add local time and timezone to git_print_authorship
From: Jakub Narebski @ 2006-08-28 21:17 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0608281016380.27779@g5.osdl.org>
Linus Torvalds wrote:
> 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.
-- >8 --
Add local time (hours and minutes) and local timezone to the output of
git_print_authorship command, used by git_commitdiff. The code was
taken from git_commit subroutine.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ef09cf5..fa7f62a 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1345,10 +1345,18 @@ #sub git_print_authorship (\%) {
sub git_print_authorship {
my $co = shift;
- my %ad = parse_date($co->{'author_epoch'});
+ my %ad = parse_date($co->{'author_epoch'}, $co->{'author_tz'});
print "<div class=\"author_date\">" .
esc_html($co->{'author_name'}) .
- " [$ad{'rfc2822'}]</div>\n";
+ " [$ad{'rfc2822'}";
+ if ($ad{'hour_local'} < 6) {
+ printf(" (<span class=\"atnight\">%02d:%02d</span> %s)",
+ $ad{'hour_local'}, $ad{'minute_local'}, $ad{'tz_local'});
+ } else {
+ printf(" (%02d:%02d %s)",
+ $ad{'hour_local'}, $ad{'minute_local'}, $ad{'tz_local'});
+ }
+ print "]</div>\n";
}
sub git_print_page_path {
--
1.4.1.1
^ permalink raw reply related
* Re: Starting to think about sha-256?
From: Linus Torvalds @ 2006-08-28 21:23 UTC (permalink / raw)
To: Krzysztof Halasa
Cc: David Lang, Johannes Schindelin, Jeff Garzik, Git Mailing List
In-Reply-To: <m3r6z0ef95.fsf@defiant.localdomain>
On Mon, 28 Aug 2006, Krzysztof Halasa wrote:
>
> Well, conflicting files will most probably have the same size,
> like with MD5 cases :-)
That's only true for the much easier injection case where you generate
_both_ files together.
>From an external git hash-attack standpoint, that's not a very useful
case. It's much more useful if you can make a new file that has a hash
that matches a given old file, and in that case, the filelengths are
likely not the same.
Linus
^ permalink raw reply
* Re: [PATCH] Add git-zip-tree to .gitignore
From: Rene Scharfe @ 2006-08-28 22:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhczxvlar.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano schrieb:
> Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> Junio C Hamano schrieb:
>>> Although it was my fault applying it already to "master" without
>>> asking this question first, I started to wonder how many more archive
>>> format people would want, and if it might make more sense to
>>> consolidate git-*-tree into a single frontend with an option to
>>> specify the archiver.
>>>
>>> We would obviously need to keep git-tar-tree as a backward
>>> compatibility alias for "git archive-tree -f tar", but doing things
>>> that way we do not have to introduce unbounded number of new
>>> git-{zip,rar,...}-tree programs.
>> That thought occurred to me, too. I guess there are not that many more
>> interesting archive formats, though. Can we defer adding
>> git-archive-tree until a third archive format command appears? I won't
>> submit another one, I promise. ;-)
>
> I was more worried about possibly having to do --remote once in
> each for tar-tree and zip-tree in git-daemon. The version of
> daemon currently in "pu" can allow git-tar-tree to be accessed
> from the client via git:// URL.
Good point. And especially for net transfers a compressed format like
ZIP or TGZ (not yet implemented) would be better.
Would it make sense to have just one multiplexer command? I.e.
something like this:
git-archive -f <format> [extra] <tree-ish> [<base>]
git-archive -f <format> [extra] --upload <tree-ish> [<base>]
git-archive -f <format> [extra] --remote=<url> <tree-ish> [<base>]
[extra] stands for format specific options like the compression ratio
for ZIP. The protocol spoken by upload and --remote would need to be
extended to be able to specify the format and any format specific options.
While we're discussing the command line interface, would it make sense
to support path specs, like e.g. ls-tree does? Like this:
git-archive -f <format> [extra] [--prefix=<base>] <tree-ish> [<path>]
Personally, I don't see the need for path specs for archive creation,
but IF we want to introduce them then the best time to do it would be
now, at the same time as introducing git-archive (or git-archive-tree).
René
^ permalink raw reply
* Re: [PATCH] Add git-zip-tree to .gitignore
From: Junio C Hamano @ 2006-08-28 22:43 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <44F36E03.9090802@lsrfire.ath.cx>
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Junio C Hamano schrieb:
>>
>> I was more worried about possibly having to do --remote once in
>> each for tar-tree and zip-tree in git-daemon. The version of
>> daemon currently in "pu" can allow git-tar-tree to be accessed
>> from the client via git:// URL.
>
> Good point. And especially for net transfers a compressed format like
> ZIP or TGZ (not yet implemented) would be better.
>
> Would it make sense to have just one multiplexer command? I.e.
> something like this:
>
> git-archive -f <format> [extra] <tree-ish> [<base>]
> git-archive -f <format> [extra] --upload <tree-ish> [<base>]
> git-archive -f <format> [extra] --remote=<url> <tree-ish> [<base>]
>
> [extra] stands for format specific options like the compression ratio
> for ZIP. The protocol spoken by upload and --remote would need to be
> extended to be able to specify the format and any format specific options.
I think so. I never liked the --remote support that was done
inside tar-tree myself and hoped there would be better ways.
> While we're discussing the command line interface, would it make sense
> to support path specs, like e.g. ls-tree does? Like this:
>
> git-archive -f <format> [extra] [--prefix=<base>] <tree-ish> [<path>]
>
> Personally, I don't see the need for path specs for archive creation,
> but IF we want to introduce them then the best time to do it would be
> now, at the same time as introducing git-archive (or git-archive-tree).
Well people may want to say more than one <path> to archive only
"include/asm-i386" and "arch/i386" directories, but other than
that, naming <tree-ish> with <revision>:<path> syntax would be
enough. But I agree with you that it would be now IF we want to
do this. I am neutral, perhaps slightly in favor.
^ permalink raw reply
* Re: Starting to think about sha-256?
From: Johannes Schindelin @ 2006-08-28 23:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Lang, Krzysztof Halasa, Jeff Garzik, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0608281034440.27779@g5.osdl.org>
Hi,
On Mon, 28 Aug 2006, Linus Torvalds wrote:
>
>
> 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.
The only notable exception I can think of: "git fetch -k". If you then try
to retrieve the bogus object, it will return the one of whichever pack was
returned first be readdir(). (If I read the source correctly.)
Now, the cases are rare where you do both "git fetch -k" and "git repack
-a -d" (the latter of which _could_ leave a hole in the directory which
_could_ make the next fetched pack fill that hole, which in turn _could_
make readdir() return that pack before more "senior" packs) in the same
repository, but in these cases, yes, you could end up with the copy of the
remote side.
You'd need to explicitely use "git fetch -k", though.
Ciao,
Dscho
^ permalink raw reply
* Re: Starting to think about sha-256?
From: Linus Torvalds @ 2006-08-28 23:48 UTC (permalink / raw)
To: Johannes Schindelin
Cc: David Lang, Krzysztof Halasa, Jeff Garzik, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0608290101320.28360@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 29 Aug 2006, Johannes Schindelin wrote:
>
> > 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.
>
> The only notable exception I can think of: "git fetch -k". If you then try
> to retrieve the bogus object, it will return the one of whichever pack was
> returned first be readdir(). (If I read the source correctly.)
Good point.
I didn't even think of "-k", since I mentally put that in the "initial
clone usage only" category, but yeah, if people use it for incremental
updates too, that could indeed cause ambiguity in which object to use when
the other end does something bad.
Linus
^ permalink raw reply
* Re: [PATCH] gitweb: Add local time and timezone to git_print_authorship
From: Junio C Hamano @ 2006-08-29 0:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <11567998513000-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Add local time (hours and minutes) and local timezone to the output of
> git_print_authorship command, used by git_commitdiff.
Looks nice, thanks.
Now I got envious seeing people are having SO MUCH FUN with
gitweb, so here is mine...
Likes, dislikes, "your color selection sucks ;-)",... ?
-- >8 --
gitweb: show age and author in blame output
This does two things.
- The commit object name link on each link uses "title", which
shows the author and age of the particular line when hovered
over.
- The background of these links are painted on darker color as
they become older and the links on younger lines are shown on
lighter background.
---
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index eb9fc38..008ee70 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -215,6 +215,12 @@ td.sha1 {
font-family: monospace;
}
+td.age-week { color: #00f; background-color: #fff; }
+td.age-month { color: #00f; background-color: #eef; }
+td.age-season { color: #00f; background-color: #ddf; }
+td.age-year { color: #00f; background-color: #ccf; }
+td.age-old { color: #00f; background-color: #bbf; }
+
td.error {
color: red;
background-color: yellow;
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9324d71..7dbd40f 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2190,7 +2190,7 @@ sub git_blame2 {
if ($ftype !~ "blob") {
die_error("400 Bad Request", "Object is not a blob");
}
- open ($fd, "-|", git_cmd(), "blame", '-l', $file_name, $hash_base)
+ open ($fd, "-|", git_cmd(), "blame", '-l', '-t', $file_name, $hash_base)
or die_error(undef, "Open git-blame failed");
git_header_html();
my $formats_nav =
@@ -2211,12 +2211,21 @@ sub git_blame2 {
<table class="blame">
<tr><th>Commit</th><th>Line</th><th>Data</th></tr>
HTML
+ my $now = time();
while (<$fd>) {
- /^([0-9a-fA-F]{40}).*?(\d+)\)\s{1}(\s*.*)/;
- my $full_rev = $1;
+ my ($full_rev, $author, $timestamp, $zone, $lineno, $data) =
+ /^([0-9a-fA-F]{40})\s\((.*?)\s+(\d+)\s
+ ([-+\d]{5})\s+(\d+)\)\s{1}(\s*.*)/x;
my $rev = substr($full_rev, 0, 8);
- my $lineno = $2;
- my $data = $3;
+
+ my $age = $now - $timestamp;
+ my $ago = age_string($age);
+ my $pop = "$author, $ago";
+ my $agegroup =
+ (($age < 60*60*24*7) ? "age-week" :
+ ($age < 60*60*24*30) ? "age-month" :
+ ($age < 60*60*24*120) ? "age-season" :
+ ($age < 60*60*24*360) ? "age-year" : "age-old");
if (!defined $last_rev) {
$last_rev = $full_rev;
@@ -2225,7 +2234,8 @@ HTML
$current_color = ++$current_color % $num_colors;
}
print "<tr class=\"$rev_color[$current_color]\">\n";
- print "<td class=\"sha1\">" .
+ print "<td class=\"sha1 $agegroup\" title=\"" .
+ esc_html($pop) ."\">" .
$cgi->a({-href => href(action=>"commit", hash=>$full_rev, file_name=>$file_name)},
esc_html($rev)) . "</td>\n";
print "<td class=\"linenr\"><a id=\"l$lineno\" href=\"#l$lineno\" class=\"linenr\">" .
^ permalink raw reply related
* Re: Packfile can't be mapped
From: Shawn Pearce @ 2006-08-29 4:52 UTC (permalink / raw)
To: git; +Cc: Jon Smirl
In-Reply-To: <20060828024720.GD24204@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> I'm going to try to get tree deltas written to the pack sometime this
> week.
I was able to implement and with Jon Smirl's help debug the tree
delta code in fast-import.
Earlier this evening Jon sent me the following:
> git-fast-import statistics:
> ---------------------------------------------------------------------
> Alloc'd objects: 1980000 ( 0 overflow )
> Total objects: 1967527 ( 41856 duplicates )
> blobs : 633842 ( 0 duplicates 576219 deltas)
> trees : 1131208 ( 41856 duplicates 1019741 deltas)
> commits: 200921 ( 0 duplicates 0 deltas)
> tags : 1556 ( 0 duplicates 0 deltas)
> Total branches: 1600 ( 2228 loads )
> marks: 1048576 ( 200921 unique )
> atoms: 56803
> Memory total: 75213 KiB
> pools: 13338 KiB
> objects: 61875 KiB
> Pack remaps: 658
> Pack size: 895983 KiB
> Index size: 46114 KiB
> ---------------------------------------------------------------------
Compared to our last attempt:
> > Pack size: 1713200 KiB
> > Index size: 46114 KiB
This tree delta version came out pretty good. The pack with tree
deltas is 874 MiB. Quite a reduction in size. fast-import takes
about 20 minutes to convert its 20 GiB input file into this 874 MiB
pack. Producing the 20 GiB input file from the 3 GiB CVS ,v
files takes about 4 hours with Jon's modified cvs2svn.
Jon has started a `git-repack -a -f` with aggressive depth and
window sizes. He estimated it may need another 2.5 hours to process.
Hopefully I'll hear more details tomorrow.
--
Shawn.
^ permalink raw reply
* Re: Packfile can't be mapped
From: Shawn Pearce @ 2006-08-29 5:33 UTC (permalink / raw)
To: git; +Cc: Jon Smirl
In-Reply-To: <20060829045239.GB24479@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> This tree delta version came out pretty good. The pack with tree
> deltas is 874 MiB. Quite a reduction in size. fast-import takes
> about 20 minutes to convert its 20 GiB input file into this 874 MiB
> pack. Producing the 20 GiB input file from the 3 GiB CVS ,v
> files takes about 4 hours with Jon's modified cvs2svn.
>
> Jon has started a `git-repack -a -f` with aggressive depth and
> window sizes. He estimated it may need another 2.5 hours to process.
> Hopefully I'll hear more details tomorrow.
I just heard from Jon:
> git-repack -a -f --window=50 --depth=5000
> 100% CPU for 60 minutes
> 1.2GB resident memory
> Final pack size is 451,203,363 bytes.
So with very agressive delta depth and window sizes git-repack took
a while to run but came very close to the best packed size from
previous Mozilla CVS import attempts. I think we'd still like to
make the final historical pack smaller than that.
--
Shawn.
^ permalink raw reply
* Re: [PATCH (amend)] gitweb: Use --git-dir parameter instead of setting $ENV{'GIT_DIR'}
From: Dennis Stosberg @ 2006-08-29 7:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <11567801982990-git-send-email-jnareb@gmail.com>
Jakub Narebski wrote:
> Dennis, could you check that it works for you in 'next'
> version of gitweb? The patch you sent is pre-rename even...
Yes, it works for me.
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
There is another trivial failure with mod_perl: The configuration file
will only be read on the first invocation of the script. I didn't
notice it until today, because I never used a configuration file before.
Regards,
Dennis
^ permalink raw reply
* [PATCH] use do() instead of require() to include configuration
From: Dennis Stosberg @ 2006-08-29 7:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <11567801982990-git-send-email-jnareb@gmail.com>
When run under mod_perl, require() will read and execute the configuration
file on the first invocation only. On every subsequent invocation, all
configuration variables will be reset to their default values. do() reads
and executes the configuration file unconditionally.
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 352236b..39ebcf4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -152,7 +152,7 @@ # - one might want to include '-B' optio
our @diff_opts = ('-M'); # taken from git_commit
our $GITWEB_CONFIG = $ENV{'GITWEB_CONFIG'} || "++GITWEB_CONFIG++";
-require $GITWEB_CONFIG if -e $GITWEB_CONFIG;
+do $GITWEB_CONFIG if -e $GITWEB_CONFIG;
# version of the core git binary
our $git_version = qx($GIT --version) =~ m/git version (.*)$/ ? $1 : "unknown";
--
1.4.2
^ permalink raw reply related
* Re: [PATCH] gitweb: Add local time and timezone to git_print_authorship
From: Jakub Narebski @ 2006-08-29 8:23 UTC (permalink / raw)
To: git
In-Reply-To: <7vveocpfa3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Add local time (hours and minutes) and local timezone to the output of
>> git_print_authorship command, used by git_commitdiff.
>
> Looks nice, thanks.
>
> Now I got envious seeing people are having SO MUCH FUN with
> gitweb, so here is mine...
>
> Likes, dislikes, "your color selection sucks ;-)",... ?
>
> -- >8 --
> +td.age-week { color: #00f; background-color: #fff; }
> +td.age-month { color: #00f; background-color: #eef; }
> +td.age-season { color: #00f; background-color: #ddf; }
> +td.age-year { color: #00f; background-color: #ccf; }
> +td.age-old { color: #00f; background-color: #bbf; }
Could you use full hex color length? Everywhere else in CSS we use
6-char wide hex colours.
> + my $now = time();
> while (<$fd>) {
> - /^([0-9a-fA-F]{40}).*?(\d+)\)\s{1}(\s*.*)/;
> - my $full_rev = $1;
> + my ($full_rev, $author, $timestamp, $zone, $lineno, $data) =
> + /^([0-9a-fA-F]{40})\s\((.*?)\s+(\d+)\s
> + ([-+\d]{5})\s+(\d+)\)\s{1}(\s*.*)/x;
Nice compact style. But different from other parsing using regexp in gitweb.
And some of those other, e.g. parse_difftree_raw_line cannot use this style.
Doesn't matter much.
> my $rev = substr($full_rev, 0, 8);
> - my $lineno = $2;
> - my $data = $3;
> +
> + my $age = $now - $timestamp;
> + my $ago = age_string($age);
> + my $pop = "$author, $ago";
> + my $agegroup =
> + (($age < 60*60*24*7) ? "age-week" :
> + ($age < 60*60*24*30) ? "age-month" :
> + ($age < 60*60*24*120) ? "age-season" :
> + ($age < 60*60*24*360) ? "age-year" : "age-old");
We have age_class subroutine which does something similar.
I'm not sure if one subroutine can be used for those two situations.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: Add local time and timezone to git_print_authorship
From: Junio C Hamano @ 2006-08-29 9:05 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ed0ths$okn$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Could you use full hex color length? Everywhere else in CSS we use
> 6-char wide hex colours.
Will do for consistency's sake, although I do not think we
really care about the extra precision in this application.
> We have age_class subroutine which does something similar.
Yeah, but...
(1) When somebody says "there are three age classes: age0,
age1, and age2", can you tell which one represents older
ones? I think they are misnamed.
(2) The classification of age_class seems to be useful for the
project age, which is to check if anything happened in the
last two hours and last two days. Unless the project is
really dead/dormant it should not be more than a month. On
the other hand, a mature and stable project should have
more than 80% lines that are more than a year old, even if
it is very active and have many lines that are less than
two hours old.
The yardstick age_class uses is really geared toward
checking project's last activity and not appropriate for
use in blame. Luckily, blame2 does not use it.
(3) I'd like to eventually get rid of the abbreviated commit
object name from blame output, so the setting in gitweb.css
for table.blame td.age[012] (different colors and font
styles) is not appropriate for what I am shooting at.
I have a bit updated 3-series for review.
^ permalink raw reply
* [PATCH] gitweb: split output routine of blame2
From: Junio C Hamano @ 2006-08-29 9:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <7vveocpfa3.fsf@assigned-by-dhcp.cox.net>
Make the loop over blame output to collect lines belonging to the
same revision, and send it over to the output routine "flush_blame_lines".
This will let me do interesting things later.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
gitweb/gitweb.perl | 73 +++++++++++++++++++++++++++++++++++++---------------
1 files changed, 52 insertions(+), 21 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 555441d..28e1cfd 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2170,6 +2170,33 @@ sub git_tag {
git_footer_html();
}
+sub flush_blame_lines {
+ my ($color, $file_name, @line) = @_;
+ my $full_rev = shift @line;
+ my $rev = substr($full_rev, 0, 8);
+
+ for (@line) {
+ unless (/^[0-9a-fA-F]{40}.*?(\d+)\)\s(.*)/) {
+ print "<tr><td>(malformed blame output)</td></tr>";
+ next;
+ }
+ my $lineno = $1;
+ my $data = $2;
+ print "<tr class=\"$color\">\n";
+ print "<td class=\"sha1\">" .
+ $cgi->a({-href => href(action=>"commit",
+ hash=>$full_rev,
+ file_name=>$file_name)},
+ esc_html($rev)) . "</td>\n";
+ print +("<td class=\"linenr\">".
+ "<a id=\"l$lineno\" href=\"#l$lineno\" ".
+ "class=\"linenr\">" .
+ esc_html($lineno) . "</a></td>\n");
+ print "<td class=\"pre\">" . esc_html($data) . "</td>\n";
+ print "</tr>\n";
+ }
+}
+
sub git_blame2 {
my $fd;
my $ftype;
@@ -2205,33 +2232,37 @@ sub git_blame2 {
my @rev_color = (qw(light2 dark2));
my $num_colors = scalar(@rev_color);
my $current_color = 0;
- my $last_rev;
+ my @current_group = ();
print <<HTML;
<div class="page_body">
<table class="blame">
<tr><th>Commit</th><th>Line</th><th>Data</th></tr>
HTML
while (<$fd>) {
- /^([0-9a-fA-F]{40}).*?(\d+)\)\s{1}(\s*.*)/;
- my $full_rev = $1;
- my $rev = substr($full_rev, 0, 8);
- my $lineno = $2;
- my $data = $3;
-
- if (!defined $last_rev) {
- $last_rev = $full_rev;
- } elsif ($last_rev ne $full_rev) {
- $last_rev = $full_rev;
- $current_color = ++$current_color % $num_colors;
- }
- print "<tr class=\"$rev_color[$current_color]\">\n";
- print "<td class=\"sha1\">" .
- $cgi->a({-href => href(action=>"commit", hash=>$full_rev, file_name=>$file_name)},
- esc_html($rev)) . "</td>\n";
- print "<td class=\"linenr\"><a id=\"l$lineno\" href=\"#l$lineno\" class=\"linenr\">" .
- esc_html($lineno) . "</a></td>\n";
- print "<td class=\"pre\">" . esc_html($data) . "</td>\n";
- print "</tr>\n";
+ my $full_rev;
+ unless (($full_rev) = /^([0-9a-fA-F]{40})/) {
+ print "<tr><td>(malformed blame output)</td></tr>\n";
+ next;
+ }
+ if (@current_group) {
+ if (($current_group[0] ne $full_rev)) {
+ $current_color = ++$current_color % $num_colors;
+ flush_blame_lines($rev_color[$current_color],
+ $file_name,
+ @current_group);
+ }
+ else {
+ push @current_group, $_;
+ next;
+ }
+ }
+ @current_group = ($full_rev, $_);
+ }
+ if (@current_group) {
+ $current_color = ++$current_color % $num_colors;
+ flush_blame_lines($rev_color[$current_color],
+ $file_name,
+ @current_group);
}
print "</table>\n";
print "</div>";
--
1.4.2.g39ee
^ permalink raw reply related
* [PATCH] gitweb: show rev only on the first line of each group in blame
From: Junio C Hamano @ 2006-08-29 9:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <7vveocpfa3.fsf@assigned-by-dhcp.cox.net>
Thanks to the last round, this is now easy to do.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
gitweb/gitweb.perl | 21 ++++++++++++++++-----
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 28e1cfd..5c82d3f 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2174,8 +2174,11 @@ sub flush_blame_lines {
my ($color, $file_name, @line) = @_;
my $full_rev = shift @line;
my $rev = substr($full_rev, 0, 8);
+ my $cnt = scalar @line;
+ my $this = 0;
for (@line) {
+ $this++;
unless (/^[0-9a-fA-F]{40}.*?(\d+)\)\s(.*)/) {
print "<tr><td>(malformed blame output)</td></tr>";
next;
@@ -2183,11 +2186,19 @@ sub flush_blame_lines {
my $lineno = $1;
my $data = $2;
print "<tr class=\"$color\">\n";
- print "<td class=\"sha1\">" .
- $cgi->a({-href => href(action=>"commit",
- hash=>$full_rev,
- file_name=>$file_name)},
- esc_html($rev)) . "</td>\n";
+
+ if ($this == 1) {
+ if (1 < $cnt) {
+ print "<td class=\"sha1\" rowspan=\"$cnt\">";
+ }
+ else {
+ print "<td class=\"sha1\">";
+ }
+ print $cgi->a({-href => href(action=>"commit",
+ hash=>$full_rev,
+ file_name=>$file_name)},
+ esc_html($rev)) . "</td>\n";
+ }
print +("<td class=\"linenr\">".
"<a id=\"l$lineno\" href=\"#l$lineno\" ".
"class=\"linenr\">" .
--
1.4.2.g39ee
^ permalink raw reply related
* [PATCH] gitweb: show age and author in blame output
From: Junio C Hamano @ 2006-08-29 9:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
The commit object name link on each link uses "title", which
shows the author and age of the particular line when hovered
over.
The background of these links are painted on darker color as
they become older and the links on younger lines are shown on
lighter background.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
gitweb/gitweb.css | 6 ++++++
gitweb/gitweb.perl | 27 +++++++++++++++++++++++----
2 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index eb9fc38..f3211c2 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -215,6 +215,12 @@ td.sha1 {
font-family: monospace;
}
+table.blame td.age-week { color: #0000ff; background-color: #ffffff; }
+table.blame td.age-month { color: #0000ff; background-color: #ddddee; }
+table.blame td.age-season { color: #0000ff; background-color: #bbbbdd; }
+table.blame td.age-year { color: #0000ff; background-color: #9999cc; }
+table.blame td.age-old { color: #0000ff; background-color: #7777bb; }
+
td.error {
color: red;
background-color: yellow;
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 5c82d3f..0265a82 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2171,12 +2171,26 @@ sub git_tag {
}
sub flush_blame_lines {
- my ($color, $file_name, @line) = @_;
+ my ($color, $file_name, $now, @line) = @_;
my $full_rev = shift @line;
+
+ my ($author, $timestamp, $zone) =
+ ($line[0] =~
+ /^[0-9a-f]{40}\s\((.*?)\s+(\d+)\s([-+\d]{5})\s+\d+\)/);
+ my $age = $now - $timestamp;
+ my $ago = age_string($age);
+ my $pop = 'title="' . esc_html("$author, $ago") . '"';
+ my $agegroup =
+ (($age < 60*60*24*7) ? "age-week" :
+ ($age < 60*60*24*30) ? "age-month" :
+ ($age < 60*60*24*120) ? "age-season" :
+ ($age < 60*60*24*360) ? "age-year" : "age-old");
+
my $rev = substr($full_rev, 0, 8);
my $cnt = scalar @line;
my $this = 0;
+
for (@line) {
$this++;
unless (/^[0-9a-fA-F]{40}.*?(\d+)\)\s(.*)/) {
@@ -2188,11 +2202,12 @@ sub flush_blame_lines {
print "<tr class=\"$color\">\n";
if ($this == 1) {
+ my $cls = "class=\"sha1 $agegroup\"";
if (1 < $cnt) {
- print "<td class=\"sha1\" rowspan=\"$cnt\">";
+ print "<td $cls $pop rowspan=\"$cnt\">";
}
else {
- print "<td class=\"sha1\">";
+ print "<td $cls $pop>";
}
print $cgi->a({-href => href(action=>"commit",
hash=>$full_rev,
@@ -2228,7 +2243,8 @@ sub git_blame2 {
if ($ftype !~ "blob") {
die_error("400 Bad Request", "Object is not a blob");
}
- open ($fd, "-|", git_cmd(), "blame", '-l', $file_name, $hash_base)
+ open ($fd, "-|", git_cmd(), "blame", '-l', '-t',
+ $file_name, $hash_base)
or die_error(undef, "Open git-blame failed");
git_header_html();
my $formats_nav =
@@ -2242,6 +2258,7 @@ sub git_blame2 {
git_print_page_path($file_name, $ftype, $hash_base);
my @rev_color = (qw(light2 dark2));
my $num_colors = scalar(@rev_color);
+ my $now = time();
my $current_color = 0;
my @current_group = ();
print <<HTML;
@@ -2260,6 +2277,7 @@ HTML
$current_color = ++$current_color % $num_colors;
flush_blame_lines($rev_color[$current_color],
$file_name,
+ $now,
@current_group);
}
else {
@@ -2273,6 +2291,7 @@ HTML
$current_color = ++$current_color % $num_colors;
flush_blame_lines($rev_color[$current_color],
$file_name,
+ $now,
@current_group);
}
print "</table>\n";
--
1.4.2.g39ee
^ permalink raw reply related
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