* [PATCH 3/3] t9119: conditionally re-enable test depending on svn(1) version
From: Eric Wong @ 2008-08-05 7:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <1217921718-25011-1-git-send-email-normalperson@yhbt.net>
I've tested this with svn 1.4.4
This also adds quoting to make it work odd characters
in the trash path.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t9119-git-svn-info.sh | 69 +++++++++++++++++++++++++++-------------------
1 files changed, 40 insertions(+), 29 deletions(-)
diff --git a/t/t9119-git-svn-info.sh b/t/t9119-git-svn-info.sh
index 964011e..5fd36a1 100755
--- a/t/t9119-git-svn-info.sh
+++ b/t/t9119-git-svn-info.sh
@@ -5,8 +5,19 @@
test_description='git-svn info'
. ./lib-git-svn.sh
-say 'skipping svn-info test (has a race undiagnosed yet)'
-test_done
+
+set -e
+
+# Tested with: svn, version 1.4.4 (r25188)
+v=`svn --version | sed -n -e 's/^svn, version \(1\.4\.[0-9]\).*$/\1/p'`
+case $v in
+1.4.*)
+ ;;
+*)
+ say "skipping svn-info test (SVN version: $v not supported)"
+ test_done
+ ;;
+esac
ptouch() {
perl -w -e '
@@ -25,7 +36,7 @@ ptouch() {
' "`svn info $2 | grep '^Text Last Updated:'`" "$1"
}
-test_expect_success 'setup repository and import' "
+test_expect_success 'setup repository and import' '
mkdir info &&
cd info &&
echo FIRST > A &&
@@ -34,19 +45,19 @@ test_expect_success 'setup repository and import' "
mkdir directory &&
touch directory/.placeholder &&
ln -s directory symlink-directory &&
- svn import -m 'initial' . $svnrepo &&
+ svn import -m "initial" . "$svnrepo" &&
cd .. &&
mkdir gitwc &&
cd gitwc &&
- git-svn init $svnrepo &&
+ git-svn init "$svnrepo" &&
git-svn fetch &&
cd .. &&
- svn co $svnrepo svnwc &&
+ svn co "$svnrepo" svnwc &&
ptouch svnwc/file gitwc/file &&
ptouch svnwc/directory gitwc/directory &&
ptouch svnwc/symlink-file gitwc/symlink-file &&
ptouch svnwc/symlink-directory gitwc/symlink-directory
- "
+ '
test_expect_success 'info' "
(cd svnwc; svn info) > expected.info &&
@@ -55,7 +66,7 @@ test_expect_success 'info' "
"
test_expect_success 'info --url' '
- test $(cd gitwc; git-svn info --url) = $svnrepo
+ test "$(cd gitwc; git-svn info --url)" = "$svnrepo"
'
test_expect_success 'info .' "
@@ -65,7 +76,7 @@ test_expect_success 'info .' "
"
test_expect_success 'info --url .' '
- test $(cd gitwc; git-svn info --url .) = $svnrepo
+ test "$(cd gitwc; git-svn info --url .)" = "$svnrepo"
'
test_expect_success 'info file' "
@@ -75,7 +86,7 @@ test_expect_success 'info file' "
"
test_expect_success 'info --url file' '
- test $(cd gitwc; git-svn info --url file) = "$svnrepo/file"
+ test "$(cd gitwc; git-svn info --url file)" = "$svnrepo/file"
'
test_expect_success 'info directory' "
@@ -85,7 +96,7 @@ test_expect_success 'info directory' "
"
test_expect_success 'info --url directory' '
- test $(cd gitwc; git-svn info --url directory) = "$svnrepo/directory"
+ test "$(cd gitwc; git-svn info --url directory)" = "$svnrepo/directory"
'
test_expect_success 'info symlink-file' "
@@ -95,7 +106,7 @@ test_expect_success 'info symlink-file' "
"
test_expect_success 'info --url symlink-file' '
- test $(cd gitwc; git-svn info --url symlink-file) \
+ test "$(cd gitwc; git-svn info --url symlink-file)" \
= "$svnrepo/symlink-file"
'
@@ -108,7 +119,7 @@ test_expect_success 'info symlink-directory' "
"
test_expect_success 'info --url symlink-directory' '
- test $(cd gitwc; git-svn info --url symlink-directory) \
+ test "$(cd gitwc; git-svn info --url symlink-directory)" \
= "$svnrepo/symlink-directory"
'
@@ -128,7 +139,7 @@ test_expect_success 'info added-file' "
"
test_expect_success 'info --url added-file' '
- test $(cd gitwc; git-svn info --url added-file) \
+ test "$(cd gitwc; git-svn info --url added-file)" \
= "$svnrepo/added-file"
'
@@ -150,7 +161,7 @@ test_expect_success 'info added-directory' "
"
test_expect_success 'info --url added-directory' '
- test $(cd gitwc; git-svn info --url added-directory) \
+ test "$(cd gitwc; git-svn info --url added-directory)" \
= "$svnrepo/added-directory"
'
@@ -173,7 +184,7 @@ test_expect_success 'info added-symlink-file' "
"
test_expect_success 'info --url added-symlink-file' '
- test $(cd gitwc; git-svn info --url added-symlink-file) \
+ test "$(cd gitwc; git-svn info --url added-symlink-file)" \
= "$svnrepo/added-symlink-file"
'
@@ -196,7 +207,7 @@ test_expect_success 'info added-symlink-directory' "
"
test_expect_success 'info --url added-symlink-directory' '
- test $(cd gitwc; git-svn info --url added-symlink-directory) \
+ test "$(cd gitwc; git-svn info --url added-symlink-directory)" \
= "$svnrepo/added-symlink-directory"
'
@@ -222,7 +233,7 @@ test_expect_success 'info deleted-file' "
"
test_expect_success 'info --url file (deleted)' '
- test $(cd gitwc; git-svn info --url file) \
+ test "$(cd gitwc; git-svn info --url file)" \
= "$svnrepo/file"
'
@@ -243,7 +254,7 @@ test_expect_success 'info deleted-directory' "
"
test_expect_success 'info --url directory (deleted)' '
- test $(cd gitwc; git-svn info --url directory) \
+ test "$(cd gitwc; git-svn info --url directory)" \
= "$svnrepo/directory"
'
@@ -265,7 +276,7 @@ test_expect_success 'info deleted-symlink-file' "
"
test_expect_success 'info --url symlink-file (deleted)' '
- test $(cd gitwc; git-svn info --url symlink-file) \
+ test "$(cd gitwc; git-svn info --url symlink-file)" \
= "$svnrepo/symlink-file"
'
@@ -287,7 +298,7 @@ test_expect_success 'info deleted-symlink-directory' "
"
test_expect_success 'info --url symlink-directory (deleted)' '
- test $(cd gitwc; git-svn info --url symlink-directory) \
+ test "$(cd gitwc; git-svn info --url symlink-directory)" \
= "$svnrepo/symlink-directory"
'
@@ -304,8 +315,8 @@ test_expect_success 'info unknown-file' "
"
test_expect_success 'info --url unknown-file' '
- test -z $(cd gitwc; git-svn info --url unknown-file \
- 2> ../actual.info--url-unknown-file) &&
+ test -z "$(cd gitwc; git-svn info --url unknown-file \
+ 2> ../actual.info--url-unknown-file)" &&
git-diff expected.info-unknown-file actual.info--url-unknown-file
'
@@ -321,8 +332,8 @@ test_expect_success 'info unknown-directory' "
"
test_expect_success 'info --url unknown-directory' '
- test -z $(cd gitwc; git-svn info --url unknown-directory \
- 2> ../actual.info--url-unknown-directory) &&
+ test -z "$(cd gitwc; git-svn info --url unknown-directory \
+ 2> ../actual.info--url-unknown-directory)" &&
git-diff expected.info-unknown-directory \
actual.info--url-unknown-directory
'
@@ -344,8 +355,8 @@ test_expect_success 'info unknown-symlink-file' "
"
test_expect_success 'info --url unknown-symlink-file' '
- test -z $(cd gitwc; git-svn info --url unknown-symlink-file \
- 2> ../actual.info--url-unknown-symlink-file) &&
+ test -z "$(cd gitwc; git-svn info --url unknown-symlink-file \
+ 2> ../actual.info--url-unknown-symlink-file)" &&
git-diff expected.info-unknown-symlink-file \
actual.info--url-unknown-symlink-file
'
@@ -368,8 +379,8 @@ test_expect_success 'info unknown-symlink-directory' "
"
test_expect_success 'info --url unknown-symlink-directory' '
- test -z $(cd gitwc; git-svn info --url unknown-symlink-directory \
- 2> ../actual.info--url-unknown-symlink-directory) &&
+ test -z "$(cd gitwc; git-svn info --url unknown-symlink-directory \
+ 2> ../actual.info--url-unknown-symlink-directory)" &&
git-diff expected.info-unknown-symlink-directory \
actual.info--url-unknown-symlink-directory
'
--
1.6.0.rc1.69.g797ea
^ permalink raw reply related
* Re: [PATCH] git-p4: chdir now properly sets PWD environment variable in msysGit
From: Simon Hausmann @ 2008-08-05 8:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robert Blum, shausman, marius, hanwen, git
In-Reply-To: <7v7iaxu7i1.fsf@gitster.siamese.dyndns.org>
On Sunday 03 August 2008 23:13:42 Junio C Hamano wrote:
> "Robert Blum" <rob.blum@gmail.com> writes:
> > P4 on Windows expects the PWD environment variable to be set to the
> > current working dir, but os.chdir in python doesn't do that by default
>
> Missing full stop at the end of sentence aside, this comment makes me
> wonder if there is an optional way to have it set it, as opposed to the
> inconvenient way it behaves "by defualt". If there is none, I think your
> patch, even though it looks ugly, is the least evil approach. Another way
> might be to wrap callsites of system() by introducing a "run_p4" function,
> like:
>
> def run_p4(arg):
> os.environ['PWD'] = os.getcwd() if os.name == 'nt'
> return system(arg)
>
> > ---
> >
> > Pushing it out to the list since I'm not entirely sure who the git-p4
> > owner even is. CC'ed likely suspects for ownership ;)
>
> Thanks. I've been waiting for an Ack from somewhere or success reports
> from p4 users on Windows.
Acked-by: Simon Hausmann <simon@lst.de>
It may not be the prettiest solution, but I agree it needs to be solved :)
Simon
^ permalink raw reply
* Re: Not going beyond symbolic links
From: Johannes Schindelin @ 2008-08-05 11:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git, Petr Baudis, Shawn O. Pearce
In-Reply-To: <7vprooysst.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 4 Aug 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > However, please note that Junio's patch affects git-add, AFAIR, not
> > git-update-index.
>
> Really? I thought I added a test case to cover the plumbing as well...
Right, I missed that one. I kinda hoped that only porcelain is affected.
Ciao,
Dscho
^ permalink raw reply
* [TopGit PATCH] tg-info: pretty print dependencies
From: Bert Wesarg @ 2008-08-05 11:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: Bert Wesarg, git
Print one dependency per line in tg-info output.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
tg-info.sh | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/tg-info.sh b/tg-info.sh
index ce99809..9e09039 100644
--- a/tg-info.sh
+++ b/tg-info.sh
@@ -38,8 +38,13 @@ echo "Base: $base_rev"
branch_contains "$name" "$base_rev" ||
echo "Base is newer than head! Please run \`tg update\`."
-deps="$(git cat-file blob "$name:.topdeps")"
-echo "Depends: $deps"
+prefix="Depends:"
+prefixlen=${#prefix}
+git cat-file blob "$name:.topdeps" 2>/dev/null |
+ while read _dep; do
+ printf "%-*s %s\n" $prefixlen "$prefix" "$_dep"
+ prefix=""
+ done
depcheck="$(mktemp)"
needs_update "$name" >"$depcheck"
--
1.5.5.GIT
^ permalink raw reply related
* [Q] Finding the commit that removed a symbol?
From: Brian Foster @ 2008-08-05 11:43 UTC (permalink / raw)
To: Git Mailing List
I'm a bit puzzled as to how to do find a commit which
removed a symbol. This is not a ‘bisect’ per se (or at
least I don't think it is ?); I know exactly what I am
looking for, but am not quite sure how to find it.
I know that between tags A (older) and B (younger)
a certain symbol S, defined in file F, vanished.
A:F has S; B:F does not. (There are many commits
affecting F between A and B, albeit most don't involve
S per se.) S isn't mentioned in any commit comments,
else I could search the output of: git log A..B -- F
Actually, using gitk(1) — gitk A..B -- F — I've found
what I'm looking for, so I guess what I'm now wondering
is if there's a better/easier/faster(/non-GUI ?) way of
doing this? (My git-newbie-ness may be showing here!)
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
^ permalink raw reply
* Re: [Q] Finding the commit that removed a symbol?
From: Jonathan del Strother @ 2008-08-05 11:47 UTC (permalink / raw)
To: Brian Foster; +Cc: Git Mailing List
In-Reply-To: <200808051343.07370.brian.foster@innova-card.com>
On Tue, Aug 5, 2008 at 12:43 PM, Brian Foster
<brian.foster@innova-card.com> wrote:
>
> I'm a bit puzzled as to how to do find a commit which
> removed a symbol. This is not a 'bisect' per se (or at
> least I don't think it is ?); I know exactly what I am
> looking for, but am not quite sure how to find it.
>
> I know that between tags A (older) and B (younger)
> a certain symbol S, defined in file F, vanished.
> A:F has S; B:F does not. (There are many commits
> affecting F between A and B, albeit most don't involve
> S per se.) S isn't mentioned in any commit comments,
> else I could search the output of: git log A..B -- F
>
> Actually, using gitk(1) — gitk A..B -- F — I've found
> what I'm looking for, so I guess what I'm now wondering
> is if there's a better/easier/faster(/non-GUI ?) way of
> doing this? (My git-newbie-ness may be showing here!)
>
You probably want git log -S'MySymbol'
^ permalink raw reply
* Re: [Q] Finding the commit that removed a symbol?
From: Brian Foster @ 2008-08-05 12:00 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Git Mailing List
In-Reply-To: <57518fd10808050447h2df6da07vb001ed8862076992@mail.gmail.com>
On Tuesday 05 August 2008 13:47:35 Jonathan del Strother wrote:
>[ ... ]
> You probably want git log -S'MySymbol'
Jonathan,
Thanks! That did it, exactly (finding, in fact, only
two commits: The one that added the symbol, and the one
I was looking for, the one that removed it).
I was unwares of ‘-S’ because git-log(1) for v1.5.2.5
did not list it (albeit it seems to exist). Consulting
the v1.5.5 documentation, it's listed. Thanks to whoever
fixed/updated the documentation.
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
^ permalink raw reply
* Re: Not going beyond symbolic links
From: Dmitry Potapov @ 2008-08-05 12:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Johannes Schindelin, git, Petr Baudis,
Shawn O. Pearce
In-Reply-To: <7vej54xa80.fsf@gitster.siamese.dyndns.org>
On Mon, Aug 04, 2008 at 11:11:11PM -0700, Junio C Hamano wrote:
>
> The thing is, the "feature" is not very well supported, even without the
> fixes from last night. If you have a symlink "sym" that points at "dir"
> that has "file" in it, and if neither "sym" nor "dir/file" are tracked,
> you can "git add sym/file" to add it (I called it a bug).
Well, I actually used this feature less than a year ago and did not have
any problem with that. Not that it is very important for me now, but I had
makefiles in a separate build directory, and I used a symlink to move
building to a tmpfs partion, which sped up building slightly.
Obviously, if a symlink points to a directory inside of the repository
and then you use "git add sym/file", it is definitely a mistake. OTOH,
let's consider the following situation:
git init
mkdir newdir
touch newdir/foo
git add newdir/foo
git commit -m 'add foo'
mv newdir /tmp/
ln -s /tmp/newdir
touch newdir/bar
git add newdir/bar
git commit -m 'add bar'
git ls-files
And you can see:
newdir/bar
newdir/foo
Git does exactly what I want here!
Anyway, I more concern with performance impact of your patch. If it
is noticeable, then it would be nice to have an option to turn this
check off.
Dmitry
^ permalink raw reply
* Re: extracting to/cc addresses for stg mail
From: Karl Hasselström @ 2008-08-05 13:39 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: git
In-Reply-To: <200808011650.45915.bjorn.helgaas@hp.com>
On 2008-08-01 16:50:45 -0600, Bjorn Helgaas wrote:
> Is there a way to make stg pay attention to my "To:" lines in the
> patch description? Or another way to accomplish this?
It can't do it at the moment, but it should be easy to fix. In
stgit/commands/mail.py, the following lines
if options.auto:
extra_cc = __get_signers_list(descr)
else:
extra_cc = []
add the extra CC addresses. You could augment __get_signers_list to
return a tuple of to and cc addresses instead of just cc addresses,
pass those addesses to the same place extra_cc is fed now, and that's
it.
If you really hate Python, don't have time, etc., I can do it for you
(as long as you agree to test it) -- just ask -- but I try to take
every opportunity to get people to contribute patches. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 0/8] bash completion: more porcelain completions
From: Shawn O. Pearce @ 2008-08-05 14:29 UTC (permalink / raw)
To: Lee Marlow; +Cc: git
In-Reply-To: <1217915438-6838-1-git-send-email-lee.marlow@gmail.com>
Lee Marlow <lee.marlow@gmail.com> wrote:
> This adds basic long option completion for some common commands that I
> use, as well as stash name completion.
Entire series is good.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> Lee Marlow (8):
> bash completion: Add completion for 'git clone'
> bash completion: Add completion for 'git clean'
> bash completion: Add completion for 'git init'
> bash completion: Add completion for 'git revert'
> bash completion: More completions for 'git stash'
> bash completion: Add completion for 'git archive'
> bash completion: Add completion for 'git ls-files'
> bash completion: Add completion for 'git mv'
>
> contrib/completion/git-completion.bash | 143 +++++++++++++++++++++++++++++++-
> git-stash.sh | 2 +-
> 2 files changed, 143 insertions(+), 2 deletions(-)
>
--
Shawn.
^ permalink raw reply
* [PATCH] git-cvsimport.perl: Print "UNKNOWN LINE..." on stderr, not stdout.
From: Jim Meyering @ 2008-08-05 14:54 UTC (permalink / raw)
To: git list
Signed-off-by: Jim Meyering <meyering@redhat.com>
---
I'm used to filtering git-cvsimport's noisy stderr, but this
diagnostic appears on stdout. Looks like an oversight.
Now that I'm using cvsps-2.2b1, I see tons of these.
git-cvsimport.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index e2664ef..e439202 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -952,7 +952,7 @@ while (<CVS>) {
} elsif (/^-+$/) { # end of unknown-line processing
$state = 1;
} elsif ($state != 11) { # ignore stuff when skipping
- print "* UNKNOWN LINE * $_\n";
+ print STDERR "* UNKNOWN LINE * $_\n";
}
}
commit() if $branch and $state != 11;
--
1.6.0.rc1.36.g5ff70
^ permalink raw reply related
* [TopGit PATCH] tg-create.sh: fix help string
From: Bert Wesarg @ 2008-08-05 15:07 UTC (permalink / raw)
To: Petr Baudis, Petr Baudis; +Cc: Bert Wesarg, git
The help string of the tg-create command was not changed with the commit
"Change usage (-d ->arguments) <ab712f2ed92a6e451bf2d482b03d2559697bf100>".
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
tg-create.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tg-create.sh b/tg-create.sh
index d196e4f..5438deb 100644
--- a/tg-create.sh
+++ b/tg-create.sh
@@ -15,7 +15,7 @@ while [ -n "$1" ]; do
arg="$1"; shift
case "$arg" in
-*)
- echo "Usage: tg create [-d DEPS...] NAME" >&2
+ echo "Usage: tg create NAME [DEPS...]" >&2
exit 1;;
*)
if [ -z "$name" ]; then
--
tg: (24367cc..) t/fix-tg-create-help-string (depends on: master)
^ permalink raw reply related
* Re: [PATCH] git-cvsimport.perl: Print "UNKNOWN LINE..." on stderr, not stdout.
From: Jeff King @ 2008-08-05 15:28 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list
In-Reply-To: <87zlnro6kt.fsf@rho.meyering.net>
On Tue, Aug 05, 2008 at 04:54:42PM +0200, Jim Meyering wrote:
> I'm used to filtering git-cvsimport's noisy stderr, but this
> diagnostic appears on stdout. Looks like an oversight.
> Now that I'm using cvsps-2.2b1, I see tons of these.
There are a ton of things that go to stdout:
$ perl -ne '/print (\S+)/ && print "$1\n" git-cvsimport.perl |
grep '^#' | wc -l
18
though many are only activated via "-v". Maybe it is worth putting all
of them to stderr? I really don't see why cvsimport should ever produce
any output on stdout.
-Peff
^ permalink raw reply
* Re: [PATCH] git-cvsimport.perl: Print "UNKNOWN LINE..." on stderr, not stdout.
From: Jeff King @ 2008-08-05 15:35 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list
In-Reply-To: <20080805152836.GB21901@sigill.intra.peff.net>
On Tue, Aug 05, 2008 at 11:28:36AM -0400, Jeff King wrote:
> $ perl -ne '/print (\S+)/ && print "$1\n" git-cvsimport.perl |
> grep '^#' | wc -l
Urgh, somehow I managed to get a typo into my cut and paste. It should be
grep '^"'
(i.e., we are getting rid of "print STDERR" and "print $fh"; this is
admittedly not very robust, but I just wanted an approximation of how
many there were).
-Peff
^ permalink raw reply
* Re: [PATCH] git-cvsimport.perl: Print "UNKNOWN LINE..." on stderr, not stdout.
From: Jim Meyering @ 2008-08-05 15:44 UTC (permalink / raw)
To: Jeff King; +Cc: git list
In-Reply-To: <20080805152836.GB21901@sigill.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Tue, Aug 05, 2008 at 04:54:42PM +0200, Jim Meyering wrote:
>
>> I'm used to filtering git-cvsimport's noisy stderr, but this
>> diagnostic appears on stdout. Looks like an oversight.
>> Now that I'm using cvsps-2.2b1, I see tons of these.
>
> There are a ton of things that go to stdout:
>
> $ perl -ne '/print (\S+)/ && print "$1\n" git-cvsimport.perl |
> grep '^#' | wc -l
> 18
>
> though many are only activated via "-v". Maybe it is worth putting all
> of them to stderr? I really don't see why cvsimport should ever produce
> any output on stdout.
A quick scan (post-patch)
$ grep 'print ' git-cvsimport.perl|grep -vE 'STDERR|opt_v'
print $f "$_=$conv_author_name{$_} <$conv_author_email{$_}>\n";
print $fh $line;
print $fh $buf;
print $cvspsfh $_;
print $fh
print "SKIPPING $fn v $rev\n";
suggests that if you don't count the "SKIPPING..." diagnostic you'd get
for each "-S REGEXP"-skipped name, the "UNKNOWN LINE" diagnostic is the
only one that goes to stdout but that is not protected by an $opt_v guard.
^ permalink raw reply
* [BUG] git diff-tree --stdin doesn't accept two trees
From: Karl Hasselström @ 2008-08-05 16:48 UTC (permalink / raw)
To: git
I'm trying to use diff-tree --stdin to diff several trees in one go.
But I just get error messages when I feed it two space-separated trees
(one commit works fine):
$ echo $(git rev-parse HEAD^{tree}) $(git rev-parse HEAD^^{tree}) | git diff-tree -p --stdin
error: Object 7bfd9971f77438858e412be0219ec78afb3ca46f not a commit
This is at odds with the documentation:
--stdin::
When '--stdin' is specified, the command does not take
<tree-ish> arguments from the command line. Instead, it
reads either one <commit> or a pair of <tree-ish>
separated with a single space from its standard input.
I tried reading the code to figure out what's wrong, and as far as I
can tell the code to do this is there, but seems to be protected by
logic that aborts everything unless the whole input line is a valid
commit. Or maybe I'm just confused ...
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] Documentation: typos / spelling fixes
From: Mike Ralphson @ 2008-08-05 16:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Mike Ralphson
Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
---
Documentation/RelNotes-1.6.0.txt | 2 +-
Documentation/config.txt | 2 +-
Documentation/git-cat-file.txt | 2 +-
Documentation/git-for-each-ref.txt | 2 +-
Documentation/git-mergetool.txt | 2 +-
Documentation/git-svn.txt | 4 ++--
Documentation/merge-config.txt | 4 ++--
7 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/RelNotes-1.6.0.txt b/Documentation/RelNotes-1.6.0.txt
index 2542cf5..614a3be 100644
--- a/Documentation/RelNotes-1.6.0.txt
+++ b/Documentation/RelNotes-1.6.0.txt
@@ -187,7 +187,7 @@ Updates since v1.5.6
command internally uses rev-parse to interpret its arguments.
* git-rev-list learned --children option to show child commits it
- encountered during the traversal, instead of shoing parent commits.
+ encountered during the traversal, instead of showing parent commits.
* git-send-mail can talk not just over SSL but over TLS now.
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 61c3760..b8ec01c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -693,7 +693,7 @@ gitcvs.usecrlfattr
files to determine the '-k' modes to use. If `crlf` is set,
the '-k' mode will be left blank, so cvs clients will
treat it as text. If `crlf` is explicitly unset, the file
- will be set with '-kb' mode, which supresses any newline munging
+ will be set with '-kb' mode, which suppresses any newline munging
the client might otherwise do. If `crlf` is not specified,
then 'gitcvs.allbinary' is used. See linkgit:gitattributes[5].
diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt
index d35e8a0..668f697 100644
--- a/Documentation/git-cat-file.txt
+++ b/Documentation/git-cat-file.txt
@@ -81,7 +81,7 @@ object specified on stdin:
------------
If '--batch-check' is specified, output of the following form is printed for
-each object specified fon stdin:
+each object specified on stdin:
------------
<sha1> SP <type> SP <size> LF
diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
index 609f949..eae6c0e 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -49,7 +49,7 @@ OPTIONS
<pattern>...::
If one or more patterns are given, only refs are shown that
- match againt at least one pattern, either using fnmatch(3) or
+ match against at least one pattern, either using fnmatch(3) or
literally, in the latter case matching completely or from the
beginning up to a slash.
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 31570b1..e0b2703 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -40,7 +40,7 @@ tool is available in PATH.
+
Instead of running one of the known merge tool programs
'git-mergetool' can be customized to run an alternative program
-by specifying the command line to invoke in a configration
+by specifying the command line to invoke in a configuration
variable `mergetool.<tool>.cmd`.
+
When 'git-mergetool' is invoked with this tool (either through the
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index f230125..773ae96 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -13,7 +13,7 @@ DESCRIPTION
-----------
'git-svn' is a simple conduit for changesets between Subversion and git.
It provides a bidirectional flow of changes between a Subversion and a git
-respository.
+repository.
'git-svn' can track a single Subversion branch simply by using a
URL to the branch, follow branches laid out in the Subversion recommended
@@ -209,7 +209,7 @@ Any other arguments are passed directly to 'git-log'
Recursively finds the svn:ignore property on directories and
creates matching .gitignore files. The resulting files are staged to
be committed, but are not committed. Use -r/--revision to refer to a
- specfic revision.
+ specific revision.
'show-ignore'::
Recursively finds and lists the svn:ignore property on
diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt
index 48ce747..00277e0 100644
--- a/Documentation/merge-config.txt
+++ b/Documentation/merge-config.txt
@@ -1,5 +1,5 @@
merge.stat::
- Whether to print the diffstat berween ORIG_HEAD and merge result
+ Whether to print the diffstat between ORIG_HEAD and merge result
at the end of the merge. True by default.
merge.log::
@@ -16,7 +16,7 @@ merge.tool::
linkgit:git-mergetool[1]. Valid built-in values are: "kdiff3",
"tkdiff", "meld", "xxdiff", "emerge", "vimdiff", "gvimdiff", and
"opendiff". Any other value is treated is custom merge tool
- and there must be a corresponing mergetool.<tool>.cmd option.
+ and there must be a corresponding mergetool.<tool>.cmd option.
merge.verbosity::
Controls the amount of output shown by the recursive merge
--
1.6.0.rc0.dirty
^ permalink raw reply related
* Re: Not going beyond symbolic links
From: Linus Torvalds @ 2008-08-05 17:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, Petr Baudis, Shawn O. Pearce
In-Reply-To: <7vej54xa80.fsf@gitster.siamese.dyndns.org>
On Mon, 4 Aug 2008, Junio C Hamano wrote:
>
> While I admit that I have managed a large directory split across
> partitions grafted via symlinks in pre-git days myself, ever since you
> started "tracking" symbolic links with 8ae0a8c (git and symlinks as
> tracked content, 2005-05-05), you have pretty much been committed to
> "track" symbolic links.
Yes, but my point is:
- IF the cost is exorbitant (which was my question that triggered this:
it sure as h*ll _would_ have been too high back in the days of the
original symlink-matching code) ...
- ... then there really are valid cases that say that we could just call
it a feature.
That's really my whole argument. Saying that "ok, we will assume that
existing paths that git already knows about are stable" is not really an
odd feature. It's one we have lived with for years, and it's one that is
actually pretty dang trivial to work with. Yes, it can cause unexpected
behaviour, but if you hit it, that unexpected behavior is actually not
_that_ hard to work around.
This is all I'm arguing for. People claim that there are 'correctness'
issues. I say that 'performance issues' are important, and we can and we
_should_ take performance issues very seriously. So seriously that we'll
make performance a _feature_ if required.
Linus
^ permalink raw reply
* Re: extracting to/cc addresses for stg mail
From: Bjorn Helgaas @ 2008-08-05 17:43 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080805133922.GB29499@diana.vm.bytemark.co.uk>
On Tuesday 05 August 2008 07:39:22 am Karl Hasselström wrote:
> On 2008-08-01 16:50:45 -0600, Bjorn Helgaas wrote:
>
> > Is there a way to make stg pay attention to my "To:" lines in the
> > patch description? Or another way to accomplish this?
>
> It can't do it at the moment, but it should be easy to fix. In
> stgit/commands/mail.py, the following lines
>
> if options.auto:
> extra_cc = __get_signers_list(descr)
> else:
> extra_cc = []
>
> add the extra CC addresses. You could augment __get_signers_list to
> return a tuple of to and cc addresses instead of just cc addresses,
> pass those addesses to the same place extra_cc is fed now, and that's
> it.
>
> If you really hate Python, don't have time, etc., I can do it for you
> (as long as you agree to test it) -- just ask -- but I try to take
> every opportunity to get people to contribute patches. :-)
Thanks for the hints. I'll take a look at it. It'll take me a while,
but it's a good excuse to try to learn a little Python.
Bjorn
^ permalink raw reply
* Best of open source developer tools
From: Johannes Schindelin @ 2008-08-05 17:45 UTC (permalink / raw)
To: git
To those who haven't seen it yet,
http://www.infoworld.com/slideshow/2008/08/166-best_of_open_so-3.html
Ciao,
Dscho
^ permalink raw reply
* Re: Best of open source developer tools
From: Scott Chacon @ 2008-08-05 17:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0808051844550.26154@racer>
Also somewhat interesting, there was some discussion about having
Prototype as a project on the git-scm.com frontpage. It is also
listed as one of the best open source dev tools:
http://www.infoworld.com/slideshow/2008/08/166-best_of_open_so-8.html
Scott
On Tue, Aug 5, 2008 at 10:45 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> To those who haven't seen it yet,
>
> http://www.infoworld.com/slideshow/2008/08/166-best_of_open_so-3.html
>
> Ciao,
> Dscho
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] Teach fsck and prune that tmp_obj_ file names may not be 14 bytes long
From: Brandon Casey @ 2008-08-05 18:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Shawn O. Pearce
As Shawn pointed out, not all temporary file creation routines can
ensure that the generated temporary file is of a certain length.
e.g. Java's createTempFile(prefix, suffix). So just depend on the
prefix 'tmp_obj_' for detection.
Update prune, and fix the "fix" introduced by a08c53a1 :)
Signed-off-by: Brandon "appendixless" Casey <casey@nrlssc.navy.mil>
---
builtin-fsck.c | 2 +-
builtin-prune.c | 9 ++++-----
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/builtin-fsck.c b/builtin-fsck.c
index 6eb7da8..d3f3de9 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -385,7 +385,7 @@ static void fsck_dir(int i, char *path)
add_sha1_list(sha1, DIRENT_SORT_HINT(de));
continue;
}
- if (prefixcmp(de->d_name, "tmp_obj_"))
+ if (!prefixcmp(de->d_name, "tmp_obj_"))
continue;
fprintf(stderr, "bad sha1 file: %s/%s\n", path, de->d_name);
}
diff --git a/builtin-prune.c b/builtin-prune.c
index 947de8c..c767a0a 100644
--- a/builtin-prune.c
+++ b/builtin-prune.c
@@ -69,11 +69,6 @@ static int prune_dir(int i, char *path)
if (de->d_name[0] != '.')
break;
continue;
- case 14:
- if (prefixcmp(de->d_name, "tmp_obj_"))
- break;
- prune_tmp_object(path, de->d_name);
- continue;
case 38:
sprintf(name, "%02x", i);
memcpy(name+2, de->d_name, len+1);
@@ -90,6 +85,10 @@ static int prune_dir(int i, char *path)
prune_object(path, de->d_name, sha1);
continue;
}
+ if (!prefixcmp(de->d_name, "tmp_obj_")) {
+ prune_tmp_object(path, de->d_name);
+ continue;
+ }
fprintf(stderr, "bad sha1 file: %s/%s\n", path, de->d_name);
}
if (!show_only)
--
1.5.6.2
^ permalink raw reply related
* Re: [PATCH 0/8] bash completion: more porcelain completions
From: Junio C Hamano @ 2008-08-05 18:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Lee Marlow, git
In-Reply-To: <20080805142919.GA27295@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Lee Marlow <lee.marlow@gmail.com> wrote:
>> This adds basic long option completion for some common commands that I
>> use, as well as stash name completion.
>
> Entire series is good.
>
> Acked-by: Shawn O. Pearce <spearce@spearce.org>
Have you looked at the last one [PATCH 8/8]? I do not seem to have it.
>> Lee Marlow (8):
>> bash completion: Add completion for 'git clone'
>> bash completion: Add completion for 'git clean'
>> bash completion: Add completion for 'git init'
>> bash completion: Add completion for 'git revert'
>> bash completion: More completions for 'git stash'
>> bash completion: Add completion for 'git archive'
>> bash completion: Add completion for 'git ls-files'
>> bash completion: Add completion for 'git mv'
>>
>> contrib/completion/git-completion.bash | 143 +++++++++++++++++++++++++++++++-
>> git-stash.sh | 2 +-
>> 2 files changed, 143 insertions(+), 2 deletions(-)
>>
>
> --
> Shawn.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Teach fsck and prune that tmp_obj_ file names may not be 14 bytes long
From: Shawn O. Pearce @ 2008-08-05 19:07 UTC (permalink / raw)
To: Brandon Casey; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <I1vUBkF5DO9PiWvc0SRIfOHigaNX9d2kNHLqpAUceLenX-_BWPAliQ@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> wrote:
> As Shawn pointed out, not all temporary file creation routines can
> ensure that the generated temporary file is of a certain length.
> e.g. Java's createTempFile(prefix, suffix). So just depend on the
> prefix 'tmp_obj_' for detection.
>
> Update prune, and fix the "fix" introduced by a08c53a1 :)
Arrrrgh! :-)
Thanks for cleaning up my mess.
> Signed-off-by: Brandon "appendixless" Casey <casey@nrlssc.navy.mil>
> ---
> builtin-fsck.c | 2 +-
> builtin-prune.c | 9 ++++-----
> 2 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/builtin-fsck.c b/builtin-fsck.c
> index 6eb7da8..d3f3de9 100644
> --- a/builtin-fsck.c
> +++ b/builtin-fsck.c
> @@ -385,7 +385,7 @@ static void fsck_dir(int i, char *path)
> add_sha1_list(sha1, DIRENT_SORT_HINT(de));
> continue;
> }
> - if (prefixcmp(de->d_name, "tmp_obj_"))
> + if (!prefixcmp(de->d_name, "tmp_obj_"))
> continue;
> fprintf(stderr, "bad sha1 file: %s/%s\n", path, de->d_name);
> }
> diff --git a/builtin-prune.c b/builtin-prune.c
> index 947de8c..c767a0a 100644
> --- a/builtin-prune.c
> +++ b/builtin-prune.c
> @@ -69,11 +69,6 @@ static int prune_dir(int i, char *path)
> if (de->d_name[0] != '.')
> break;
> continue;
> - case 14:
> - if (prefixcmp(de->d_name, "tmp_obj_"))
> - break;
> - prune_tmp_object(path, de->d_name);
> - continue;
> case 38:
> sprintf(name, "%02x", i);
> memcpy(name+2, de->d_name, len+1);
> @@ -90,6 +85,10 @@ static int prune_dir(int i, char *path)
> prune_object(path, de->d_name, sha1);
> continue;
> }
> + if (!prefixcmp(de->d_name, "tmp_obj_")) {
> + prune_tmp_object(path, de->d_name);
> + continue;
> + }
> fprintf(stderr, "bad sha1 file: %s/%s\n", path, de->d_name);
> }
> if (!show_only)
> --
> 1.5.6.2
>
--
Shawn.
^ permalink raw reply
* [PATCH 8/8] bash completion: Add completion for 'git mv'
From: Shawn O. Pearce @ 2008-08-05 19:08 UTC (permalink / raw)
To: Junio C Hamano, git
[-- Attachment #1: Type: text/plain, Size: 33 bytes --]
The missing patch 8.
--
Shawn.
[-- Attachment #2: Type: message/rfc822, Size: 3807 bytes --]
From: Lee Marlow <lee.marlow@gmail.com>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: git@vger.kernel.org, Lee Marlow <lee.marlow@gmail.com>
Subject: [PATCH 8/8] bash completion: Add completion for 'git mv'
Date: Mon, 4 Aug 2008 23:50:38 -0600
Message-ID: <1217915438-6838-9-git-send-email-lee.marlow@gmail.com>
Added completions for all long options specified in the docs
--dry-run
Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
---
contrib/completion/git-completion.bash | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 936cd35..57b8c0f 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -983,6 +983,18 @@ _git_merge_base ()
__gitcomp "$(__git_refs)"
}
+_git_mv ()
+{
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --*)
+ __gitcomp "--dry-run"
+ return
+ ;;
+ esac
+ COMPREPLY=()
+}
+
_git_name_rev ()
{
__gitcomp "--tags --all --stdin"
@@ -1615,6 +1627,7 @@ _git ()
ls-tree) _git_ls_tree ;;
merge) _git_merge;;
merge-base) _git_merge_base ;;
+ mv) _git_mv ;;
name-rev) _git_name_rev ;;
pull) _git_pull ;;
push) _git_push ;;
--
1.6.0.rc1.48.g2b6032
^ 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