* Re: [PATCH] gitweb: Show project README if available
From: Junio C Hamano @ 2006-10-10 3:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061010025627.19317.70511.stgit@rover>
Petr Baudis <pasky@suse.cz> writes:
> If the project includes a README file, show it in the summary page.
> The usual "this should be in the config file" argument does not apply here
> since this can be larger and having such a big string in the config file
> would be impractical.
>
> I don't know if this is suitable upstream, but it's one of the repo.or.cz
> custom modifications that I've thought could be interesting for others
> as well.
I agree something like this would be very useful.
I wonder how this should relate to .git/description file,
though. In other words, it _might_ make sense to change where
we show the contents of description right now to show the first
line and take README from the same location.
Having said that I'd take this as is in "next" and wait for
public to decide having two separate files is Ok (which I
suspect is the case) or we'd be better off in the longer term to
try to minimize random files under $GIT_DIR.
^ permalink raw reply
* [PATCH] gitweb: Show project README if available
From: Petr Baudis @ 2006-10-10 2:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
If the project includes a README file, show it in the summary page.
The usual "this should be in the config file" argument does not apply here
since this can be larger and having such a big string in the config file
would be impractical.
I don't know if this is suitable upstream, but it's one of the repo.or.cz
custom modifications that I've thought could be interesting for others
as well.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 7547c4d..4e56af9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2535,6 +2535,14 @@ sub git_summary {
}
print "</table>\n";
+ if (-s "$projectroot/$project/README") {
+ if (open my $fd, "$projectroot/$project/README") {
+ print "<div class=\"title\">readme</div>\n";
+ print $_ while (<$fd>);
+ close $fd;
+ }
+ }
+
open my $fd, "-|", git_cmd(), "rev-list", "--max-count=17",
git_get_head_hash($project)
or die_error(undef, "Open git-rev-list failed");
^ permalink raw reply related
* Re: [PATCH] add commit count options to git-shortlog
From: Nicolas Pitre @ 2006-10-10 2:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodsotqqd.fsf@assigned-by-dhcp.cox.net>
On Sat, 7 Oct 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > This patch does 3 things:
> >...
> > Signed-off-by: Nicolas Pitre <nico@cam.org>
> >
> > ---
> >
> > I'm far from a Perl expert. I just hope that Perl gurus out there won't
> > throw up too badly.
> >
> > With this it is possible to have nice statistics quickly, and
> > demonstrate that Junio is really our King. ;-)
>
> I only talk passable Perl but I did not find much objectionable
> stuff there. But I am not sure how this is useful aside from
> stroking your own ego.
While stroking your own ego might sometimes be a good thing (hackers
are in it for free because they have some pride back), I think it is
most interesting for the pure statistic values. It is often nice to
know who the main contributors are and by what margin, or to have a look
at the contribution spectrum to have a feel of participation to a given
project.
Linus recently wanted to know the opinion of an arbitrary number of top
developers to the Linux kernel. He used a criteria to determine who
those developers were which was based on amount of sign-off lines, but
the number of pure contribution is otherwise the metric that most
projects are likely to be interested in.
Oh, and BitKeeper had that feature.
> Also I get the following.
>
> $ git log --pretty=short v1.4.2..abd6970 |
> perl ./git-shortlog.perl -n -s >/dev/null
> parse error: input records != output records
Please find new patch below (only one line added) with that issue fixed.
diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt
index 7486ebe..1601d22 100644
--- a/Documentation/git-shortlog.txt
+++ b/Documentation/git-shortlog.txt
@@ -7,16 +7,29 @@ git-shortlog - Summarize 'git log' outpu
SYNOPSIS
--------
-git-log --pretty=short | 'git-shortlog'
+git-log --pretty=short | 'git-shortlog' [-h] [-n] [-s]
DESCRIPTION
-----------
Summarizes 'git log' output in a format suitable for inclusion
-in release announcements. Each commit will be grouped by author
+in release announcements. Each commit will be grouped by author and
the first line of the commit message will be shown.
Additionally, "[PATCH]" will be stripped from the commit description.
+OPTIONS
+-------
+
+-h::
+ Print a short usage message and exit.
+
+-n::
+ Sort output according to the number of commits per author instead
+ of author alphabetic order.
+
+-s:
+ Supress commit description and Provide a commit count summary only.
+
FILES
-----
'.mailmap'::
diff --git a/git-shortlog.perl b/git-shortlog.perl
index 0b14f83..334fec7 100755
--- a/git-shortlog.perl
+++ b/git-shortlog.perl
@@ -1,6 +1,18 @@
#!/usr/bin/perl -w
use strict;
+use Getopt::Std;
+use File::Basename qw(basename dirname);
+
+our ($opt_h, $opt_n, $opt_s);
+getopts('hns');
+
+$opt_h && usage();
+
+sub usage {
+ print STDERR "Usage: ${\basename $0} [-h] [-n] [-s] < <log_data>\n";
+ exit(1);
+}
my (%mailmap);
my (%email);
@@ -38,16 +50,38 @@ sub by_name($$) {
uc($a) cmp uc($b);
}
+sub by_nbentries($$) {
+ my ($a, $b) = @_;
+ my $a_entries = $map{$a};
+ my $b_entries = $map{$b};
+
+ @$b_entries - @$a_entries || by_name $a, $b;
+}
+
+my $sort_method = $opt_n ? \&by_nbentries : \&by_name;
+
+sub summary_output {
+ my ($obj, $num, $key);
+
+ foreach $key (sort $sort_method keys %map) {
+ $obj = $map{$key};
+ $num = @$obj;
+ printf "%s: %u\n", $key, $num;
+ $n_output += $num;
+ }
+}
sub shortlog_output {
- my ($obj, $key, $desc);
+ my ($obj, $num, $key, $desc);
+
+ foreach $key (sort $sort_method keys %map) {
+ $obj = $map{$key};
+ $num = @$obj;
- foreach $key (sort by_name keys %map) {
# output author
- printf "%s:\n", $key;
+ printf "%s (%u):\n", $key, $num;
# output author's 1-line summaries
- $obj = $map{$key};
foreach $desc (reverse @$obj) {
print " $desc\n";
$n_output++;
@@ -152,7 +186,7 @@ sub finalize {
&setup_mailmap;
&changelog_input;
-&shortlog_output;
+$opt_s ? &summary_output : &shortlog_output;
&finalize;
exit(0);
^ permalink raw reply related
* Re: Why gitweb commitdiff NO diff output ?
From: Junio C Hamano @ 2006-10-10 2:28 UTC (permalink / raw)
To: Dongsheng Song; +Cc: git
In-Reply-To: <7v1wpgapew.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> "Dongsheng Song" <dongsheng.song@gmail.com> writes:
>
>> NO.
>>
>> When I change the repository's owner to gitweb process, no diff output yet.
>>
>> $ chown -R www-data:www-data cauchy/ gcc/ mph/
>>
>> 2006/10/10, Junio C Hamano <junkio@cox.net>:
>>> The site does not return any of these four blobs that are part
>>> of the commitdiff when a=blob is requested on them.
>>>
>>> file:a34d77e47bf1561db1ade4f6b247598b880f80d5 ->
>>> file:7625c494df01d4745e67bd4423e2fdbe9fc43799
>>>
>>> file:b207fe30a5430f97d27d398d89c974b068694c7a ->
>>> file:57b07ace4bb6352416bbf9436b9f2642b3273257
>>>
>>> I would first suspect if the repository actually have them _and_
>>> with an appropriate mode protection to be readable by your
>>> gitweb process.
>
> And does the repository have these four blob objects?
Sorry, the follow-up question was not very helpful to guide
another person over e-mail. Let's try again with more specific
questions.
What do these say in that repository when run as the webserver
user?
$ for blob in \
a34d77e47bf1561db1ade4f6b247598b880f80d5 \
7625c494df01d4745e67bd4423e2fdbe9fc43799 \
b207fe30a5430f97d27d398d89c974b068694c7a \
57b07ace4bb6352416bbf9436b9f2642b3273257
do
git cat-file -t $blob || echo $blob does not exist
done
$ git cat-file commit c977ee1b2e54d67bb379ce476f784431c32136d7 |
grep 'parent '
$ git diff-tree -p c977ee1b2e54d67bb379ce476f784431c32136d7 | wc
The first one tries to make sure you have those four blob
objects in the repository, the second tries to make sure the
commit is a single parent commit as your gitweb output suggests,
and the last one is to obtain the diff text.
Also do you have the same problem with other commits, or is this
the only commit your gitweb is having trouble with showing
commitdiff?
^ permalink raw reply
* Re: git-revert in branch next
From: Junio C Hamano @ 2006-10-10 2:21 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20061010011134.58584.qmail@web31809.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> --- Luben Tuikov <ltuikov@yahoo.com> wrote:
>> Has anyone successfully used "git-revert" from branch next, lately?
Yes, and it is actually in "master". Thanks for noticing before
I declared -rc2.
-- >8 --
Fix git-revert
Defaulting to $replay for the sake of fixing cherry-pick was not
done conditionally, which broke git-revert.
Noticed by Luben.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-revert.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/git-revert.sh b/git-revert.sh
index 0784f74..4fd81b6 100755
--- a/git-revert.sh
+++ b/git-revert.sh
@@ -7,9 +7,11 @@ #
case "$0" in
*-revert* )
test -t 0 && edit=-e
+ replay=
me=revert
USAGE='[--edit | --no-edit] [-n] <commit-ish>' ;;
*-cherry-pick* )
+ replay=t
edit=
me=cherry-pick
USAGE='[--edit] [-n] [-r] [-x] <commit-ish>' ;;
@@ -18,7 +20,7 @@ case "$0" in
esac
. git-sh-setup
-no_commit= replay=t
+no_commit=
while case "$#" in 0) break ;; esac
do
case "$1" in
--
1.4.2.3.g2c59
^ permalink raw reply related
* Re: Why gitweb commitdiff NO diff output ?
From: Junio C Hamano @ 2006-10-10 2:13 UTC (permalink / raw)
To: Dongsheng Song; +Cc: git
In-Reply-To: <4b3406f0610091851i593f3e53v5d5fef891edb6d48@mail.gmail.com>
"Dongsheng Song" <dongsheng.song@gmail.com> writes:
> NO.
>
> When I change the repository's owner to gitweb process, no diff output yet.
>
> $ chown -R www-data:www-data cauchy/ gcc/ mph/
>
> 2006/10/10, Junio C Hamano <junkio@cox.net>:
>> The site does not return any of these four blobs that are part
>> of the commitdiff when a=blob is requested on them.
>>
>> file:a34d77e47bf1561db1ade4f6b247598b880f80d5 ->
>> file:7625c494df01d4745e67bd4423e2fdbe9fc43799
>>
>> file:b207fe30a5430f97d27d398d89c974b068694c7a ->
>> file:57b07ace4bb6352416bbf9436b9f2642b3273257
>>
>> I would first suspect if the repository actually have them _and_
>> with an appropriate mode protection to be readable by your
>> gitweb process.
And does the repository have these four blob objects?
^ permalink raw reply
* Re: git-svn fetch fails when a file is renamed changing only case
From: Pazu @ 2006-10-10 2:11 UTC (permalink / raw)
To: git
In-Reply-To: <m2psd1rwb0.fsf@ziti.local>
Seth Falcon wrote:
> IOW, are you sure this is an issue in git-svn and not an issue in
> filesystem + svn? For example, I think you will also have problems
> with a repository that contains in the same dir TESTFILE and TestFile
> :-\
If I try something like:
mini:~$ svn mv TESTFILE TestFile
It will fail with a message saying that TestFile already exists, since
HFS+ is case insensitive by default:
svn: File 'TestFile' already exists
But keep in mind this is a shared repository, and people working on
case-sensitive file systems may rename the file. I can do it too, if I
use full URL's (all examples here use the same test repository provided
in my first message):
mini:~$ svn mv file:///tmp/git-svn-rename-test/TESTFILE
file:///tmp/git-svn-rename-test/TestFile
Commited revision 5.
Anyway, when I'm updating a working copy, svn will do the right thing:
mini:~$ svn co -r1 file:///tmp/git-svn-rename-test
D git-svn-rename-test/TESTFILE
A git-svn-rename-test/TestFile
Checked out revision 1.
mini:~$ cd git-svn-rename-test
mini:git-svn-rename-test$ svn up -r3
D TestFile
A TESTFILE
Updated to revision 3.
A rename for svn is just a copy followed by delete, so when updating,
TestFile is removed and then recreated as TESTFILE, correctly.
So, to finally answer your question, no, unfortunately I don't think
this is purely an svn problem. Yes, I would have problems with two files
named TestFile and TESTFILE in the same dir, but that's not what happens
in this test case.
Well, I'll keep browsing the git-svn source code, and try to make some
sense out of it...
-- Marcus
^ permalink raw reply
* Re: Why gitweb commitdiff NO diff output ?
From: Dongsheng Song @ 2006-10-10 1:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64et9fjq.fsf@assigned-by-dhcp.cox.net>
NO.
When I change the repository's owner to gitweb process, no diff output yet.
$ chown -R www-data:www-data cauchy/ gcc/ mph/
2006/10/10, Junio C Hamano <junkio@cox.net>:
> The site does not return any of these four blobs that are part
> of the commitdiff when a=blob is requested on them.
>
> file:a34d77e47bf1561db1ade4f6b247598b880f80d5 ->
> file:7625c494df01d4745e67bd4423e2fdbe9fc43799
>
> file:b207fe30a5430f97d27d398d89c974b068694c7a ->
> file:57b07ace4bb6352416bbf9436b9f2642b3273257
>
> I would first suspect if the repository actually have them _and_
> with an appropriate mode protection to be readable by your
> gitweb process.
>
>
>
>
^ permalink raw reply
* Re: git-revert in branch next
From: Luben Tuikov @ 2006-10-10 1:11 UTC (permalink / raw)
To: git
--- Luben Tuikov <ltuikov@yahoo.com> wrote:
> Has anyone successfully used "git-revert" from branch next, lately?
> It seems to print USAGE no matter what arguments are given to it.
Line 50:
test "$me,$replay" = "revert,t" && usage
is suspicious after commit abd6970a.
Luben
^ permalink raw reply
* git-revert in branch next
From: Luben Tuikov @ 2006-10-10 1:05 UTC (permalink / raw)
To: git
Has anyone successfully used "git-revert" from branch next, lately?
It seems to print USAGE no matter what arguments are given to it.
Luben
^ permalink raw reply
* Re: [RFC/PATCH] merge: loosen overcautious "working file will be lost" check.
From: Luben Tuikov @ 2006-10-10 0:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5919g55.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Ah, I misunderstood. But then I do not understand why you see
> all 0 anywhere. Merge base has the path, branch B has it, and
> trunk has it too; wouldn't it result in regular 3-way merge?
>
> I understand you do _not_ even want a regular 3-way merge in
> this case, but that is a separate issue. You could write a new
> merge strategy to traverse ancestry chain between the merge base
> and each heads you are merging and notice disappearance and
> reappearance of the path, but that would slow things down
> tremendously for normal case and I do not think it is worth it.
>
> You would also have exactly the same issue if you do not remove
> and then add the file, but if your work on the branch involves a
> significant rewrite. Depending on how good the rewrite is,
> bugfixes that happened on the trunk based on an ancient code may
> not even be needed (in other words, it would not apply cleanly
> anyway, but it does not matter -- the branch work is much better
> or has different set of problems that the trunk fix is
> irrelevant).
>
> At that point, M1 would involve significant merge conflicts (and
> not all-0 which I am still puzzled about), but I suspect that
> the situation is obvious enough to the human (inspect git log
> branch...trunk output and the log somewhere had better indicate
> that the are unrelated), and the solution very much is different
> case-by-case (most likely the person who pulls branch into trunk
> would say "keep ours" for the path which would mean running "git
> cat-file :2:$path >$path", or say "we are not really ready to merge
> yet" and abort the entire merge; somebody on the trunk pulling
> from that branch might say "I want other smaller fixes but this
> total rewrite is not ready yet -- keep ours", or "now we know
> this is total rewrite and the small updates on the trunk does
> not matter -- take theirs and from now on we will improve on the
> work done on the branch").
>
> So in short, I do not think there is a clear-cut improvement we
> can do to the tools to solve this.
Yes, I agree.
Luben
^ permalink raw reply
* Re: Why gitweb commitdiff NO diff output ?
From: Junio C Hamano @ 2006-10-10 0:32 UTC (permalink / raw)
To: Dongsheng Song; +Cc: git, Jakub Narebski
In-Reply-To: <4b3406f0610080122r17a10ea4h2c71a399fb8398a@mail.gmail.com>
The site does not return any of these four blobs that are part
of the commitdiff when a=blob is requested on them.
file:a34d77e47bf1561db1ade4f6b247598b880f80d5 ->
file:7625c494df01d4745e67bd4423e2fdbe9fc43799
file:b207fe30a5430f97d27d398d89c974b068694c7a ->
file:57b07ace4bb6352416bbf9436b9f2642b3273257
I would first suspect if the repository actually have them _and_
with an appropriate mode protection to be readable by your
gitweb process.
^ permalink raw reply
* Re: [RFC/PATCH] merge: loosen overcautious "working file will be lost" check.
From: Junio C Hamano @ 2006-10-10 0:19 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20061010000127.76332.qmail@web31801.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> --- Junio C Hamano <junkio@cox.net> wrote:
>> Luben Tuikov <ltuikov@yahoo.com> writes:
>>
>> > I think this is a good thing.
>> >
>> > How about this case I've noticed in my trees:
>> >
>> > After branching out, a file is deleted, only to add
>> > a different file with the same file name.
>> >
>> > Then any time I pull in from the trunk to merge,
>> > merge fails with git-diff-files showing all 0's and the
>> > file name in question. Picture:
>> >
>> > Branch B +-----------------M1---->
>> > / /
>> > C2 <-- git-add A /
>> > / /
>> > C1 <-- git-rm A /
>> > / /
>> > Trunk -----+-----------------+---->
>>
>> Sorry I do not understand the picture; where is the common
>> ancestor? If it is the left plus sign on the Trunk line, and
>
> Yes, the left plus sign is the common ancestor.
>
>> you are talking about what happens when making the merge M1,
>> then before C1 A did not exist (so Trunk tip which is the right
>
> File A exists before C1, it does not exist after C1. C1 removes
> it.
Ah, I misunderstood. But then I do not understand why you see
all 0 anywhere. Merge base has the path, branch B has it, and
trunk has it too; wouldn't it result in regular 3-way merge?
I understand you do _not_ even want a regular 3-way merge in
this case, but that is a separate issue. You could write a new
merge strategy to traverse ancestry chain between the merge base
and each heads you are merging and notice disappearance and
reappearance of the path, but that would slow things down
tremendously for normal case and I do not think it is worth it.
You would also have exactly the same issue if you do not remove
and then add the file, but if your work on the branch involves a
significant rewrite. Depending on how good the rewrite is,
bugfixes that happened on the trunk based on an ancient code may
not even be needed (in other words, it would not apply cleanly
anyway, but it does not matter -- the branch work is much better
or has different set of problems that the trunk fix is
irrelevant).
At that point, M1 would involve significant merge conflicts (and
not all-0 which I am still puzzled about), but I suspect that
the situation is obvious enough to the human (inspect git log
branch...trunk output and the log somewhere had better indicate
that the are unrelated), and the solution very much is different
case-by-case (most likely the person who pulls branch into trunk
would say "keep ours" for the path which would mean running "git
cat-file :2:$path >$path", or say "we are not really ready to merge
yet" and abort the entire merge; somebody on the trunk pulling
from that branch might say "I want other smaller fixes but this
total rewrite is not ready yet -- keep ours", or "now we know
this is total rewrite and the small updates on the trunk does
not matter -- take theirs and from now on we will improve on the
work done on the branch").
So in short, I do not think there is a clear-cut improvement we
can do to the tools to solve this.
^ permalink raw reply
* Re: [RFC/PATCH] merge: loosen overcautious "working file will be lost" check.
From: Luben Tuikov @ 2006-10-10 0:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7rp9kdz.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > I think this is a good thing.
> >
> > How about this case I've noticed in my trees:
> >
> > After branching out, a file is deleted, only to add
> > a different file with the same file name.
> >
> > Then any time I pull in from the trunk to merge,
> > merge fails with git-diff-files showing all 0's and the
> > file name in question. Picture:
> >
> > Branch B +-----------------M1---->
> > / /
> > C2 <-- git-add A /
> > / /
> > C1 <-- git-rm A /
> > / /
> > Trunk -----+-----------------+---->
>
> Sorry I do not understand the picture; where is the common
> ancestor? If it is the left plus sign on the Trunk line, and
Yes, the left plus sign is the common ancestor.
> you are talking about what happens when making the merge M1,
> then before C1 A did not exist (so Trunk tip which is the right
File A exists before C1, it does not exist after C1. C1 removes
it.
> plus sign on the Trunk line would not either), and the other
> head (tip of branch B you are pulling the trunk into) would have
> one already (from C2), so I would imagine it would be "one side
> adds while the other did not touch" (net effect since branch B
The trunk is free to change/update file A. In fact this is what
most likely happens.
> forked from trunk is an addition of A, while Trunk did not do
> anything with respect to path A), so I do not see where any
> conflict can come from. Puzzled.
>From branch B's point of view, we are not interested in
any updates/changes/etc of file A coming from the trunk.
Since we've deleted that file and added our own, albeit
with the same name.
Luben
P.S. I'm not sure if this is tenable, since it is hard
for GIT to know... or is it?
^ permalink raw reply
* Re: Does GIT has vc keywords like CVS/Subversion?
From: Martin Langhoff @ 2006-10-09 22:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Liu Yubao, Dongsheng Song, git
In-Reply-To: <Pine.LNX.4.63.0610100045430.14200@wbgn013.biozentrum.uni-wuerzburg.de>
On 10/10/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> If you have the path, you can reuse the whole algorithm for finding
> the best delta base.
Can I do that from Perl/bash? (how?)
> However, if you do not have the path, you might as well just give up (if
> there is no perfect match for the SHA1), since the SHA1 is _not_ similar
> for similar contents. IOW, you'd literally have to search _all_ objects in
> the repository, which usually takes a long, long time.
So the delta base algorithm doesn't work without a path. I thought we
had a quick way to find blobs of similar size. If the user can't even
give us a filename (that we can use to try and build a likely path)
then they have bigger problems than the delta ;-) -- at some point we
have to provide git-paddedcell for the remaining <ahem> users.
cheers,
maritn
^ permalink raw reply
* Re: Does GIT has vc keywords like CVS/Subversion?
From: Junio C Hamano @ 2006-10-09 22:55 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90610091408y29f60a12gea7040b5412331c6@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> is there a way to scan the object store for blobs of around a given
> size (as the packing code does) from Perl?
For objects in packs, verify-pack -v comes to mind (show-index
might show the same information). Loose objects needs help from
git-cat-file -s or git-cat-file -t or both.
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Junio C Hamano @ 2006-10-09 22:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061009205551.GO20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> This is the count of actions invoked from the tree, commit and
> commitdiff view (using the referer information):
>
> blame blob total requests containing 'a='
> #2 1 18 264
> #1 31 23 399
> #0 4 6 50
>
> The disparation between #2 and #1,#0 is quite apparent. If we want more
> exact results, I will let #0 accumulate data for a week and then revert
> the removal of the links and start another sample.
I am not sure -- you are certainly counting me looking at your
blame output while working on the slimmed down blame output (you
may remember that I noted that while your output gives names and
dates for each line which is busier I kind of liked it in one of
my previous messages), and we talked about gitweb blame lot
recently on the list so that might have spurred people's
curiosity.
^ permalink raw reply
* Re: Does GIT has vc keywords like CVS/Subversion?
From: Johannes Schindelin @ 2006-10-09 22:48 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Linus Torvalds, Liu Yubao, Dongsheng Song, git
In-Reply-To: <46a038f90610091408y29f60a12gea7040b5412331c6@mail.gmail.com>
Hi,
On Tue, 10 Oct 2006, Martin Langhoff wrote:
> On 10/10/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
> > - outside of the SCM, keyword substitution can make sense, but doing it
> > should be in helper scripts or something that can easily tailor it for
> > the actual need of that particular project.
... like a pre-commit hook.
> If we have a tool that I can pass a file or a directory tree and will
> find the (perfectly|closely) matching trees and related commits.
>
> For the single file case, searching for an exact SHA1 match is easy,
> as is by path.
If you have the path, you can reuse the whole algorithm for finding the
best delta base.
However, if you do not have the path, you might as well just give up (if
there is no perfect match for the SHA1), since the SHA1 is _not_ similar
for similar contents. IOW, you'd literally have to search _all_ objects in
the repository, which usually takes a long, long time.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH] merge: loosen overcautious "working file will be lost" check.
From: Junio C Hamano @ 2006-10-09 22:47 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20061009172053.48882.qmail@web31804.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> I think this is a good thing.
>
> How about this case I've noticed in my trees:
>
> After branching out, a file is deleted, only to add
> a different file with the same file name.
>
> Then any time I pull in from the trunk to merge,
> merge fails with git-diff-files showing all 0's and the
> file name in question. Picture:
>
> Branch B +-----------------M1---->
> / /
> C2 <-- git-add A /
> / /
> C1 <-- git-rm A /
> / /
> Trunk -----+-----------------+---->
Sorry I do not understand the picture; where is the common
ancestor? If it is the left plus sign on the Trunk line, and
you are talking about what happens when making the merge M1,
then before C1 A did not exist (so Trunk tip which is the right
plus sign on the Trunk line would not either), and the other
head (tip of branch B you are pulling the trunk into) would have
one already (from C2), so I would imagine it would be "one side
adds while the other did not touch" (net effect since branch B
forked from trunk is an addition of A, while Trunk did not do
anything with respect to path A), so I do not see where any
conflict can come from. Puzzled.
^ permalink raw reply
* Obituary for git-annotate
From: Junio C Hamano @ 2006-10-09 22:33 UTC (permalink / raw)
To: git; +Cc: Ryan Anderson, Fredrik Kuivinen
In-Reply-To: <20061009103710.GX1558@h4x0r5.com>
Ryan Anderson <ryan@michonline.com> writes:
> On Thu, Oct 05, 2006 at 01:13:15AM -0700, Junio C Hamano wrote:
>> It's been a while since we lost git_blame from %actions list. I
>> am wondering maybe it's time to remove it, after 1.4.3 happens.
>
> I certainly have no objection. In fact, I sent a patch a moment ago.
> (I didn't keep the cc: on it, I figured there was too high a chance of
> mishap when pasting the cc: list.)
So it's finally settled between annotate and blame. It is kind
of sad to see one of them had to go while these stem from
slightly different algorithm sketches [*1*]. But for 8 months
of its existence, it served us well as the git-cvsserver
backend. May it rest in peace.
Having said that, there are a few things in git-blame that
interested people may want to further look into.
Annotation by git-blame is done by "passing the blame to
parents" principle. You start from the final form of the blob,
and compare it with its counterpart in the parent version
(rename detection is used to pick which file in the parent
version to compare against). The lines the commit inherited
from its parent are not responsibility of the child so the
algorithm passes blame on them to the parent. The lines the
commit changed from the parent are blamed on the child.
When this is done, the parent "temporarily" takes responsibility
for those lines that child did not change -- it just becomes
"suspect" for those lines when we compare parent and child. And
then the algorithm goes further down the ancestry to give the
parent the chance to exonerate itself by passing blames for the
lines it is suspect for, by passing the blame to its parent.
When sifting the lines into "inherited" and "our
responsibility", internally git-blame runs "diff", which
expresses the changes as "these lines are deleted and these are
inserted by the child". Lines outside are clearly inherited
from the parent.
This has an interesting effect on blame output.
Suppose the original file had two groups of lines; group A
followed by group B. A commit changes the file so that it has
group B followed by group A. What git-blame sees as diff
between the two is either:
-A
B
+A
or
+B
A
-B
In either case, it would end up giving blame to the child for
one group (the first diff blames the child for A lines) and pass
the blame for the other one to the parent.
If we used something other than "diff" (Delete Insert File vs
File ;-)), that expresses changes as "these are moved from
there, these are inserted anew" (call that "miff"), then we
should be able to assign blame more accurately. The above
example case would be expressed as "group A came from the top
part of the parent, group B came from the bottom part of the
parent". Passing of the blame based on that expression would
blame the child for neither group of lines.
Further, if we use "ciff" that expresses changes as "these are
copied from there, these are inserted anew", we can do a lot
more interesting thing. We can track code movement across
files, and that is not limited to renames.
For example, suppose that the parent had files F1 and F2 and the
child moved a function and copy-and-pasted a comment block from
F1 to F2, and we are annotating lines in F2.
The current git-blame sees that the function and comment block
appeared from nowhere into F2 and blames the child for them.
However, when annotating F2, we could:
- use concatenation of all files in the parent that was
modified between parent and child (or just "all files in the
parent" -- the difference is exactly like plain -C vs -C
--find-copies-harder) as the source image;
- use lines of F2 in the child as the destination image;
- run "ciff" algorithm to see where each line of F2 in the
child came from (either copied from existing file somewhere
in the parent, or inserted anew by the child).
This would find that the function and the comment block were
copied from F1 in the parent.
An interesting property of this is that when the parent passes
down the blame for the function the child moved in the above
example further to its parent, we do not necessarily have to run
"ciff" algorithm on file F1 as the whole. We only need to give
the function (i.e. the lines the parent is still suspect for)
[*2*]. So this makes destination image fed to "ciff" smaller as
more lines are blamed on children while digging deeper, which
may compensate for the need to feed not just that file but other
files for copy detection on the source image side.
[*1*]
I think annotate follows this sketch
http://thread.gmane.org/gmane.comp.version-control.git/14819/focus=14867
while blame follows this sketch
http://thread.gmane.org/gmane.comp.version-control.git/5453/focus=5483
[*2*]
we may need to use a handful surrounding context lines for
better identification of copy source by the "ciff" algorithm but
that is a minor implementation detail.
^ permalink raw reply
* Re: git-svn fetch fails when a file is renamed changing only case
From: Seth Falcon @ 2006-10-09 21:52 UTC (permalink / raw)
To: git
In-Reply-To: <ege016$vrb$1@sea.gmane.org>
Pazu <pazu@pazu.com.br> writes:
> For example, if you had a file named TestFile and it's renamed to
> TESTFILE, git-svn fails to fetch revisions after the rename.
Does this work for you via svn?
On OS X, the default is a non case-sensitive filesystem. I use OS X
and have encountered issues with case-change-only commits in svn.
IOW, are you sure this is an issue in git-svn and not an issue in
filesystem + svn? For example, I think you will also have problems
with a repository that contains in the same dir TESTFILE and TestFile
:-\
+ seth
^ permalink raw reply
* Re: Does GIT has vc keywords like CVS/Subversion?
From: Martin Langhoff @ 2006-10-09 21:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Liu Yubao, Dongsheng Song, git
In-Reply-To: <Pine.LNX.4.64.0610090904360.3952@g5.osdl.org>
On 10/10/06, Linus Torvalds <torvalds@osdl.org> wrote:
> So:
> - inside of the SCM, keyword substitution is pointless, since you have
> much better tools available (like "git log filename")
> - outside of the SCM, keyword substitution can make sense, but doing it
> should be in helper scripts or something that can easily tailor it for
> the actual need of that particular project.
For the outside of the SCM case, keyword subst is useful indeed if
someone has a $version_unknown tarball, unpacks it and hacks away. It
is a pretty broken scenario, and less likely to happen nowadays with
easy access to SCM tools.
However, I don't think that scenario is hard to support and Git can
have a much better story to tell than keyword substituting SCMs.
If we have a tool that I can pass a file or a directory tree and will
find the (perfectly|closely) matching trees and related commits.
For the single file case, searching for an exact SHA1 match is easy,
as is by path. If we get a file without a path it gets a bit harder --
is there a way to scan the object store for blobs of around a given
size (as the packing code does) from Perl? Actually, if we find a
relatively close match, it'd be useful to ask git if it's deltified
and ask for other members of the delta chain.
For the directory tree case, the ideal thing would be to build a
temporary index without getting the blobs in the object store, and
then do a first pass trying to match tree SHA1s. If the user has
modified a few files in a large project, it'll be trivial to find a
good candidate commit for delta. OTOH, if the user has indulged in
wide ranging search and replace... it will be well deserved pain ;-)
cheers,
martin
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Petr Baudis @ 2006-10-09 20:55 UTC (permalink / raw)
To: Luben Tuikov, Jakub Narebski; +Cc: git
In-Reply-To: <20061007191246.GF20017@pasky.or.cz>
> Dear diary, on Sat, Oct 07, 2006 at 09:06:25PM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
> > By the way, I miss somewhat the "redundant" tree/blob links in tree
> > view...
>
> I didn't want to post about it but I share the feeling - I have to keep
> thinking consciously about clicking on the file name instead of on the
> view name - and the situation is worse for regular files, since it is
> not really apparent that the filenames are clickablea. My mind knows
> that I'm supposed to click on them (not users' mind!), but the eyes and
> hands are still clueless.
I was looking into accesslogs of repo.or.cz for something and noticed
that I see unusually large number of blame requests. That of course
attracted my curiosity and I came to conclusion that what I'm seeing is
not just my personal whim but we have serious usability problem here.
I'm unfortunately not sure when the update of repo.or.cz gitweb which
dropped the blob/tree links happenned, so the following _is_ somewhat
dubious, but I think it's quite telling anyway.
I have three samples (logfiles) available: #2 almost certainly when the
blob link was still there, #1 covering the switch and some time before
and after, and #0 certainly when the blob link was not there anymore,
but unfortunately spanning only one or two days.
This is the count of actions invoked from the tree, commit and
commitdiff view (using the referer information):
blame blob total requests containing 'a='
#2 1 18 264
#1 31 23 399
#0 4 6 50
The disparation between #2 and #1,#0 is quite apparent. If we want more
exact results, I will let #0 accumulate data for a week and then revert
the removal of the links and start another sample.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] gitweb: Cleanup Git logo and Git logo target generation
From: Petr Baudis @ 2006-10-09 20:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vvemtdfst.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Oct 09, 2006 at 11:00:50AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Partial improvement is better than no improvement.
>
> Not necessarily. As the maintainer, I found that when we say
> "we will fix it later", later tend to never come, and one
> effective way to fight that tendency is to prod the contributors
> a bit harder, which worked reasonably well so far.
If later tends to never come, it means apparently noone really needs it.
:-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* git-svn fetch fails when a file is renamed changing only case
From: Pazu @ 2006-10-09 17:13 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]
For example, if you had a file named TestFile and it's renamed to
TESTFILE, git-svn fails to fetch revisions after the rename.
My perl skills are close to non-existant, so I'm afraid I don't know how
to fix this. Attached to this message, however, is a sample svn
repository that can reproduce this bug. Just unpack it somewhere (let's
say, in /tmp) and try the following:
tar -C /tmp -xzf git-svn-rename-test.tar.gz
mkdir test-wc
cd test-wc
git-svn init file:///tmp/git-svn-rename-test
git-svn fetch
The last command will fail after fetching revision #3, where a file
named TestFile was renamed to TESTFILE. Here's the stack trace:
svn: 'TestFile' is not under version control
256 at /Users/pazu/bin/git-svn line 2015
main::safe_qx('svn', 'propget', 'svn:keywords',
'TestFile@BASE') called at /Users/pazu/bin/git-svn line 2154
main::svn_propget_base('svn:keywords', 'TestFile') called at
/Users/pazu/bin/git-svn line 1773
main::do_update_index('ARRAY(0x180bd68)', 'remove', 'undef')
called at /Users/pazu/bin/git-svn line 1805
main::index_changes() called at /Users/pazu/bin/git-svn line 1875
main::git_commit('HASH(0x180bd98)',
'c77db38dc752305ba19ebe19b22306551d0f8d52') called at
/Users/pazu/bin/git-svn line 346
main::fetch_cmd() called at /Users/pazu/bin/git-svn line 290
main::fetch() called at /Users/pazu/bin/git-svn line 149
I'm on Mac OS X (Intel) 10.4.8
mini:~ pazu$ uname -a
Darwin mini.intranet.ecore.com.br 8.8.1 Darwin Kernel Version 8.8.1: Mon
Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386
Git was compiled from the released 1.4.2.3 sources, without any
modifications:
mini:~ pazu$ git-svn --version
git-svn version 1.4.2.3
If you need more information, you can contact me directly, or just use
the list -- I'll be here listening :)
-- Marcus Brito
[-- Attachment #2: git-svn-rename-test.tar.gz --]
[-- Type: application/x-gzip, Size: 6686 bytes --]
^ 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