* Re: [PATCH] git-clean fails on files beginning with a dash
From: Junio C Hamano @ 2006-05-30 8:49 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: git
In-Reply-To: <20060529150632.G6794bab6@leonov.stosberg.net>
Dennis Stosberg <dennis@stosberg.net> writes:
> Reproducible with:
>
> $ git init-db
> $ echo "some text" >-file
> $ git clean
> Removing -file
> rm: invalid option -- l
> Try `rm --help' for more information.
Thanks.
^ permalink raw reply
* Re: [PATCH] Automatically line wrap long commit messages.
From: Junio C Hamano @ 2006-05-30 8:38 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060529094605.GB27194@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> OK. Ignore both patches then. Two negative votes in such a short
> time suggests they are probably not generally accepted. ;-)
>
>> We probably should allow "commit -F -" to read from the standard
>> input if we already don't, but that is about as far as I am
>> willing to go at this moment.
>
> We do. So apparently the solution to my usage issue is:
>
> $ fmt -w 60 | git commit -F-
> This is my message.
>
> This is the body. Etc....
> EOF
>
> I'm thinking that's too much work for me.
If we supported multiple -m (presumably each becomes a single line?)
with internal fmt, I do not see how it would become less work.
$ git commit -w60 -m "This is my message." \
-m '' \
-m 'This is the body. Etc....'
looks more typing to me, even without the second line to force
the empty line between the summary and the body.
^ permalink raw reply
* [PATCH] cvsimport: complete the cvsps run before starting the import
From: Martin Langhoff @ 2006-05-30 8:08 UTC (permalink / raw)
To: junio, git; +Cc: Martin Langhoff
On 5/24/06, Linus Torvalds <torvalds@osdl.org> wrote:
> It's entirely possible that the fact that it now seems to work for me is
> purely timing-related, since I also ended up using "-P cvsps-output" to
> avoid having a huge cvsps binary in memory at the same time.
We now capture the output of cvsps to a tempfile, and then read it in.
cvsps 2.1 works quite a bit "in memory", and only prints its patchset info
once it has finished talking with cvs, but apparently retaining all that
memory allocation. With this patch, cvsps is finished and reaped before
cvsimport start working (and growing). So the footprint of the whole
process is much lower.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
I don't particularly like the idea of switching from a safe system() call
to this ugly one. But this patch makes a huge difference importing gentoo's
repo, and I could not find a way to get system() to do redirection.
Of course, we could do the redirection in Perl. Ugly vs uglier?
---
git-cvsimport.perl | 32 ++++++++++++++++++++++----------
1 files changed, 22 insertions(+), 10 deletions(-)
5ce458e0883f39ae774ec67211e6565b65139b7f
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 60fc86a..2239c67 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -529,24 +529,36 @@ if ($opt_A) {
write_author_info("$git_dir/cvs-authors");
}
-my $pid = open(CVS,"-|");
-die "Cannot fork: $!\n" unless defined $pid;
-unless($pid) {
+#
+# run cvsps into a file unless it's provided already
+#
+my $cvspsfile;
+if ($opt_P) {
+ $cvspsfile = $opt_P;
+} else {
+ my $cvspsfh;
+ ($cvspsfh, $cvspsfile) = tempfile('gitXXXXXX', SUFFIX => '.cvsps',
+ DIR => File::Spec->tmpdir());
+ close ($cvspsfh);
+ my ($cvspserrfh, $cvspserr) = tempfile('gitXXXXXX', SUFFIX => '.err',
+ DIR => File::Spec->tmpdir());
+ close ($cvspserrfh);
+
my @opt;
@opt = split(/,/,$opt_p) if defined $opt_p;
unshift @opt, '-z', $opt_z if defined $opt_z;
- unshift @opt, '-q' unless defined $opt_v;
+ unshift @opt, '-q' unless defined $opt_v;
unless (defined($opt_p) && $opt_p =~ m/--no-cvs-direct/) {
push @opt, '--cvs-direct';
}
- if ($opt_P) {
- exec("cat", $opt_P);
- } else {
- exec("cvsps","--norc",@opt,"-u","-A",'--root',$opt_d,$cvs_tree);
- die "Could not start cvsps: $!\n";
- }
+
+ print "Running cvsps\n" if $opt_v;
+ system(join(' ', "cvsps","--norc",@opt,"-u","-A",'--root',$opt_d,$cvs_tree, "1>$cvspsfile" ))
+ or die "Error in cvsps: $!\n";
}
+open (CVS, "<$cvspsfile")
+ or die "Cannot open cvsps output file $cvspsfile: $!\n";
## cvsps output:
#---------------------
--
1.3.2.g82000
^ permalink raw reply related
* Re: [PATCH 4/4] Add a basic test case for git send-email, and fix some real bugs discovered.
From: Junio C Hamano @ 2006-05-30 6:58 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <7v1wuc3t9y.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> On top of yours, I think this covers the CC: trouble your test
> triggers.
Sorry, I did not look closely enough. You are trying to keep
the address human friendly as long as possible so that you can
place them on the headers, so the previous one was bogus.
*BLUSH*
I think this is lower impact. On the other hand, it appears
that at least whatever pretends to be /usr/lib/sendmail on my
box seems to grok 'A <author@example.com>' just fine, so maybe
the test was bogus (in which case you should just change the
expected command line parameters to include the human name).
I dunno.
-- >8 --
From c95682409346f7acc220ac64f453933d5a59ec3f Mon Sep 17 00:00:00 2001
From: Junio C Hamano <junkio@cox.net>
Date: Mon, 29 May 2006 23:53:13 -0700
Subject: [PATCH] send-email: do not pass bogus address to local sendmail binary
This makes t9001 test happy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-send-email.perl | 4 +++-
t/t9001-send-email.sh | 19 +++++++++++++------
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index d418d6c..ac84553 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -387,7 +387,9 @@ X-Mailer: git-send-email $gitversion
my $pid = open my $sm, '|-';
defined $pid or die $!;
if (!$pid) {
- exec($smtp_server,'-i',@recipients) or die $!;
+ exec($smtp_server,'-i',
+ map { extract_valid_address($_) }
+ @recipients) or die $!;
}
print $sm "$header\n$message";
close $sm or die $?;
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 276cbac..a61da1e 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -13,10 +13,14 @@ test_expect_success \
test_expect_success \
'Setup helper tool' \
- 'echo "#!/bin/sh" > fake.sendmail
- echo "shift" >> fake.sendmail
- echo "echo \"\$*\" > commandline" >> fake.sendmail
- echo "cat > msgtxt" >> fake.sendmail
+ '(echo "#!/bin/sh"
+ echo shift
+ echo for a
+ echo do
+ echo " echo \"!\$a!\""
+ echo "done >commandline"
+ echo "cat > msgtxt"
+ ) >fake.sendmail
chmod +x ./fake.sendmail
git add fake.sendmail
GIT_AUTHOR_NAME="A" git commit -a -m "Second."'
@@ -26,9 +30,12 @@ test_expect_success \
'git format-patch -n HEAD^1
git send-email -from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" ./0001*txt'
+cat >expected <<\EOF
+!nobody@example.com!
+!author@example.com!
+EOF
test_expect_success \
'Verify commandline' \
- 'cline=$(cat commandline)
- [ "$cline" == "nobody@example.com author@example.com" ]'
+ 'diff commandline expected'
test_done
--
1.3.3.g5029f
^ permalink raw reply related
* Re: [PATCH 4/4] Add a basic test case for git send-email, and fix some real bugs discovered.
From: Junio C Hamano @ 2006-05-30 6:45 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <7v8xok3vhj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>> 64ea8c0210c2e9d1711a870460eca326778a4ffc
>> t/t9001-send-email.sh | 34 ++++++++++++++++++++++++++++++++++
>> 1 files changed, 34 insertions(+), 0 deletions(-)
>> create mode 100755 t/t9001-send-email.sh
>
> Adds test, alright, but I do not see the fix. Is this a thinko?
On top of yours, I think this covers the CC: trouble your test
triggers.
-- >8 -
send-email: fix cc address fed to underlying sendmail
---
diff --git a/git-send-email.perl b/git-send-email.perl
index d418d6c..d61ef8e 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -448,9 +448,11 @@ foreach my $t (@files) {
else {
$author_not_sender = $2;
}
- printf("(mbox) Adding cc: %s from line '%s'\n",
- $2, $_) unless $quiet;
- push @cc, $2;
+ my $cc = extract_valid_address($2);
+ printf("(mbox) Adding cc: %s from ".
+ "line '%s'\n",
+ $cc, $_) unless $quiet;
+ push @cc, $cc;
}
} else {
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 276cbac..a61da1e 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -13,10 +13,14 @@ test_expect_success \
test_expect_success \
'Setup helper tool' \
- 'echo "#!/bin/sh" > fake.sendmail
- echo "shift" >> fake.sendmail
- echo "echo \"\$*\" > commandline" >> fake.sendmail
- echo "cat > msgtxt" >> fake.sendmail
+ '(echo "#!/bin/sh"
+ echo shift
+ echo for a
+ echo do
+ echo " echo \"!\$a!\""
+ echo "done >commandline"
+ echo "cat > msgtxt"
+ ) >fake.sendmail
chmod +x ./fake.sendmail
git add fake.sendmail
GIT_AUTHOR_NAME="A" git commit -a -m "Second."'
@@ -26,9 +30,12 @@ test_expect_success \
'git format-patch -n HEAD^1
git send-email -from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" ./0001*txt'
+cat >expected <<\EOF
+!nobody@example.com!
+!author@example.com!
+EOF
test_expect_success \
'Verify commandline' \
- 'cline=$(cat commandline)
- [ "$cline" == "nobody@example.com author@example.com" ]'
+ 'diff commandline expected'
test_done
^ permalink raw reply related
* Re: [RFC] git-fetch - repack in the background after fetching
From: Daniel Barkalow @ 2006-05-30 6:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0605292147010.5623@g5.osdl.org>
On Mon, 29 May 2006, Linus Torvalds wrote:
> Some long-running (in git terms) git programs will look up the pack-files
> when they start, and if you repack after that, they won't see the new
> pack-file, but they _will_ notice that the unpacked files are no longer
> there, and will be very unhappy indeed.
We should be able to fix this, right? If an object isn't found in packs or
unpacked, look for new packs; if there are any, look for the object in
them; if it's not there, then give up. The only tricky thing is making it
possible to scan through the available packs without installing any that
are already installed. I think the failure case is only a critical path in
the history-walking fetch code, which should probably disable this (or
defer it to after trying to download the object).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: irc usage..
From: Martin Langhoff @ 2006-05-30 6:01 UTC (permalink / raw)
To: Donnie Berkholz
Cc: Linus Torvalds, Yann Dirson, Git Mailing List, Matthias Urlichs,
Johannes Schindelin
In-Reply-To: <447BD8C1.6090402@gentoo.org>
On 5/30/06, Donnie Berkholz <spyderous@gentoo.org> wrote:
> All I can think of is that I somehow OOM'd when I manually ran a repack
> and didn't notice it. But that should've at least made me unable to
> resume the cvsimport process, which happily kept chugging along later on.
Sounds likely -- and cvsimport restarts gracefully, though you might want to do
git checkout HEAD
to get a usable checkout if the very first import failed. However, the
default head is master, and what you want to look at is origin or
whatever you passed as your -o parameter. I use cvshead normally, so I
do
git log cvshead
> > My dmesg talks about an earlier cvs segfault. Nasty tree you have here
> > -- it's breaking all sorts of things... and teaching us a thing or two
> > about the import process.
> >
> >> Committed patch 249100 (origin 2005-08-20 05:05:58)
> >
> > Hmmm? How can you be at patch 249100 and still be a good year ahead of
> > me? Have you told cvsps to cut off old history?
>
> Nope. I ran the exact cvsps flags you posted earlier to create it.
Oh, that was an earlier PEBKAK at my end: I did git log HEAD instead
of git log cvshead. My import is now at 293145 (cvshead +0000
2005-12-25 12:24:42) which looks promising.
cheers,
martin
^ permalink raw reply
* Re: [PATCH 4/4] Add a basic test case for git send-email, and fix some real bugs discovered.
From: Junio C Hamano @ 2006-05-30 5:57 UTC (permalink / raw)
To: Ryan Anderson; +Cc: junkio, git
In-Reply-To: <11489310153617-git-send-email-1>
Ryan Anderson <rda@google.com> writes:
> Signed-off-by: Ryan Anderson <rda@google.com>
>
> ---
>
> 64ea8c0210c2e9d1711a870460eca326778a4ffc
> t/t9001-send-email.sh | 34 ++++++++++++++++++++++++++++++++++
> 1 files changed, 34 insertions(+), 0 deletions(-)
> create mode 100755 t/t9001-send-email.sh
Adds test, alright, but I do not see the fix. Is this a thinko?
^ permalink raw reply
* Re: irc usage..
From: Donnie Berkholz @ 2006-05-30 5:31 UTC (permalink / raw)
To: Martin Langhoff
Cc: Linus Torvalds, Yann Dirson, Git Mailing List, Matthias Urlichs,
Johannes Schindelin
In-Reply-To: <46a038f90605291719r292269bct61bf2817a9791e3d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]
Martin Langhoff wrote:
> On 5/30/06, Donnie Berkholz <spyderous@gentoo.org> wrote:
>> Looking closer, I see that the memory suckers do appear to be git, from
>> dmesg:
>>
>> Out of Memory: Kill process 17230 (git-repack) score 97207 and children.
>> Out of memory: Killed process 17231 (git-rev-list).
>
> That would mean that you do have Linus' patch then. Grep cvsimport for
> repack and remove the -a -- and consider using his recent patch to
> rev-list.
You certainly would think so, and I did as well, but available evidence
indicates otherwise. I'm not sure how the repack got in there.
donnie@supernova ~ $ type git-cvsimport
git-cvsimport is /usr/bin/git-cvsimport
donnie@supernova ~ $ grep repack /usr/bin/git-cvsimport
donnie@supernova ~ $
All I can think of is that I somehow OOM'd when I manually ran a repack
and didn't notice it. But that should've at least made me unable to
resume the cvsimport process, which happily kept chugging along later on.
> My dmesg talks about an earlier cvs segfault. Nasty tree you have here
> -- it's breaking all sorts of things... and teaching us a thing or two
> about the import process.
>
>> Committed patch 249100 (origin 2005-08-20 05:05:58)
>
> Hmmm? How can you be at patch 249100 and still be a good year ahead of
> me? Have you told cvsps to cut off old history?
Nope. I ran the exact cvsps flags you posted earlier to create it.
Thanks,
Donnie
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [RFC] git-fetch - repack in the background after fetching
From: Martin Langhoff @ 2006-05-30 5:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0605292147010.5623@g5.osdl.org>
On 5/30/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Repacking is, but "-d" is not necessarily.
Ok -- strawman knocked down. Next try...
> Some long-running (in git terms) git programs will look up the pack-files
> when they start, and if you repack after that, they won't see the new
> pack-file, but they _will_ notice that the unpacked files are no longer
> there, and will be very unhappy indeed.
>
> So the "-d" part really isn't necessarily safe.
>
> Of course, in -practice- you won't likely see this, and the archive itself
> is never corrupted, but concurrent git ops can fail due to it in theory,
> and quite frankly, that's not the kind of SCM I like to use.
Would it be safe to repack -a && sleep 180 && git prune-packed ?
> So either just do "git repack -a", or do things synchronously.
Which I take to mean 'prune synchronously'. So what about...
+
+if test $(git rev-list --unpacked --all | wc -l) -gt 1000
+then
+ echo "Repacking in the background"
+ git prune-packed
+ nice git repack -a -q &
+fi
this would mean that at any given time there's a bit of overlap
between packed and unpacked, but will be resolved over repeated
commands.
martin
^ permalink raw reply
* Re: [RFC] git-fetch - repack in the background after fetching
From: Linus Torvalds @ 2006-05-30 4:51 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <11489641631558-git-send-email-martin@catalyst.net.nz>
On Tue, 30 May 2006, Martin Langhoff wrote:
>
> There's been some discussion about repacking proactively without
> preventing further work. But as Linus said, repacking on an active
> repo is _safe_
Repacking is, but "-d" is not necessarily.
You really should do the prune-packed only _after_ you've repacked, and no
old git programs are around.
Some long-running (in git terms) git programs will look up the pack-files
when they start, and if you repack after that, they won't see the new
pack-file, but they _will_ notice that the unpacked files are no longer
there, and will be very unhappy indeed.
So the "-d" part really isn't necessarily safe.
Of course, in -practice- you won't likely see this, and the archive itself
is never corrupted, but concurrent git ops can fail due to it in theory,
and quite frankly, that's not the kind of SCM I like to use.
So either just do "git repack -a", or do things synchronously.
Linus
^ permalink raw reply
* Re: git-cvsimport problem
From: Linus Torvalds @ 2006-05-30 4:37 UTC (permalink / raw)
To: Grzegorz Kulewski; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0605300236270.25988@alpha.polcom.net>
On Tue, 30 May 2006, Grzegorz Kulewski wrote:
>
> and it looks like it hangs in the middle with message:
>
> cvs [rlog aborted]: unexpected '\x0' reading revision number in RCS file
> /home/cvsroot/lms/templates/noaccess.html,v
Are you sure that CVS archive isn't corrupted? That sounds like an
internal CVS error to me. Doing a "git cvsimport" will obviously get every
single version of every single file, so it will inevitably also hit errors
that you migt not hit with a regular "cvs co" (which will only get the
current version).
There's bound to be some "fsck for CVS" (since people edit files by hand,
and mistakes must happen), but I have no idea.
That said, it's not like we haven't had our share of cvsps issues and
other things, so who knows..
> and to my understanding does not do anything usefull next. Nothing is imported
> (there is only nearly empty .git tree).
Do "git log origin" to see what has been imported. If a cvsimport is
broken in the middle, you'll not get any checked-out state, and your HEAD
won't point to anything, but the "origin" branch has been created and
contains whatever has been imported so far.
Linus
^ permalink raw reply
* [RFC] git-fetch - repack in the background after fetching
From: Martin Langhoff @ 2006-05-30 4:42 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
Check whether we have a large set of unpacked objects and repack
after the fetch, but don't for the user to wait for us.
---
There's been some discussion about repacking proactively without
preventing further work. But as Linus said, repacking on an active
repo is _safe_, so repack in the background.
If we like this approach, we should at least respect a git-repo-config
entry saying core.noautorepack for users who don't want it. I don't
really know if there is any convention for us to check if we are in
a resource-constrained situation (aka laptops on battery). If there
is, we should respect that as well. I suspect anacron and others
do this already but I can't find any references.
We can potentially do it on commit, merge and push as well.
---
git-fetch.sh | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
5498d015eb1062928a504af3c6b3cb9b776088e8
diff --git a/git-fetch.sh b/git-fetch.sh
index 69bd810..4d64cdb 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -424,3 +424,9 @@ case ",$update_head_ok,$orig_head," in
fi
;;
esac
+
+if test $(git rev-list --unpacked --all | wc -l) -gt 1000
+then
+ echo "Repacking in the background"
+ nice git repack -a -d -q &
+fi
--
1.3.2.g82000
^ permalink raw reply related
* Re: [PATCH 0/10] re-based and expanded tree-walker cleanup patches
From: Junio C Hamano @ 2006-05-30 4:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605292112530.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Having to move around whole patches in the editor is not what you want to
> do.
I know. What I meant was:
$ format-patch >those-patches
$ am -i those-patches
.. say no to the first two and yes to the third one
$ am -i those-patches ;# again!!
.. say yes to the first two
> I was thinking more along the lines of
>
> (a) git-rev-list --pretty=oneline "$upstream"..ORIG_HEAD > rev-list
>
> (b) edit the rev-list, moving the single lines around, deleting them, etc
>
> (c) cat rev-list |
> git-format-patch -k --stdout --stdin --full_index |
> git-am
>
> because the "--pretty=oneline" format is actually very nice as a way to
> re-order things and select single commits to be deleted or whatever..
I like this approach as well.
^ permalink raw reply
* Re: [PATCH 0/10] re-based and expanded tree-walker cleanup patches
From: Linus Torvalds @ 2006-05-30 4:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vmzd05i25.fsf@assigned-by-dhcp.cox.net>
On Mon, 29 May 2006, Junio C Hamano wrote:
>
> > Pretty powerful, although at one point I was wondering about having a "git
> > rebase" that could switch commits around or drop unwanted ones (ie let the
> > user edit the cherry-picking list before the actual rebase).
>
> I think true power users would just do the last two lines of
> git-rebase.sh by hand in two steps. By stashing away the
> format-patch output, and using git-am interactively, you can
> easily drop unwanted ones, and then re-run git-am on the same
> format-patch output to apply the ones you dropped on the first
> run practically amounts to reordering the patches ;-).
Having to move around whole patches in the editor is not what you want to
do. I was thinking more along the lines of
(a) git-rev-list --pretty=oneline "$upstream"..ORIG_HEAD > rev-list
(b) edit the rev-list, moving the single lines around, deleting them, etc
(c) cat rev-list |
git-format-patch -k --stdout --stdin --full_index |
git-am
because the "--pretty=oneline" format is actually very nice as a way to
re-order things and select single commits to be deleted or whatever..
Linus
^ permalink raw reply
* Re: [PATCH 0/10] re-based and expanded tree-walker cleanup patches
From: Junio C Hamano @ 2006-05-30 3:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605291739430.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Mon, 29 May 2006, Junio C Hamano wrote:
>>
>> Sorry for having you have done this -- last night I've merged
>> the series without rebasing and have the result in "next". I'll
>> compare to see if you have spotted my mismerges there tonight.
>
> It was interesting. I cleaned up the series and switched the order of some
> commits in my tree by doing first a "git rebase" and then cherry-picking
> them into another branch, and using "git commit --amend" to fix up some of
> the things I had missed.
I just did this (readers on the list needs to disect "next" if
they are interested to reproduce this, since I do not publish
individual topic heads, but each of the merge commits on "next"
tells which topics are merged, so that should be trivial):
$ git checkout -b lt/tree-2 master
$ apply your 10-patch series
$ git show-branch lt/tree lt/tree-2 jc/lt-tree-n-cache-tree next
Your yesterday's series is on lt/tree, and jc/lt-tree-n-cache-tree
is my "evil merge" branch to adjust it to the cache-tree that I had
in "next". It's tip has cache-tree and lt/tree merged, so
it should match the early parts of today's 10-patch series. I
used show-branch to find that lt/tree-2~5 is the one to match
yesterday's series:
$ git diff --name-only lt/tree~4..lt/tree |
xargs git diff lt/tree-2~5 jc/lt-tree-n-cache-tree --
This shows only cosmetic differences, which is good.
> Pretty powerful, although at one point I was wondering about having a "git
> rebase" that could switch commits around or drop unwanted ones (ie let the
> user edit the cherry-picking list before the actual rebase).
I think true power users would just do the last two lines of
git-rebase.sh by hand in two steps. By stashing away the
format-patch output, and using git-am interactively, you can
easily drop unwanted ones, and then re-run git-am on the same
format-patch output to apply the ones you dropped on the first
run practically amounts to reordering the patches ;-).
^ permalink raw reply
* [PATCH] git-svn: remove assertion that broke with older versions of svn
From: Eric Wong @ 2006-05-30 2:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <20060529063543.GA8128@localdomain>
svn < 1.3.x would display changes to keywords lines as modified
if they aren't expanded in the working copy. We already check
for changes against the git tree here, so checking against the
svn one is probably excessive.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
b430de64cb228512b9a817499203827c0ef645aa
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index b3e0684..aac8779 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -567,7 +567,6 @@ sub precommit_check {
sub svn_checkout_tree {
my ($svn_rev, $treeish) = @_;
my $from = file_to_s("$REV_DIR/$svn_rev");
- assert_svn_wc_clean($svn_rev);
assert_tree($from);
print "diff-tree $from $treeish\n";
my $pid = open my $diff_fh, '-|';
--
1.3.2.g7d11
^ permalink raw reply related
* [PATCH] git-svn: t0001: workaround a heredoc bug in old versions of dash
From: Eric Wong @ 2006-05-30 2:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <20060529063543.GA8128@localdomain>
The dash installed on my Debian Sarge boxes don't seem to like
<<'' as a heredoc starter. Recent versions of dash do not need
this fix.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/t/t0001-contrib-git-svn-props.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
edbca3e1b96747330a4b1459e914b07105b3bc44
diff --git a/contrib/git-svn/t/t0001-contrib-git-svn-props.sh b/contrib/git-svn/t/t0001-contrib-git-svn-props.sh
index 6fa7889..23a5a2a 100644
--- a/contrib/git-svn/t/t0001-contrib-git-svn-props.sh
+++ b/contrib/git-svn/t/t0001-contrib-git-svn-props.sh
@@ -20,9 +20,10 @@ a_empty_cr=
a_empty_crlf=
cd import
- cat >> kw.c <<''
+ cat >> kw.c <<\EOF
/* Make it look like somebody copied a file from CVS into SVN: */
/* $Id: kw.c,v 1.1.1.1 1994/03/06 00:00:00 eric Exp $ */
+EOF
printf "Hello\r\nWorld\r\n" > crlf
a_crlf=`git-hash-object -w crlf`
--
1.3.2.g7d11
^ permalink raw reply related
* [PATCH] git-svn: compat fixes for older svn and dash
From: Eric Wong @ 2006-05-30 2:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060529063543.GA8128@localdomain>
The following patches work around problems I had with testing
git-svn on my Debian Sarge box.
^ permalink raw reply
* Re: git-cvsimport problem
From: Martin Langhoff @ 2006-05-30 1:56 UTC (permalink / raw)
To: Grzegorz Kulewski; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0605300236270.25988@alpha.polcom.net>
On 5/30/06, Grzegorz Kulewski <kangur@polcom.net> wrote:
> I think I hit some problem in git-cvsimport or maybe cvsps or maybe (but
> unprobable) in network communication.
Looks like a cvsps issue. From ps, grab the whole commandine that is
used for the cvsps invocation and try to run it manually. cvsps has
some debugging flags, I would try adding -x -v to see more output, and
perhaps try with --no-cvs-direct
The other thing affecting you is the version of the remote cvs server.
cheers,
martin
^ permalink raw reply
* git-cvsimport problem
From: Grzegorz Kulewski @ 2006-05-30 1:06 UTC (permalink / raw)
To: Git Mailing List
Hi,
I think I hit some problem in git-cvsimport or maybe cvsps or maybe (but
unprobable) in network communication.
I am trying to do:
git-cvsimport -d :pserver:cvs@cvs.rulez.pl:/home/cvsroot -C lms -i -k -u
-m -v lms
and it looks like it hangs in the middle with message:
cvs [rlog aborted]: unexpected '\x0' reading revision number in RCS file
/home/cvsroot/lms/templates/noaccess.html,v
and to my understanding does not do anything usefull next. Nothing is
imported (there is only nearly empty .git tree). I have to press CTRL-C to
stop it.
strace:
[pid 30796] read(3, "---------------------\nM revision"..., 4096) = 2068
[pid 30796] read(3, "M date: 2003/06/20 21:07:56; au"..., 4096) = 1448
[pid 30796] read(3, ".19\nM date: 2003/05/26 21:05:47;"..., 4096) = 1448
[pid 30796] read(3, " revision 1.15.2.3\nM date: 2003/"..., 4096) = 1276
[pid 30796] write(2, "cvs [rlog aborted]: unexpected \'"..., 117cvs [rlog
aborted]: unexpected '\x0' reading revision number in RCS file
/home/cvsroot/lms/templates/noaccess.html,v
) = 117
[pid 30796] read(3, <-- hangs on that read
ps:
kangur 30791 30556 3 02:55 pts/4 S+ 0:00 \_ strace -f
git-cvsimport -d :pserver:cvs@cvs.rulez.pl:/home/cv
kangur 30792 30791 2 02:55 pts/4 S+ 0:00 \_
/usr/bin/perl -w /usr/bin/git-cvsimport -d :pserver:cvs@c
kangur 30796 30792 18 02:55 pts/4 S+ 0:03 \_ cvsps
--norc --cvs-direct -u -A --root :pserver:cvs@c
file descriptors:
kangur@beta ~ $ ls -al /proc/30796/fd/
total 5
dr-x------ 2 kangur users 0 May 30 02:55 .
dr-xr-xr-x 3 kangur users 0 May 30 02:55 ..
lrwx------ 1 kangur users 64 May 30 02:57 0 -> /dev/pts/4
l-wx------ 1 kangur users 64 May 30 02:57 1 -> pipe:[429154]
lrwx------ 1 kangur users 64 May 30 02:55 2 -> /dev/pts/4
lrwx------ 1 kangur users 64 May 30 02:57 3 -> socket:[429155]
lrwx------ 1 kangur users 64 May 30 02:57 4 -> socket:[429155]
kangur@beta ~ $ ls -al /proc/30792/fd/
total 6
dr-x------ 2 kangur users 0 May 30 02:55 .
dr-xr-xr-x 3 kangur users 0 May 30 02:55 ..
lrwx------ 1 kangur users 64 May 30 02:57 0 -> /dev/pts/4
lrwx------ 1 kangur users 64 May 30 02:57 1 -> /dev/pts/4
lrwx------ 1 kangur users 64 May 30 02:55 2 -> /dev/pts/4
lr-x------ 1 kangur users 64 May 30 02:57 3 -> /home/kangur/.cvspass
lrwx------ 1 kangur users 64 May 30 02:57 4 -> socket:[429124]
lr-x------ 1 kangur users 64 May 30 02:57 5 -> pipe:[429154]
kangur@beta ~ $ ls -al /proc/30791/fd/
total 3
dr-x------ 2 kangur users 0 May 30 02:55 .
dr-xr-xr-x 3 kangur users 0 May 30 02:55 ..
lrwx------ 1 kangur users 64 May 30 02:58 0 -> /dev/pts/4
lrwx------ 1 kangur users 64 May 30 02:58 1 -> /dev/pts/4
lrwx------ 1 kangur users 64 May 30 02:55 2 -> /dev/pts/4
netstat:
tcp 0 0 beta.polcom.net:50743 netx.waw.pl:cvspserver
ESTABLISHED
tcp 0 0 beta.polcom.net:50744 netx.waw.pl:cvspserver
ESTABLISHED
I am using:
git version 1.3.3
cvsps version 2.1
What is going on?
Thanks in advance,
Grzegorz Kulewski
^ permalink raw reply
* Re: Bisects that are neither good nor bad
From: Linus Torvalds @ 2006-05-30 0:46 UTC (permalink / raw)
To: linux; +Cc: paul, git, linux-kernel
In-Reply-To: <20060529225632.7073.qmail@science.horizon.com>
On Mon, 29 May 2006, linux@horizon.com wrote:
>
> It's also worth repeating some advice from the manual:
>
> >> You can further cut down the number of trials if you know what part of
> >> the tree is involved in the problem you are tracking down, by giving
> >> paths parameters when you say bisect start, like this:
> >>
> >> $ git bisect start arch/i386 include/asm-i386
I'm not 100% sure this works - I think it has problems with the ending
condition because there always ends up being more commits in between when
the commit space isn't dense, so the "no commits left" thing doesn't
trigger. But "git bisect visualize" should hopefully help make it obvious
Linus
^ permalink raw reply
* Re: irc usage..
From: Linus Torvalds @ 2006-05-30 0:43 UTC (permalink / raw)
To: Donnie Berkholz
Cc: Martin Langhoff, Yann Dirson, Git Mailing List, Matthias Urlichs,
Johannes Schindelin
In-Reply-To: <447B7669.8050805@gentoo.org>
On Mon, 29 May 2006, Donnie Berkholz wrote:
>
> Looking closer, I see that the memory suckers do appear to be git, from
> dmesg:
>
> Out of Memory: Kill process 17230 (git-repack) score 97207 and children.
> Out of memory: Killed process 17231 (git-rev-list).
Sounds like you had the "git repack -a -d" thing in your cvsimport.
The current git rev-list should use only about a third of the memory of
the one you used, so hopefully you could just update your git version, and
then continue with the "git cvsimport" without having to start all over.
Linus
^ permalink raw reply
* Re: [PATCH 0/10] re-based and expanded tree-walker cleanup patches
From: Linus Torvalds @ 2006-05-30 0:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7virno79a7.fsf@assigned-by-dhcp.cox.net>
On Mon, 29 May 2006, Junio C Hamano wrote:
>
> Sorry for having you have done this -- last night I've merged
> the series without rebasing and have the result in "next". I'll
> compare to see if you have spotted my mismerges there tonight.
It was interesting. I cleaned up the series and switched the order of some
commits in my tree by doing first a "git rebase" and then cherry-picking
them into another branch, and using "git commit --amend" to fix up some of
the things I had missed.
Pretty powerful, although at one point I was wondering about having a "git
rebase" that could switch commits around or drop unwanted ones (ie let the
user edit the cherry-picking list before the actual rebase).
^ permalink raw reply
* Re: irc usage..
From: Martin Langhoff @ 2006-05-30 0:19 UTC (permalink / raw)
To: Donnie Berkholz
Cc: Linus Torvalds, Yann Dirson, Git Mailing List, Matthias Urlichs,
Johannes Schindelin
In-Reply-To: <447B7669.8050805@gentoo.org>
On 5/30/06, Donnie Berkholz <spyderous@gentoo.org> wrote:
> Looking closer, I see that the memory suckers do appear to be git, from
> dmesg:
>
> Out of Memory: Kill process 17230 (git-repack) score 97207 and children.
> Out of memory: Killed process 17231 (git-rev-list).
That would mean that you do have Linus' patch then. Grep cvsimport for
repack and remove the -a -- and consider using his recent patch to
rev-list.
My dmesg talks about an earlier cvs segfault. Nasty tree you have here
-- it's breaking all sorts of things... and teaching us a thing or two
about the import process.
> Committed patch 249100 (origin 2005-08-20 05:05:58)
Hmmm? How can you be at patch 249100 and still be a good year ahead of
me? Have you told cvsps to cut off old history?
Another thing I found is that this import uses a lot of $TMPDIR, so if
your TMPDIR is small, you'll hit all sorts of problems.
cheers,
martin
^ 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