* Re: git doesn't like big files when pushing
From: Junio C Hamano @ 2006-03-01 23:03 UTC (permalink / raw)
To: Greg KH; +Cc: git, Nicolas Pitre
In-Reply-To: <20060301220840.GB18250@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Wed, Mar 01, 2006 at 02:08:02PM -0800, Greg KH wrote:
>> I have a mail archive stored with git, in mbox form, and I made some
>> changes to a few of the files and checked them back in.
>...
Ouch. Running out of memory while deltifying sounds really bad.
> Oh, and I'm using:
> $ git --version
> git version 1.2.3.g8c2f
>
> if that helps or not.
It doen't, since I do not have 8c2fXXXX commit ;-).
I suspect "git push --thin origin" might help, if you are on my
"master" branch:
diff-tree a79a276... (from 2245be3...)
Author: Junio C Hamano <junkio@cox.net>
Date: Mon Feb 20 00:09:41 2006 -0800
Add git-push --thin.
Maybe we would want to make this default before it graduates to
the master branch, but in the meantime to help testing things,
this allows you to say "git push --thin destination".
Signed-off-by: Junio C Hamano <junkio@cox.net>
:100755 100755 706db99... 73dcf06... M git-push.sh
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Carl Worth @ 2006-03-01 23:23 UTC (permalink / raw)
To: Martin Langhoff
Cc: Junio C Hamano, Linus Torvalds, Andreas Ericsson, Eric Wong, git
In-Reply-To: <46a038f90603011340k23327f11s6e3d9d69585a5188@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]
On Thu, 2 Mar 2006 10:40:41 +1300, "Martin Langhoff" wrote:
>
> Aren't we doing a lot of work (changes in core git, and corresponding
> changes in the porcelain) when simple changes in porcelain would
> suffice? Let's imagine that
There might be a simpler change to solve the git-svn-HEAD issue. But I
was about to independently bring up the issue that I wanted to hide
away the "remote-tracking" branches.
I currently get a lot of noise in "git branch" output that are
remote-tracking branches that I will never commit to. (I use a -origin
suffix to help me filter them out, but I'd prefer not to see them at
all here.)
Meanwhile, as I've been teaching new git users, I've had to carefully
teach:
1) Never commit to a branch name that appears on the right side of ':'
in a Pull: refspec.
2) BTW, that ':' might be only implicit. A refspec of "branch" is
equivalent to "branch:branch" so don't commit to those either.
That's pretty painful, so I really think these remote-tracking refs
belong outside of refs/heads.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git doesn't like big files when pushing
From: Greg KH @ 2006-03-01 23:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Pitre
In-Reply-To: <7v8xrtepje.fsf@assigned-by-dhcp.cox.net>
On Wed, Mar 01, 2006 at 03:03:17PM -0800, Junio C Hamano wrote:
> Greg KH <greg@kroah.com> writes:
>
> > On Wed, Mar 01, 2006 at 02:08:02PM -0800, Greg KH wrote:
> >> I have a mail archive stored with git, in mbox form, and I made some
> >> changes to a few of the files and checked them back in.
> >...
>
> Ouch. Running out of memory while deltifying sounds really bad.
>
> > Oh, and I'm using:
> > $ git --version
> > git version 1.2.3.g8c2f
> >
> > if that helps or not.
>
> It doen't, since I do not have 8c2fXXXX commit ;-).
Heh, that's a merge on my tree, sorry. My tree only has one change to
the git-format-patch.sh script.
858cbfbabe4ede5f5eba32041eb7448319e53e2a is the most recent commit from
your tree.
> I suspect "git push --thin origin" might help, if you are on my
> "master" branch:
>
> diff-tree a79a276... (from 2245be3...)
> Author: Junio C Hamano <junkio@cox.net>
> Date: Mon Feb 20 00:09:41 2006 -0800
>
> Add git-push --thin.
>
> Maybe we would want to make this default before it graduates to
> the master branch, but in the meantime to help testing things,
> this allows you to say "git push --thin destination".
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
Will try that. I eventually gave up on the last push when it ran for 45
minutes at full cpu usage, and X got killed by the OOM killer in the
kernel for some reason...
thanks,
greg k-h
^ permalink raw reply
* Re: git doesn't like big files when pushing
From: Greg KH @ 2006-03-01 23:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Pitre
In-Reply-To: <20060301232719.GA22068@kroah.com>
On Wed, Mar 01, 2006 at 03:27:19PM -0800, Greg KH wrote:
> On Wed, Mar 01, 2006 at 03:03:17PM -0800, Junio C Hamano wrote:
> > I suspect "git push --thin origin" might help, if you are on my
> > "master" branch:
> >
> > diff-tree a79a276... (from 2245be3...)
> > Author: Junio C Hamano <junkio@cox.net>
> > Date: Mon Feb 20 00:09:41 2006 -0800
> >
> > Add git-push --thin.
> >
> > Maybe we would want to make this default before it graduates to
> > the master branch, but in the meantime to help testing things,
> > this allows you to say "git push --thin destination".
> >
> > Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> Will try that. I eventually gave up on the last push when it ran for 45
> minutes at full cpu usage, and X got killed by the OOM killer in the
> kernel for some reason...
Nice, this worked!
Now what's the odds that when I pull from the server to another box
these same objects, the server will have the same problem as git-push
did?
will go try that now...
thanks,
greg k-h
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Linus Torvalds @ 2006-03-01 23:43 UTC (permalink / raw)
To: Carl Worth
Cc: Martin Langhoff, Junio C Hamano, Andreas Ericsson, Eric Wong, git
In-Reply-To: <87zmk9zr42.wl%cworth@cworth.org>
On Wed, 1 Mar 2006, Carl Worth wrote:
> Meanwhile, as I've been teaching new git users, I've had to carefully
> teach:
>
> 1) Never commit to a branch name that appears on the right side of ':'
> in a Pull: refspec.
>
> 2) BTW, that ':' might be only implicit. A refspec of "branch" is
> equivalent to "branch:branch" so don't commit to those either.
>
> That's pretty painful, so I really think these remote-tracking refs
> belong outside of refs/heads.
In the same vein, I think the refs/remotes/<remotename>/<branchname>
naming will make it possible for people who track multiple remotes to
sanely work with the fact that they might track 10 separate branches from
Jeff, one branch from me, and a couple of branches from Greg in the same
tree, without just going crazy.
I agree that we could solve the "don't touch that branch" issue another
way, by just making them read-only. But the reason I like the separate
namespace is that it just seems to organize the branches really well, and
in an unambiguous - and logical - manner.
I too find myself looking at "git branch" output, and a lot of it is stuff
I don't really care about - much of it is just the branches I got for just
tracking Junio's git repo.
Linus
^ permalink raw reply
* Problems with using git
From: Joseph Wakeling @ 2006-03-02 0:25 UTC (permalink / raw)
To: git
Hello all,
I'm a physics PhD student, not much experienced in serious software
writing, but I've got to the point where I felt learning to use a
version control system would be worthwhile. I decided to go for git
rather than CVS or Subversion because I felt a distributed VCS would
have more potential for future projects.
However, I've been experiencing some difficulties with using git, with
the results of commands not always being what the tutorial
<http://www.kernel.org/pub/software/scm/git/docs/tutorial.html> says it
should be. So, I'm hoping someone here can advise me!
I'm using openSUSE 10.0 and the package installed is git-core version
0.99.3git20050905-2.
The problem is to do with branches. Wanting to make some trial
revisions, I typed,
git branch trial
to create an appropriate branch. However, typing "git branch"
afterwards results in an error message: "git branch: I want a branch
name". No list of branches as the tutorial suggests!
However, I can use git checkout trial, make edits, and then go back to
git checkout master, and switch between the two, with the revisions in
one but not in the other. So the branches do seem to exist, and I can
modify them separately as one should be able to.
Now, having played around with the changes and found that they really
work very well, I'd like to merge the changes in the trial branch back
into the master. So, as per the tutorial, I type, git pull trial; and
am told, "No such remote branch: trial". I've also tried, git pull .
trial, which has the result, "No such remote branch: .".
I also note that when I'm in the master branch, having used git checkout
master, if I go into gitk, it does not show the existence of the trial
branch: but if I go into git checkout trial, it does. But the two
appear to be shown as completely separate entities.
Just as a test, I tried creating a throwaway branch,
git branch silly
which I then tried to delete with git branch -D silly. However, this
didn't delete the silly branch: it created a new one called -D (and both
of these *did* show up in gitk under the master branch). Using
git-branch instead of git branch results in an error message: "bash:
git-branch: command not found".
The result is that I'm kind of confused. I'd like to understand why the
commands I've tried from the tutorial haven't produced the results the
tutorial claims they will; but I'd also like to solve the original
problem: how just to merge the stuff in my trial branch back into the
master.
I suspect this might be simply that the SUSE package has some problems.
For example, it doesn't appear to have any man pages included. :-(
Thanks for any advice,
Best wishes,
-- Joe
^ permalink raw reply
* Re: git doesn't like big files when pushing
From: Greg KH @ 2006-03-02 0:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Pitre
In-Reply-To: <20060301233506.GA25209@kroah.com>
On Wed, Mar 01, 2006 at 03:35:06PM -0800, Greg KH wrote:
> On Wed, Mar 01, 2006 at 03:27:19PM -0800, Greg KH wrote:
> > On Wed, Mar 01, 2006 at 03:03:17PM -0800, Junio C Hamano wrote:
> > > I suspect "git push --thin origin" might help, if you are on my
> > > "master" branch:
> > >
> > > diff-tree a79a276... (from 2245be3...)
> > > Author: Junio C Hamano <junkio@cox.net>
> > > Date: Mon Feb 20 00:09:41 2006 -0800
> > >
> > > Add git-push --thin.
> > >
> > > Maybe we would want to make this default before it graduates to
> > > the master branch, but in the meantime to help testing things,
> > > this allows you to say "git push --thin destination".
> > >
> > > Signed-off-by: Junio C Hamano <junkio@cox.net>
> >
> > Will try that. I eventually gave up on the last push when it ran for 45
> > minutes at full cpu usage, and X got killed by the OOM killer in the
> > kernel for some reason...
>
> Nice, this worked!
>
> Now what's the odds that when I pull from the server to another box
> these same objects, the server will have the same problem as git-push
> did?
Ok, no problem there either.
thanks for the pointer to that option.
greg k-h
^ permalink raw reply
* [PATCH] cvsserver: Checkout correctly on Eclipse
From: Martin Langhoff @ 2006-03-02 0:58 UTC (permalink / raw)
To: git, junkio; +Cc: Martin Langhoff
Initial checkouts were failing to create Entries files under Eclipse.
Eclipse was waiting for two non-standard directory-resets to prepare for a new
directory from the server.
This patch is tricky, because the same directory resets tend to confuse other
clients. It's taken a bit of fiddling to get the commandline cvs client and
Eclipse to get a good, clean checkout.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
Heh! Using git-format-patch I make sure I don't send you stray spaces ;-)
(actually, I am back to using cperl-mode which highlights trailing ws)
I'll rewind/reset my 'cvsserver' branch so it's all clean and you can pull
from it and not fear white space monsters.
cheers,
martin
---
git-cvsserver.perl | 33 ++++++++++++++++++++++++++-------
1 files changed, 26 insertions(+), 7 deletions(-)
6a6ad59c4979e88e7f2a7b0997a3eb9fa115d6a7
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 3c588c9..d641c03 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -571,8 +571,19 @@ sub req_co
my $updater = GITCVS::updater->new($state->{CVSROOT}, $module, $log);
$updater->update();
+ $checkout_path =~ s|/$||; # get rid of trailing slashes
+
+ # Eclipse seems to need the Clear-sticky command
+ # to prepare the 'Entries' file for the new directory.
+ print "Clear-sticky $checkout_path/\n";
+ print $state->{CVSROOT} . "/$checkout_path/\n";
+ print "Clear-static-directory $checkout_path/\n";
+ print $state->{CVSROOT} . "/$checkout_path/\n";
+
# instruct the client that we're checking out to $checkout_path
- print "E cvs server: updating $checkout_path\n";
+ print "E cvs checkout: Updating $checkout_path\n";
+
+ my %seendirs = ();
foreach my $git ( @{$updater->gethead} )
{
@@ -585,16 +596,24 @@ sub req_co
print "Mod-time $git->{modified}\n";
# print some information to the client
- print "MT +updated\n";
- print "MT text U \n";
if ( defined ( $git->{dir} ) and $git->{dir} ne "./" )
{
- print "MT fname $checkout_path/$git->{dir}$git->{name}\n";
+ print "M U $checkout_path/$git->{dir}$git->{name}\n";
} else {
- print "MT fname $checkout_path/$git->{name}\n";
+ print "M U $checkout_path/$git->{name}\n";
}
- print "MT newline\n";
- print "MT -updated\n";
+
+ if (length($git->{dir}) && $git->{dir} ne './' && !exists($seendirs{$git->{dir}})) {
+
+ # Eclipse seems to need the Clear-sticky command
+ # to prepare the 'Entries' file for the new directory.
+ print "Clear-sticky $module/$git->{dir}\n";
+ print $state->{CVSROOT} . "/$module/$git->{dir}\n";
+ print "Clear-static-directory $module/$git->{dir}\n";
+ print $state->{CVSROOT} . "/$module/$git->{dir}\n";
+ print "E cvs checkout: Updating /$module/$git->{dir}\n";
+ $seendirs{$git->{dir}} = 1;
+ }
# instruct client we're sending a file to put in this path
print "Created $checkout_path/" . ( defined ( $git->{dir} ) and $git->{dir} ne "./" ? $git->{dir} . "/" : "" ) . "\n";
--
1.2.3.g67153
^ permalink raw reply related
* Re: git doesn't like big files when pushing
From: Martin Langhoff @ 2006-03-02 0:45 UTC (permalink / raw)
To: Greg KH; +Cc: Junio C Hamano, git, Nicolas Pitre
In-Reply-To: <20060302003418.GA11119@kroah.com>
On 3/2/06, Greg KH <greg@kroah.com> wrote:
> Ok, no problem there either.
>
> thanks for the pointer to that option.
Now that it has been tested twice, it's about time it becomes the default ;-)
cheers,
martin
^ permalink raw reply
* Re: Problems with using git
From: Linus Torvalds @ 2006-03-02 0:52 UTC (permalink / raw)
To: Joseph Wakeling; +Cc: git
In-Reply-To: <44063B7C.40609@webdrake.net>
On Thu, 2 Mar 2006, Joseph Wakeling wrote:
>
> I'm using openSUSE 10.0 and the package installed is git-core version
> 0.99.3git20050905-2.
I think your problems are just related to the fact that the tutorial is
newer than your git version.
Just fetch a newer version of git first (0.99.3 should be new enough to
happily fetch a newer version using git itself, but it might be easier to
just get a tar-ball), and you'll have an easier time at it.
Linus
^ permalink raw reply
* git-annotate dies when a patch is missing trailing newline
From: Martin Langhoff @ 2006-03-02 0:53 UTC (permalink / raw)
To: Git Mailing List, Ryan Anderson
Ryan, (& list)
git-annotate is dying when a patch is missing trailing newline. There
_are_ valid situations where code files are not expected to have
trailing newlines. Just thing of that glorious programming language,
PHP.
(Ducks).
Actually, 99% of my usage of git is tracking CVS projects so this is a
bit of a problem.
I had fixed it in Johannes version, but I'm lost as to where to fix it
in the current git-annotate. Help?
martin
^ permalink raw reply
* Re: Problems with using git
From: Andreas Ericsson @ 2006-03-02 1:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Joseph Wakeling, git
In-Reply-To: <Pine.LNX.4.64.0603011651240.22647@g5.osdl.org>
Linus Torvalds wrote:
>
> On Thu, 2 Mar 2006, Joseph Wakeling wrote:
>
>>I'm using openSUSE 10.0 and the package installed is git-core version
>>0.99.3git20050905-2.
>
>
> I think your problems are just related to the fact that the tutorial is
> newer than your git version.
>
> Just fetch a newer version of git first (0.99.3 should be new enough to
> happily fetch a newer version using git itself, but it might be easier to
> just get a tar-ball), and you'll have an easier time at it.
>
... and the way to fetch and install that repo with your current git is:
$ git clone git://git.kernel.org/pub/scm/git/git.git git
$ cd git && make all strip install
There are 2215 commits since 0.99.3, so I think you'll find much has
changed since then.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-annotate dies when a patch is missing trailing newline
From: Ryan Anderson @ 2006-03-02 1:53 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90603011653l7956d5dat99d88a7da98d21b6@mail.gmail.com>
On Thu, Mar 02, 2006 at 01:53:21PM +1300, Martin Langhoff wrote:
> Ryan, (& list)
>
> git-annotate is dying when a patch is missing trailing newline. There
> _are_ valid situations where code files are not expected to have
> trailing newlines. Just thing of that glorious programming language,
> PHP.
>
> (Ducks).
>
> Actually, 99% of my usage of git is tracking CVS projects so this is a
> bit of a problem.
>
> I had fixed it in Johannes version, but I'm lost as to where to fix it
> in the current git-annotate. Help?
Can you point me at a tree that has this problem? I'll see what I can
do about fixing it tonight.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: git-annotate dies when a patch is missing trailing newline
From: Junio C Hamano @ 2006-03-02 2:07 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20060302015303.GA27871@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
>> git-annotate is dying when a patch is missing trailing newline. There
>> _are_ valid situations where code files are not expected to have
>> trailing newlines. Just thing of that glorious programming language,
>> PHP.
>
> Can you point me at a tree that has this problem? I'll see what I can
> do about fixing it tonight.
$ cat script
#!/bin/sh
mkdir test-dir || exit
cd test-dir
git init-db
echo 'A quick brown fox jumps over the' >file
echo 'lazy dog' | tr -d '\012' >>file
git add file
git commit -a -m 'Initial.'
echo 'A quick brown fox
jumps over the' >file
echo 'lazy dog' | tr -d '\012' >>file
git commit -a -m 'Second.'
git annotate file
$ rm -fr test-dir
$ sh script
defaulting to local storage area
Committing initial tree 2850f9a320885b57bb410baffe972b19b17e9270
Use of uninitialized value in string ne at /home/junio/bin/Linux/git-annotate line 308, <$kid> line 10.
Use of uninitialized value in sprintf at /home/junio/bin/Linux/git-annotate line 309, <$kid> line 10.
Line 3 (3) does not match:
| No newline at end of file
|
1e698bcc5b142b542bf99a1a6f17864bc709dbf5 => 780bca516444e94219d4158b7fea97e763dcee6e
$ echo $?
9
$ exit
^ permalink raw reply
* Re: git-annotate dies when a patch is missing trailing newline
From: Junio C Hamano @ 2006-03-02 2:23 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90603011653l7956d5dat99d88a7da98d21b6@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> git-annotate is dying when a patch is missing trailing newline. There
> _are_ valid situations where code files are not expected to have
> trailing newlines. Just thing of that glorious programming language,
> PHP.
Does this help?
---
diff --git a/git-annotate.perl b/git-annotate.perl
index f9c2c6c..d30eba7 100755
--- a/git-annotate.perl
+++ b/git-annotate.perl
@@ -304,6 +304,10 @@ sub _git_diff_parse {
}
$ri++;
+ } elsif (m/^\\/) {
+
+ ; # ignore for now...
+
} else {
if (substr($_,1) ne get_line($slines,$ri) ) {
die sprintf("Line %d (%d) does not match:\n|%s\n|%s\n%s => %s\n",
^ permalink raw reply related
* Re: git-annotate dies when a patch is missing trailing newline
From: Martin Langhoff @ 2006-03-02 3:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslq1d1pr.fsf@assigned-by-dhcp.cox.net>
On 3/2/06, Junio C Hamano <junkio@cox.net> wrote:
> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
>
> > git-annotate is dying when a patch is missing trailing newline. There
> > _are_ valid situations where code files are not expected to have
> > trailing newlines. Just thing of that glorious programming language,
> > PHP.
>
> Does this help?
Yes, excellent! BTW, I just realized that git-cvsserver is in master,
but the "git-annotate -S" patch isn't there, so cvs annotate dies. Is
anything holding the patch back in next?
cheers,
martin
^ permalink raw reply
* Re: git-annotate dies when a patch is missing trailing newline
From: Junio C Hamano @ 2006-03-02 3:37 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90603011907h6d0d4450w426afb9ada33ddb0@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> Yes, excellent! BTW, I just realized that git-cvsserver is in master,
> but the "git-annotate -S" patch isn't there, so cvs annotate dies. Is
> anything holding the patch back in next?
Is -S in next?
^ permalink raw reply
* [PATCH] annotate: fix -S parameter to take a string
From: Martin Langhoff @ 2006-03-02 4:24 UTC (permalink / raw)
To: git, junkio; +Cc: Martin Langhoff
In the conversion to Getopt::Long, the -S / --rev-list parameter stopped
working. We need to tell Getopt::Long that it is a string.
As a bonus, the open() now does some useful error handling.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
Or pull from my cvsserver branch.
---
git-annotate.perl | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
5a44938cf5b79dd5d056075509f12b8e9a13e941
diff --git a/git-annotate.perl b/git-annotate.perl
index f9c2c6c..31318d3 100755
--- a/git-annotate.perl
+++ b/git-annotate.perl
@@ -31,7 +31,7 @@ our ($help, $longrev, $rename, $starting
my $rc = GetOptions( "long|l" => \$longrev,
"help|h" => \$help,
"rename|r" => \$rename,
- "rev-file|S" => \$rev_file);
+ "rev-file|S=s" => \$rev_file);
if (!$rc or $help) {
usage();
}
@@ -174,7 +174,8 @@ sub git_rev_list {
my $revlist;
if ($rev_file) {
- open($revlist, '<' . $rev_file);
+ open($revlist, '<' . $rev_file)
+ or die "Failed to open $rev_file : $!";
} else {
$revlist = open_pipe("git-rev-list","--parents","--remove-empty",$rev,"--",$file)
or die "Failed to exec git-rev-list: $!";
--
1.2.4.g09a27-dirty
^ permalink raw reply related
* Re: git-annotate dies when a patch is missing trailing newline
From: Martin Langhoff @ 2006-03-02 4:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe0pcy9c.fsf@assigned-by-dhcp.cox.net>
On 3/2/06, Junio C Hamano <junkio@cox.net> wrote:
> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
>
> > Yes, excellent! BTW, I just realized that git-cvsserver is in master,
> > but the "git-annotate -S" patch isn't there, so cvs annotate dies. Is
> > anything holding the patch back in next?
>
> Is -S in next?
Yes, but broken since it switched to Getopt::Long (grumble...). Patch
should be hitting the list now, you can also pull it from my repo.
cheers,
martin
^ permalink raw reply
* gitview: Use horizontal scroll bar in the tree view
From: Aneesh Kumar K.V @ 2006-03-02 4:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
From: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Subject: gitview: Use horizontal scroll bar in the tree view
Earlier we set up the window to never scroll
horizontally, which made it harder to use on a narrow screen.
This patch allows scrollbar to be used as needed by Gtk
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
d08429a55c3c4fb565cc3481e1263d04ecafebdd
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index ea05cd4..de9f3f3 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -513,7 +513,7 @@ class GitView:
scrollwin = gtk.ScrolledWindow()
- scrollwin.set_policy(gtk.POLICY_NEVER, gtk.POLICY_AUTOMATIC)
+ scrollwin.set_policy(gtk.POLICY_AUTOMATIC, gtk.POLICY_AUTOMATIC)
scrollwin.set_shadow_type(gtk.SHADOW_IN)
vbox.pack_start(scrollwin, expand=True, fill=True)
scrollwin.show()
@@ -526,9 +526,6 @@ class GitView:
self.treeview.show()
cell = CellRendererGraph()
- # Set the default width to 265
- # This make sure that we have nice display with large tag names
- cell.set_property("width", 265)
column = gtk.TreeViewColumn()
column.set_resizable(True)
column.pack_start(cell, expand=True)
--
1.2.3.gc55f-dirty
^ permalink raw reply related
* [PATCH 0/3] Annotate updates
From: Ryan Anderson @ 2006-03-02 5:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The following changes since commit 2b74cffa9179eed274be2a38c59b7e323c813737 are
found in the git repository at:
http://h4x0r5.com/~ryan/git/ryan.git annotate-upstream
and will follow this email as replies in patch format.
Ryan Anderson:
Handle \No newline at end of file.
annotate: Add a basic set of test cases.
annotate: --rev-file (-S) is not a boolean parameter
git-annotate.perl | 8 ++++-
t/t8001-annotate.sh | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 96 insertions(+), 1 deletions(-)
create mode 100755 t/t8001-annotate.sh
^ permalink raw reply
* [PATCH] Add git-annotate, a tool for assigning blame.
From: Ryan Anderson @ 2006-03-02 5:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ryan Anderson
In-Reply-To: <114127659642-git-send-email-ryan@michonline.com>
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
(Pull from http://h4x0r5.com/~ryan/git/ryan.git/ annotate-upstream )
I'm pretty sure this version (finally) gets the edge cases correct.
I would appreciate some other testing on this, as I can't find a case
where it falls down, but the files with a lot of history tend to have a
lot of lines, making them hard to spotcheck without having been an
intimate part of that history.
Oh, this is the "functional" version, but it might not qualify as "nice
looking" yet, pleaes, feel free to complain.
Makefile | 1
git-annotate.perl | 321 +++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 322 insertions(+), 0 deletions(-)
create mode 100755 git-annotate.perl
107045e8abb674a66ee7c682dd85a3d303f26e3c
diff --git a/Makefile b/Makefile
index 317be3c..86ffcf4 100644
--- a/Makefile
+++ b/Makefile
@@ -119,6 +119,7 @@ SCRIPT_SH = \
SCRIPT_PERL = \
git-archimport.perl git-cvsimport.perl git-relink.perl \
git-shortlog.perl git-fmt-merge-msg.perl git-rerere.perl \
+ git-annotate.perl \
git-svnimport.perl git-mv.perl git-cvsexportcommit.perl
SCRIPT_PYTHON = \
diff --git a/git-annotate.perl b/git-annotate.perl
new file mode 100755
index 0000000..8f98431
--- /dev/null
+++ b/git-annotate.perl
@@ -0,0 +1,321 @@
+#!/usr/bin/perl
+# Copyright 2006, Ryan Anderson <ryan@michonline.com>
+#
+# GPL v2 (See COPYING)
+#
+# This file is licensed under the GPL v2, or a later version
+# at the discretion of Linus Torvalds.
+
+use warnings;
+use strict;
+
+my $filename = shift @ARGV;
+
+
+my @stack = (
+ {
+ 'rev' => "HEAD",
+ 'filename' => $filename,
+ },
+);
+
+our (@lineoffsets, @pendinglineoffsets);
+our @filelines = ();
+open(F,"<",$filename)
+ or die "Failed to open filename: $!";
+
+while(<F>) {
+ chomp;
+ push @filelines, $_;
+}
+close(F);
+our $leftover_lines = @filelines;
+our %revs;
+our @revqueue;
+our $head;
+
+my $revsprocessed = 0;
+while (my $bound = pop @stack) {
+ my @revisions = git_rev_list($bound->{'rev'}, $bound->{'filename'});
+ foreach my $revinst (@revisions) {
+ my ($rev, @parents) = @$revinst;
+ $head ||= $rev;
+
+ $revs{$rev}{'filename'} = $bound->{'filename'};
+ if (scalar @parents > 0) {
+ $revs{$rev}{'parents'} = \@parents;
+ next;
+ }
+
+ my $newbound = find_parent_renames($rev, $bound->{'filename'});
+ if ( exists $newbound->{'filename'} && $newbound->{'filename'} ne $bound->{'filename'}) {
+ push @stack, $newbound;
+ $revs{$rev}{'parents'} = [$newbound->{'rev'}];
+ }
+ }
+}
+push @revqueue, $head;
+init_claim($head);
+$revs{$head}{'lineoffsets'} = {};
+handle_rev();
+
+
+my $i = 0;
+foreach my $l (@filelines) {
+ my ($output, $rev, $committer, $date);
+ if (ref $l eq 'ARRAY') {
+ ($output, $rev, $committer, $date) = @$l;
+ if (length($rev) > 8) {
+ $rev = substr($rev,0,8);
+ }
+ } else {
+ $output = $l;
+ ($rev, $committer, $date) = ('unknown', 'unknown', 'unknown');
+ }
+
+ printf("(%8s %10s %10s %d)%s\n", $rev, $committer, $date, $i++, $output);
+}
+
+sub init_claim {
+ my ($rev) = @_;
+ my %revinfo = git_commit_info($rev);
+ for (my $i = 0; $i < @filelines; $i++) {
+ $filelines[$i] = [ $filelines[$i], '', '', '', 1];
+ # line,
+ # rev,
+ # author,
+ # date,
+ # 1 <-- belongs to the original file.
+ }
+ $revs{$rev}{'lines'} = \@filelines;
+}
+
+
+sub handle_rev {
+ my $i = 0;
+ while (my $rev = shift @revqueue) {
+
+ my %revinfo = git_commit_info($rev);
+
+ foreach my $p (@{$revs{$rev}{'parents'}}) {
+
+ git_diff_parse($p, $rev, %revinfo);
+ push @revqueue, $p;
+ }
+
+
+ if (scalar @{$revs{$rev}{parents}} == 0) {
+ # We must be at the initial rev here, so claim everything that is left.
+ for (my $i = 0; $i < @{$revs{$rev}{lines}}; $i++) {
+ if (ref ${$revs{$rev}{lines}}[$i] eq '' || ${$revs{$rev}{lines}}[$i][1] eq '') {
+ claim_line($i, $rev, $revs{$rev}{lines}, %revinfo);
+ }
+ }
+ }
+ }
+}
+
+
+sub git_rev_list {
+ my ($rev, $file) = @_;
+
+ open(P,"-|","git-rev-list","--parents","--remove-empty",$rev,"--",$file)
+ or die "Failed to exec git-rev-list: $!";
+
+ my @revs;
+ while(my $line = <P>) {
+ chomp $line;
+ my ($rev, @parents) = split /\s+/, $line;
+ push @revs, [ $rev, @parents ];
+ }
+ close(P);
+
+ printf("0 revs found for rev %s (%s)\n", $rev, $file) if (@revs == 0);
+ return @revs;
+}
+
+sub find_parent_renames {
+ my ($rev, $file) = @_;
+
+ open(P,"-|","git-diff-tree", "-M50", "-r","--name-status", "-z","$rev")
+ or die "Failed to exec git-diff: $!";
+
+ local $/ = "\0";
+ my %bound;
+ my $junk = <P>;
+ while (my $change = <P>) {
+ chomp $change;
+ my $filename = <P>;
+ chomp $filename;
+
+ if ($change =~ m/^[AMD]$/ ) {
+ next;
+ } elsif ($change =~ m/^R/ ) {
+ my $oldfilename = $filename;
+ $filename = <P>;
+ chomp $filename;
+ if ( $file eq $filename ) {
+ my $parent = git_find_parent($rev, $oldfilename);
+ @bound{'rev','filename'} = ($parent, $oldfilename);
+ last;
+ }
+ }
+ }
+ close(P);
+
+ return \%bound;
+}
+
+
+sub git_find_parent {
+ my ($rev, $filename) = @_;
+
+ open(REVPARENT,"-|","git-rev-list","--remove-empty", "--parents","--max-count=1","$rev","--",$filename)
+ or die "Failed to open git-rev-list to find a single parent: $!";
+
+ my $parentline = <REVPARENT>;
+ chomp $parentline;
+ my ($revfound,$parent) = split m/\s+/, $parentline;
+
+ close(REVPARENT);
+
+ return $parent;
+}
+
+
+# Get a diff between the current revision and a parent.
+# Record the commit information that results.
+sub git_diff_parse {
+ my ($parent, $rev, %revinfo) = @_;
+
+ my ($ri, $pi) = (0,0);
+ open(DIFF,"-|","git-diff-tree","-M","-p",$rev,$parent,"--",
+ $revs{$rev}{'filename'}, $revs{$parent}{'filename'})
+ or die "Failed to call git-diff for annotation: $!";
+
+ my $slines = $revs{$rev}{'lines'};
+ my @plines;
+
+ my $gotheader = 0;
+ my ($remstart, $remlength, $addstart, $addlength);
+ my ($hunk_start, $hunk_index, $hunk_adds);
+ while(<DIFF>) {
+ chomp;
+ if (m/^@@ -(\d+),(\d+) \+(\d+),(\d+)/) {
+ ($remstart, $remlength, $addstart, $addlength) = ($1, $2, $3, $4);
+ # Adjust for 0-based arrays
+ $remstart--;
+ $addstart--;
+ # Reinit hunk tracking.
+ $hunk_start = $remstart;
+ $hunk_index = 0;
+ $gotheader = 1;
+
+ for (my $i = $ri; $i < $remstart; $i++) {
+ $plines[$pi++] = $slines->[$i];
+ $ri++;
+ }
+ next;
+ } elsif (!$gotheader) {
+ next;
+ }
+
+ if (m/^\+(.*)$/) {
+ my $line = $1;
+ $plines[$pi++] = [ $line, '', '', '', 0 ];
+ next;
+
+ } elsif (m/^-(.*)$/) {
+ my $line = $1;
+ if (get_line($slines, $ri) eq $line) {
+ # Found a match, claim
+ claim_line($ri, $rev, $slines, %revinfo);
+ } else {
+ die sprintf("Sync error: %d/%d\n|%s\n|%s\n%s => %s\n",
+ $ri, $hunk_start + $hunk_index,
+ $line,
+ get_line($slines, $ri),
+ $rev, $parent);
+ }
+ $ri++;
+
+ } else {
+ if (substr($_,1) ne get_line($slines,$ri) ) {
+ die sprintf("Line %d (%d) does not match:\n|%s\n|%s\n%s => %s\n",
+ $hunk_start + $hunk_index, $ri,
+ substr($_,1),
+ get_line($slines,$ri),
+ $rev, $parent);
+ }
+ $plines[$pi++] = $slines->[$ri++];
+ }
+ $hunk_index++;
+ }
+ close(DIFF);
+ for (my $i = $ri; $i < @{$slines} ; $i++) {
+ push @plines, $slines->[$ri++];
+ }
+
+ $revs{$parent}{lines} = \@plines;
+ return;
+}
+
+sub get_line {
+ my ($lines, $index) = @_;
+
+ return ref $lines->[$index] ne '' ? $lines->[$index][0] : $lines->[$index];
+}
+
+sub git_cat_file {
+ my ($parent, $filename) = @_;
+ return () unless defined $parent && defined $filename;
+ my $blobline = `git-ls-tree $parent $filename`;
+ my ($mode, $type, $blob, $tfilename) = split(/\s+/, $blobline, 4);
+
+ open(C,"-|","git-cat-file", "blob", $blob)
+ or die "Failed to git-cat-file blob $blob (rev $parent, file $filename): " . $!;
+
+ my @lines;
+ while(<C>) {
+ chomp;
+ push @lines, $_;
+ }
+ close(C);
+
+ return @lines;
+}
+
+
+sub claim_line {
+ my ($floffset, $rev, $lines, %revinfo) = @_;
+ my $oline = get_line($lines, $floffset);
+ @{$lines->[$floffset]} = ( $oline, $rev,
+ $revinfo{'author'}, $revinfo{'author_date'} );
+ #printf("Claiming line %d with rev %s: '%s'\n",
+ # $floffset, $rev, $oline) if 1;
+}
+
+sub git_commit_info {
+ my ($rev) = @_;
+ open(COMMIT, "-|","git-cat-file", "commit", $rev)
+ or die "Failed to call git-cat-file: $!";
+
+ my %info;
+ while(<COMMIT>) {
+ chomp;
+ last if (length $_ == 0);
+
+ if (m/^author (.*) <(.*)> (.*)$/) {
+ $info{'author'} = $1;
+ $info{'author_email'} = $2;
+ $info{'author_date'} = $3;
+ } elsif (m/^committer (.*) <(.*)> (.*)$/) {
+ $info{'committer'} = $1;
+ $info{'committer_email'} = $2;
+ $info{'committer_date'} = $3;
+ }
+ }
+ close(COMMIT);
+
+ return %info;
+}
--
1.2.2.gb342
^ permalink raw reply related
* Re: [PATCH] Add git-annotate, a tool for assigning blame.
From: Ryan Anderson @ 2006-03-02 5:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <11412765964127-git-send-email-ryan@michonline.com>
Sorry about this - I was in the wrong directory (apparently) when
running git-send-email. Actual patches in a second.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* [PATCH 2/3] annotate: Add a basic set of test cases.
From: Ryan Anderson @ 2006-03-02 5:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ryan Anderson
In-Reply-To: <11412770173208-git-send-email-ryan@michonline.com>
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
t/t8001-annotate.sh | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 89 insertions(+), 0 deletions(-)
create mode 100755 t/t8001-annotate.sh
7df39590a44352626c8d83a2b94d1ba11b24a118
diff --git a/t/t8001-annotate.sh b/t/t8001-annotate.sh
new file mode 100755
index 0000000..cae1794
--- /dev/null
+++ b/t/t8001-annotate.sh
@@ -0,0 +1,89 @@
+#!/bin/sh
+
+test_description='git-annotate'
+. ./test-lib.sh
+
+test_expect_success \
+ 'prepare reference tree' \
+ 'echo "1A quick brown fox jumps over the" >file &&
+ echo "lazy dog" >>file &&
+ git add file
+ GIT_AUTHOR_NAME="A" git commit -a -m "Initial."'
+
+test_expect_success \
+ 'check all lines blamed on A' \
+ '[ $(git annotate file | awk "{print \$3}" | grep -c "A") == 2 ]'
+
+test_expect_success \
+ 'Setup new lines blamed on B' \
+ 'echo "2A quick brown fox jumps over the" >>file &&
+ echo "lazy dog" >> file &&
+ GIT_AUTHOR_NAME="B" git commit -a -m "Second."'
+
+test_expect_success \
+ 'Two lines blamed on A' \
+ '[ $(git annotate file | awk "{print \$3}" | grep -c "A") == 2 ]'
+
+test_expect_success \
+ 'Two lines blamed on B' \
+ '[ $(git annotate file | awk "{print \$3}" | grep -c "B") == 2 ]'
+
+test_expect_success \
+ 'merge-setup part 1' \
+ 'git checkout -b branch1 master &&
+ echo "3A slow green fox jumps into the" >> file &&
+ echo "well." >> file &&
+ GIT_AUTHOR_NAME="B1" git commit -a -m "Branch1-1"'
+
+test_expect_success \
+ 'Two lines blamed on A' \
+ '[ $(git annotate file | awk "{print \$3}" | grep -c "^A$") == 2 ]'
+
+test_expect_success \
+ 'Two lines blamed on B' \
+ '[ $(git annotate file | awk "{print \$3}" | grep -c "^B$") == 2 ]'
+
+test_expect_success \
+ 'Two lines blamed on B1' \
+ '[ $(git annotate file | awk "{print \$3}" | grep -c "^B1$") == 2 ]'
+
+test_expect_success \
+ 'merge-setup part 2' \
+ 'git checkout -b branch2 master &&
+ sed -i -e "s/2A quick brown/4A quick brown lazy dog/" file &&
+ GIT_AUTHOR_NAME="B2" git commit -a -m "Branch2-1"'
+
+test_expect_success \
+ 'Two lines blamed on A' \
+ '[ $(git annotate file | awk "{print \$3}" | grep -c "^A$") == 2 ]'
+
+test_expect_success \
+ 'One line blamed on B' \
+ '[ $(git annotate file | awk "{print \$3}" | grep -c "^B$") == 1 ]'
+
+test_expect_success \
+ 'One line blamed on B2' \
+ '[ $(git annotate file | awk "{print \$3}" | grep -c "^B2$") == 1 ]'
+
+
+test_expect_success \
+ 'merge-setup part 3' \
+ 'git pull . branch1'
+
+test_expect_success \
+ 'Two lines blamed on A' \
+ '[ $(git annotate file | awk "{print \$3}" | grep -c "^A$") == 2 ]'
+
+test_expect_success \
+ 'One line blamed on B' \
+ '[ $(git annotate file | awk "{print \$3}" | grep -c "^B$") == 1 ]'
+
+test_expect_success \
+ 'Two lines blamed on B1' \
+ '[ $(git annotate file | awk "{print \$3}" | grep -c "^B1$") == 2 ]'
+
+test_expect_success \
+ 'One line blamed on B2' \
+ '[ $(git annotate file | awk "{print \$3}" | grep -c "^B2$") == 1 ]'
+
+test_done
--
1.2.2.g1070
^ permalink raw reply related
* [PATCH 3/3] annotate: --rev-file (-S) is not a boolean parameter
From: Ryan Anderson @ 2006-03-02 5:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ryan Anderson
In-Reply-To: <11412770172128-git-send-email-ryan@michonline.com>
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
git-annotate.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
75846f79f31c9833303ff7d44b87b53c39f4bf9a
diff --git a/git-annotate.perl b/git-annotate.perl
index d6028c9..30f9a71 100755
--- a/git-annotate.perl
+++ b/git-annotate.perl
@@ -31,7 +31,7 @@ our ($help, $longrev, $rename, $starting
my $rc = GetOptions( "long|l" => \$longrev,
"help|h" => \$help,
"rename|r" => \$rename,
- "rev-file|S" => \$rev_file);
+ "rev-file|S=s" => \$rev_file);
if (!$rc or $help) {
usage();
}
--
1.2.2.g1070
^ 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