* Re: [PATCH] git status: print files under untracked dir if -a is given
From: Yasushi SHOJI @ 2006-05-30 12:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyir26v4.fsf@assigned-by-dhcp.cox.net>
Hi Junio,
At Tue, 30 May 2006 02:34:55 -0700,
Junio C Hamano wrote:
>
> Yasushi SHOJI <yashi@atmark-techno.com> writes:
>
> > git status: print files under untracked dir if -a is given
> >
> > git status (git-commit.sh) currently doesn't show files under
> > untracked directory. this is inconvenient when adding many files
> > under new directory.
> >
> > this patch change its behavior to show files under untracked directory
> > if option --all is given.
> >
> > Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
>
> I do not quite understand your rationale behind linking -a and
> "show untracked" behaviour. In many cases, after modifying
> multiple files "commit -a" is the preferred way to make commits
> for people who keep their tree clean (meaning, they do not leave
> unrelated changes to their working tree files), and I suspect
> your change would clutter their commit log buffer with unrelated
> files they did not ask to see.
I assumed "--all" to mean "every single file under a working dir
except ignored". so I thought users of "commit -a" wouldn't mind to
see files under untracked dir.
but I was wrong. man page clearly states that "... new files you have
not told git about are not affected."
# I admit I haven't used -a with commit because of my
# misunderstanding. it's nice to know the option is much safer than I
# expected.
> At least this would make things somewhat unpleasant for me to
> use, since I do "commit -a" often and I have my random notes
> files under ./+trash subdirectory of the main project (yes, I
> know I could add /+trash to .gitignore).
I wasn't expecting that usage.
> We have something different but perhaps related by Matthias
> Lederhofer to add "git status --untracked" since you did this
> patch.
>
> commit 443f8338b9e248353a7095a1096684f1ed106c66
> Author: Matthias Lederhofer <matled@gmx.net>
> Date: Mon May 22 23:02:06 2006 +0200
>
> Does it solve your problem?
yes, it perfectly does.
thanks,
--
yashi
^ permalink raw reply
* [PATCH] cg-status: fix detection of dissappeared files
From: Jonas Fonseca @ 2006-05-30 12:48 UTC (permalink / raw)
To: Petr Baudis, git
fatal: ambiguous argument 'manual.txt': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
diff --git a/cg-status b/cg-status
index e2f97dd..aee5ff0 100755
--- a/cg-status
+++ b/cg-status
@@ -239,7 +239,7 @@ if [ "$workstatus" ]; then
git-diff-index HEAD -- "${basepath:-.}" | cut -f5- -d' ' |
while IFS=$'\t' read -r mode file; do
if [ "$mode" = D ]; then
- [ "$(git-diff-files "$file")" ] && mode=!
+ [ "$(git-diff-files -- "$file")" ] && mode=!
elif [ "$mode" = M ] && [ "$commitignore" ]; then
fgrep -qx "$file" "$_git/commit-ignore" && mode=m
fi
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH] git status: print files under untracked dir if -a is given
From: Junio C Hamano @ 2006-05-30 9:34 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: git
In-Reply-To: <87slmrdhe6.wl@mail2.atmark-techno.com>
Yasushi SHOJI <yashi@atmark-techno.com> writes:
> git status: print files under untracked dir if -a is given
>
> git status (git-commit.sh) currently doesn't show files under
> untracked directory. this is inconvenient when adding many files
> under new directory.
>
> this patch change its behavior to show files under untracked directory
> if option --all is given.
>
> Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
I do not quite understand your rationale behind linking -a and
"show untracked" behaviour. In many cases, after modifying
multiple files "commit -a" is the preferred way to make commits
for people who keep their tree clean (meaning, they do not leave
unrelated changes to their working tree files), and I suspect
your change would clutter their commit log buffer with unrelated
files they did not ask to see.
At least this would make things somewhat unpleasant for me to
use, since I do "commit -a" often and I have my random notes
files under ./+trash subdirectory of the main project (yes, I
know I could add /+trash to .gitignore).
We have something different but perhaps related by Matthias
Lederhofer to add "git status --untracked" since you did this
patch.
commit 443f8338b9e248353a7095a1096684f1ed106c66
Author: Matthias Lederhofer <matled@gmx.net>
Date: Mon May 22 23:02:06 2006 +0200
Does it solve your problem?
^ permalink raw reply
* Re: [RFC] git commit --branch
From: Junio C Hamano @ 2006-05-30 9:12 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060529202851.GE14325@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> Allow to commit to another branch and creating a merge in the current branch.
>
> Sometimes it is neccessary to have some local modifications in the tree
> in order to test it and work with it. With this patch you can have
> one working tree which combines several topic branches in order to
> develop and test your changes. When your changes are ready, you can
> commit them to the appropriate topic branch.
>
> With the --branch option, the commit will automatically be rebased to
> that branch. The original tree will then be commited to your working
> branch as a merge.
>
> ---
>
> Perhaps something like this can even be integrated into the extended
> branch configuration which is currently under discussion.
> It may make sense to have one branch which always contains a merge
> of a selected set of other branches and having a default branch
> for new commits.
I think this was discussed in the past and I appreciate what you
are trying to do. My understanding of the situation your patch
is trying to improve is this:
- you have done a few topics and you are ready to test;
- you pulled the topics into your test branch and have found
problems;
- you made changes while still on the test branch (otherwise
you wouldn't be able to test the "fix") and it seems to work
OK;
- what now?
And your approach is to backport the fix to its original topic
and then re-pull the topic onto the test branch.
While I think that is _one_ valid workflow, I am not convinced
that is _the_ best workflow. What Johannes suggested would
equally work fine, and honestly speaking probably is a better
discipline. You carry the fix in your working tree back to its
original topic and make a commit, without pulling the topic onto
the test branch immediately. This has two advantages:
- With your workflow, you will have a merge commit onto the
testing branch immediately when you commit this fix to the
original topic. But often when I encounter this situation,
after moving to the topic to backport the fix to it, I find
myself reviewing what is in the topic and making other
changes to the topic. Johannes's workflow feels more natural
to me from this aspect -- I take the fix I discovered while
on the testing branch to the relevant topic to fix it. I may
or may not make the commit only with that fix (the first
commit I make after switching the branches from testing to
the topic may contain more than that fix), and after I make
one commit, I may keep working on the topic a bit more before
I decide it is a good time to test the whole thing again (to
pull the topic into testing). I do not necessarily want that
extra merge immediately in the test branch.
- A topic branch should be testable alone; if the changes near
the tip of your topic depends on other topic (or more recent
mainline than where the topic forked), then I think you
shouldn't hesitate to pull in the other branch into the topic
to keep it buildable and testable. And your commit should be
made after testing your changes; with your workflow, you have
only tested the change in the context of the testing branch,
not the topic branch your "primary" commit is on, even though
that commit will be the source of eventual graduation to the
mainline. With Johannes's workflow, you first carry the
change to the topic, so you have a chance to test it before
making the commit (if you are not disciplined, you can make
the commit without testing after switching branches, but the
point is it gives people an option to test things before they
make a commit if they wanted to).
^ permalink raw reply
* [PATCH] git status: print files under untracked dir if -a is given
From: Yasushi SHOJI @ 2006-05-30 8:46 UTC (permalink / raw)
To: git; +Cc: tetsuya
git status: print files under untracked dir if -a is given
git status (git-commit.sh) currently doesn't show files under
untracked directory. this is inconvenient when adding many files
under new directory.
this patch change its behavior to show files under untracked directory
if option --all is given.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
---
3d3fa8f19c7d9b03b1a6e510970633ec8be7adac
git-commit.sh | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
3d3fa8f19c7d9b03b1a6e510970633ec8be7adac
diff --git a/git-commit.sh b/git-commit.sh
index 6ef1a9d..0cde305 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -134,13 +134,18 @@ #'
report "Changed but not updated" \
"use git-update-index to mark for commit"
+ if test -z "$all"
+ then
+ directory_opt="--directory"
+ fi
+
if test -f "$GIT_DIR/info/exclude"
then
- git-ls-files -z --others --directory \
+ git-ls-files -z --others $directory_opt \
--exclude-from="$GIT_DIR/info/exclude" \
--exclude-per-directory=.gitignore
else
- git-ls-files -z --others --directory \
+ git-ls-files -z --others $directory_opt \
--exclude-per-directory=.gitignore
fi |
perl -e '$/ = "\0";
--
1.3.3.g70f7
^ permalink raw reply related
* Re: [PATCH 4/4] Add a basic test case for git send-email, and fix some real bugs discovered.
From: Ryan Anderson @ 2006-05-30 8:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ryan Anderson, git
In-Reply-To: <7v8xok3vhj.fsf@assigned-by-dhcp.cox.net>
On Mon, May 29, 2006 at 10:57:44PM -0700, Junio C Hamano wrote:
> 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?
I apparently screwed this patch up (and I think I lost it, in the
process.)
Let me reconstruct, I fixed the problems in a different way (I reworked
unique_email_address(@) into unique_email_address($@), to pass a flag
stating whether to returned the cleaned email address or not, that
should come in a few minutes.)
^ permalink raw reply
* 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
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