* Re: Warning: cvsexportcommit considered dangerous
From: Alex Bennee @ 2007-11-15 11:59 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Johannes Schindelin, Steffen Prohaska, Git Mailing List
In-Reply-To: <200711050005.28561.robin.rosenberg.lists@dewire.com>
On Mon, 2007-11-05 at 00:05 +0100, Robin Rosenberg wrote:
> söndag 04 november 2007 skrev Johannes Schindelin:
> > Hi,
> > On Sun, 4 Nov 2007, Steffen Prohaska wrote:
> > > On Nov 4, 2007, at 5:41 PM, Johannes Schindelin wrote:
> > > > ever since the up-to-date check was changed to use just one call to
> > > > "cvs status", a bug was present. Now cvsexportcommit expects "cvs
> > > > status" to return the results in the same order as the file names were
> > > > passed.
> > > I do not know why it wasn't applied. I forgot re-checking after my
> > > vacation.
I think at the time it was felt the speed hit was too great on large
trees. Although my view still is we should always go for correctness
over speed.
> > It slipped by me, because of holiday, too. (I was on my well needed
> > holiday then.)
> >
> > But that patch really seems like a step back to me. The line "File: ...
> > Status: ..." should be parsable enough to fix the bug properly, instead of
> > undoing the optimisation.
> Unfortunately it's not that easy to parse. It *can* be done by looking at the
> repository path, and the CVS/Root etc, but it's not nice.
I also worry about corner cases in parsing code, especially if you have
to start poking around in CVS/Root files. Another (ugly) method could be
a two pass attempt, falling back to an individual status call if the
"optimized" version isn't sure.
> > AFAICS Robin replied with a "let's see if a proper fix materialises", and
> > I kind of hope that it will materialise soon.
I've not had another go at fixing this mainly due to being too busy. The
current patch works for me.
> Still hoping :). BTW, wouldn't this err on the right side anyway, i.e. if an
> existing file was not up to date and was wrongly thought to not exist or a new
> file was thought to be up-to-date, I would get an error and would not be able
> to commit. I've never seen it though and I always have a clean CVS checkout
> so the potential bug seems unlikely to me.
It's not just new files that can break (btw another fix has gone in to
ensure directories are added to CVS trees in order).
--
Alex, homepage: http://www.bennee.com/~alex/
Nothing in life is to be feared. It is only to be understood.
^ permalink raw reply
* Re: [PATCH v2] Bisect reset: remove bisect refs that may have been packed.
From: Johannes Schindelin @ 2007-11-15 12:10 UTC (permalink / raw)
To: Jeff King
Cc: Shawn O. Pearce, Johannes Sixt, Junio C Hamano, Christian Couder,
git
In-Reply-To: <20071115085259.GA30913@sigill.intra.peff.net>
Hi,
On Thu, 15 Nov 2007, Jeff King wrote:
> On Thu, Nov 15, 2007 at 03:49:34AM -0500, Shawn O. Pearce wrote:
>
> > What's this obsession with whitespace in refnames? Twice in like
> > two days people are talking about whitespace in refnames.
>
> I even had Junio convinced at one point!
>
> I am not actually creating such refs, but I think my brain was still
> fried from the URL encoding discussion, and I was overly paranoid about
> spaces.
Yeah, I'm really sorry I started that. It was meant to do good, but did
bad. Oh, well. The road to hell is paved with good intentions.
Ciao,
Dscho
^ permalink raw reply
* Re: How to change a submodue as a subdirectory?
From: Johannes Schindelin @ 2007-11-15 12:28 UTC (permalink / raw)
To: Ping Yin; +Cc: Alex Riesen, Git Mailing List
In-Reply-To: <46dff0320711150014x4a35975eqc53ef1fce7d40b18@mail.gmail.com>
Hi,
On Thu, 15 Nov 2007, Ping Yin wrote:
> On Nov 15, 2007 2:16 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Provided you do not kill the repository of the submodule (you have some
> > public repo for that, right?) you will not lose anything, since the
> > history of the superproject has pointers to the submodule.
> >
> > But I guess that you want something different... You probably want to
> > rewrite history as if the submodule had not been a submodule at all,
> > right?
>
> Yeah, this actually what i want. Now i find a way:
If this works for you, I am all the more happy for you. I thought that
you wanted to be able to go to a certain revision and get the same working
directory/directories. (But that is not what you get...)
> 1. move submodule subB outside
> mv subB /newpath/to/subB
> git-commit subB
Strictly speaking, you do not have to move it outside.
> 2. git-filter-branch to rename all files in subA repository to subB
> directory (say subB/subB).
>
> cd newpath/to/subB &&
> git filter-branch --index-filter \
> 'git ls-files -s | sed "s-\t-&subB/-" |
> GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
> git update-index --index-info &&
> mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD
No need to play games with GIT_INDEX_FILE, as far as I can tell.
> 3. in directory of super project superA, git-fetch repository subB to
> branch subB
> cd path/to/superA && git-fetch /newpath/to/subB master:subB
If you plan to do away with subB, you do not need to specify it... Just
use FETCH_HEAD, directly after the fetch.
> 4. git-cherry-pick each commit (except the root commit) of branch
> subB to the super project superA
> git-cherry HEAD subB | awk '{print $2}' | sed -n '2,$ p' | while
> read name; do git cherry-pick $name; done
The git-cherry call is not really necessary, right? The two repos have no
common history (not even common patches).
Besides, I think that what you did is just a complicated way of doing a
rebase.
But be aware that checking out older versions of the superproject will
still have the submodule!
Ciao,
Dscho
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Johannes Schindelin @ 2007-11-15 12:44 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Junio C Hamano, Sergei Organov, Matthieu Moy, Bill Lear,
Jan Wielemaker, git
In-Reply-To: <473C0875.3020805@op5.se>
Hi,
On Thu, 15 Nov 2007, Andreas Ericsson wrote:
> Since empty repositories have HEAD pointing to refs/heads/master by
> default, you might get away with a simpler implementation.
I recently had somebody asking me "how do I rename master in an empty
repository?" It is only logical to think in those terms if you want to
start your common development on no common basis at all (i.e. the empty
set).
> > Am I stupid for using git for this sort of thing? I believe not.
> > And yet git developers choose to call me stupid because my work flow
> > does not lend any sense to a common ancestor commit.
>
> Not stupid, but most likely unusual. Optimizing git for your needs would
> imho be a bad idea. It's perfectly fine to use a tool for something else
> than what it was intended for, but then you'll have to live with the
> fact that it *will* have a few shortcomings and that you'll have to work
> around them or fix them yourself.
Yes, I agree. That's what Open Source is: some take their formula one car
to go shopping. In some cases, others laugh because that crate of beer
tied to the front spoiler sure looks funny. In some of these cases, the
driver laughs back, because only this car allows her to go shopping for
dinner in a town across the continent.
Seriously again, there are sure things git was not optimised for. If
some complaints involving such (from git's POV) suboptimal workflows are
retorted by saying so, it is not calling somebody "stupid". Sheesh.
Ciao,
Dscho
^ permalink raw reply
* Odd .gitignore behaviour
From: Bruce Stephens @ 2007-11-15 12:49 UTC (permalink / raw)
To: git
Perhaps I'm misreading the manpage, but I think this is wrong:
% mkdir base; cd base
% git init
% mkdir -p sub1/sub2
% cd sub1
% echo foo > .gitignore; echo '!sub2/foo' >> .gitignore
% touch sub2/foo
% git add sub2/foo
The following paths are ignored by one of your .gitignore files:
sub1/sub2/foo
Use -f if you really want to add them.
fatal: no files added
So sub1/sub2/foo matches the first pattern in sub1/.gitignore, but it
also matches the negated pattern '!sub2/foo' (in the same file, so
precedence isn't an issue). And the manpage says
o An optional prefix ! which negates the pattern; any matching
file excluded by a previous pattern will become included
again. If a negated pattern matches, this will override
lower precedence patterns sources.
So surely sub1/sub2/foo ought to be included again? Or is the first
line in sub1/.gitignore not "a previous pattern" in this sense?
If I move the "foo" pattern up a level, creating a .gitignore in base
just containing "foo", then sub1/sub2/foo is still regarded as
ignored, even though it surely matches the negating pattern
sub1/.gitignore, and that should be of higher precedence than the
pattern in base/.gitignore?
^ permalink raw reply
* Re: [PATCH 1/3] git-bisect: war on "sed"
From: Miles Bader @ 2007-11-15 12:59 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <861war4uzp.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
>> For typical straightforward usage, there seems little problem.
>>
>> [The main portability problems I've actually _noticed_ with sed are
>> the "-e" versus ";" issue and what happens with "\n" in various
>> contexts...]
>
> What about character classes containing the pattern delimiter, \+, \?,
> \|, nested grouping, anchors in groups, * after groups? That's all
> rather straightforward usage.
You're right that the regexp stuff is not really "dusty corners", but
none of those affect typical sed usage I think -- most sed usage being
really rather simple (and the old "regexps differ between traditional
unix tools" issue tends to dampen enthusiasm for really complex regexps
with those tools).
I looked over the various random uses of sed I have locally (a couple of
hundred instances), and the only thing which would potentially affect
any of them would be the SVR3 thing about no nested groups (does anybody
actually care about SVR3 though?!?).
-Miles
--
Yo mama's so fat when she gets on an elevator it HAS to go down.
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: David Kastrup @ 2007-11-15 13:15 UTC (permalink / raw)
To: git
In-Reply-To: <?= =?ISO-8859-1?Q?Pine.=04LNX.4.64.0?= =?ISO-8859-1?Q?711151330300.167?= =?ISO-8859-1?Q?28@wbgn129.bioze?= =?ISO-8859-1?Q?ntrum.uni-wuerzb?= =?ISO-8859-1?Q?urg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Seriously again, there are sure things git was not optimised for.
> If some complaints involving such (from git's POV) suboptimal
> workflows are retorted by saying so, it is not calling somebody
> "stupid". Sheesh.
"Conditioned by retarded systems" is pretty close, and it was pretty
much the wording employed. And then, when someone gets upset, he gets
"Sheesh"ed off, basically calling him stupid again.
"People skills" is not something I would associate with the git
developer list in general.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] Extend cat-file to take multiple arguments or read input from stdin.
From: Han-Wen Nienhuys @ 2007-11-15 13:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Adam Roben
In-Reply-To: <7vd4uc82g2.fsf@gitster.siamese.dyndns.org>
2007/11/15, Junio C Hamano <gitster@pobox.com>:
> > I suppose fast-export would just be cat-file with a different name and
> > slightly saner interface. How about
> >
> > type <sha1> <newline>
> > size <sha1> <newline>
> > dump <type> <sha1> <newline>
>
> I wondered why that looked so familiar ;-)
>
> http://thread.gmane.org/gmane.comp.version-control.git/62295/focus=62441
So, where has that patch gone?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* [PATCH v2] Documentation: customize diff-options depending on particular command
From: Sergei Organov @ 2007-11-15 13:19 UTC (permalink / raw)
To: git; +Cc: gitster
Customize diff-options depending on particular command as follows,
mostly to make git-diff and git-format-patch manuals less confusing:
* git-format-patch:
- Mark --patch-with-stat as being the default.
- Change -p description so that it matches what it actually does and
so that it doesn't refer to absent "section on generating
patches".
* git-diff: mark -p as being the default.
* git-diff-index/git-diff-files/git-diff-tree: mark --raw as being
the default.
Signed-off-by: Sergei Organov <osv@javad.com>
---
This patch is very similar to v1, except that asciidoc bug is avoided
(see comment in the first diff hunk).
Documentation/diff-options.txt | 24 +++++++++++++++++++++++-
Documentation/git-diff.txt | 1 +
Documentation/git-format-patch.txt | 1 +
3 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index b1f528a..e4af393 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -1,5 +1,25 @@
+// Please don't remove this comment as asciidoc behaves badly when
+// the first non-empty line is ifdef/ifndef. The symptom is that
+// without this comment the <git-diff-core> attribute conditionally
+// defined below ends up being defined unconditionally.
+// Last checked with asciidoc 7.0.2.
+
+ifndef::git-format-patch[]
+ifndef::git-diff[]
+:git-diff-core: 1
+endif::git-diff[]
+endif::git-format-patch[]
+
+ifdef::git-format-patch[]
-p::
- Generate patch (see section on generating patches)
+ Generate patches without diffstat.
+endif::git-format-patch[]
+
+ifndef::git-format-patch[]
+-p::
+ Generate patch (see section on generating patches).
+ {git-diff? This is the default.}
+endif::git-format-patch[]
-u::
Synonym for "-p".
@@ -13,6 +33,7 @@
--raw::
Generate the raw format.
+ {git-diff-core? This is the default.}
--patch-with-raw::
Synonym for "-p --raw".
@@ -41,6 +62,7 @@
--patch-with-stat::
Synonym for "-p --stat".
+ {git-format-patch? This is the default.}
-z::
NUL-line termination on output. This affects the --raw
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index 11c4216..2808a5e 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -75,6 +75,7 @@ and the range notations ("<commit>..<commit>" and
OPTIONS
-------
+:git-diff: 1
include::diff-options.txt[]
<path>...::
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index f0617ef..268f227 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -65,6 +65,7 @@ reference.
OPTIONS
-------
+:git-format-patch: 1
include::diff-options.txt[]
-<n>::
--
1.5.3.4
^ permalink raw reply related
* [BUG] t7004 (master) busted on Leopard
From: Wincent Colaiuta @ 2007-11-15 13:38 UTC (permalink / raw)
To: Git Mailing List
Commit 4d8b1dc850 added a couple of tests to t7004, and my testing
reveals that this one has been broken on Leopard since then:
* FAIL 83: message in editor has initial comment
GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
(Not sure whether this affects other platforms, or versions of Mac OS
X prior to Leopard, as I only have one machine here.)
The problem is the version of sed that ships with Leopard fails to
match the initial comment with this syntax:
sed -n "/^\(#\|\$\)/p" actual
An alternative that works is:
sed -n "/^[#\$]/p" actual
Can someone with knowledge of sed compatibility across multiple
platforms suggest an alternative which will work on a wider range of
systems?
Cheers,
Wincent
^ permalink raw reply
* [BUG] t9101 (master) busted on Leopard
From: Wincent Colaiuta @ 2007-11-15 13:46 UTC (permalink / raw)
To: Git Mailing List
Was just running the test suite against the master branch and saw that
t9101 is currently failing on Leopard, and a review with git-bisect
indicates that it has been ever since it was first introduced (in
commit 15153451). Not sure if this problem is Leopard-specific or not
as I only have one machine.
This is the specific test that's failing:
* FAIL 25: test propget
git-svn propget svn:ignore . | cmp - prop.expect &&
cd deeply &&
git-svn propget svn:ignore . | cmp - ../prop.expect &&
git-svn propget svn:entry:committed-rev nested/directory/.keep |
cmp - ../prop2.expect &&
git-svn propget svn:ignore .. | cmp - ../prop.expect &&
git-svn propget svn:ignore nested/ | cmp - ../prop.expect &&
git-svn propget svn:ignore ./nested | cmp - ../prop.expect &&
git-svn propget svn:ignore .././deeply/nested | cmp - ../prop.expect
The problem is that the for line:
git-svn propget svn:entry:committed-rev nested/directory/.keep
The test expects the "8", but it actually yields "7".
I'm not a git-svn user myself, but if there's anything I can do to
help diagnose this problem further on Leopard please let me know.
Cheers,
Wincent
^ permalink raw reply
* git-fetch--tool and contrib/examples/git-fetch.sh
From: Paolo Bonzini @ 2007-11-15 13:12 UTC (permalink / raw)
To: Git Mailing List
When git-fetch was builtin-ized the previous script was moved to
contrib/examples. Now, it is the sole remaining user for most of
git-parse-remote (except for get_remote_url) and for git-fetch--tool.
Would it make sense to remove git-fetch--tool, the dead parts of
git-parse-remote, and contrib/examples/git-fetch.sh? Anyway, the script
is very involuted unlike the other scripts in contrib/examples.
Paolo
^ permalink raw reply
* Re: core.excludesfile clean-up
From: Johannes Sixt @ 2007-11-15 14:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Junio,
in 039bc64e886 core.excludesfile clean-up you wrote:
> We probably could change git-ls-files to use the standard set
> when no excludes are specified on the command line and ignore
> processing was asked, or something like that, but that will be a
> change in semantics and might break people's scripts in a subtle
> way. I am somewhat reluctant to make such a change.
Just for the records: git-filter-branch uses git-ls-files in a way that
requires that no exclude files are in effect. In particular, if the tree
filter creates new files, they are unconditionally added. See the
documentation of --tree-filter.
-- Hannes
^ permalink raw reply
* Re: [BUG] t7004 (master) busted on Leopard
From: Johannes Schindelin @ 2007-11-15 14:37 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Git Mailing List
In-Reply-To: <17E3F66C-4644-4B64-817C-88062727A2D9@wincent.com>
Hi,
On Thu, 15 Nov 2007, Wincent Colaiuta wrote:
> Commit 4d8b1dc850 added a couple of tests to t7004, and my testing reveals
> that this one has been broken on Leopard since then:
>
> * FAIL 83: message in editor has initial comment
> GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
> test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
I think this is our good old friend, MacOSX' sed. (Wasn't there a
question today what's wrong with using sed? I think this issue
qualifies.)
I imagine that it is that MacOSX' sed is adding a trailing newline (not
the regexp like you suggested). Which means that "wc -l" would print "1".
(You can see for yourself if you run the script with "sh -x ...".)
IMHO a good solution would be
test -z "$(grep -e '^#' -e '^$' actual)"
Could you test, please?
Thanks,
Dscho
^ permalink raw reply
* Re: [BUG] t7004 (master) busted on Leopard
From: David Kastrup @ 2007-11-15 14:48 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0711151434060.30886@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Thu, 15 Nov 2007, Wincent Colaiuta wrote:
>
>> Commit 4d8b1dc850 added a couple of tests to t7004, and my testing reveals
>> that this one has been broken on Leopard since then:
>>
>> * FAIL 83: message in editor has initial comment
>> GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
>> test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
>
> I think this is our good old friend, MacOSX' sed. (Wasn't there a
> question today what's wrong with using sed? I think this issue
> qualifies.)
\| is not portable. $ in groups is not portable.
> I imagine that it is that MacOSX' sed is adding a trailing newline (not
> the regexp like you suggested).
I imagine it is one of the above. Most sed's add trailing newlines.
--
David Kastrup
^ permalink raw reply
* [PATCH] t7501-commit: Add test for git commit <file> with dirty index.
From: Kristian Høgsberg @ 2007-11-15 14:49 UTC (permalink / raw)
To: gitster; +Cc: git, Kristian Høgsberg
In-Reply-To: <Pine.LNX.4.64.0711150038020.4362@racer.site>
---
t/t7501-commit.sh | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 5aed3de..3627d9f 100644
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -259,4 +259,14 @@ test_expect_success 'amend commit to fix author' '
diff expected current
'
+
+test_expect_success 'git commit <file> with dirty index' '
+ echo tacocat > elif &&
+ echo tehlulz > chz &&
+ git add chz &&
+ git commit elif -m "tacocat is a palindrome" &&
+ git show --stat | grep elif &&
+ git diff --cached | grep chz
+'
+
test_done
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* Re: [BUG] t7004 (master) busted on Leopard
From: Wincent Colaiuta @ 2007-11-15 15:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711151434060.30886@racer.site>
El 15/11/2007, a las 15:37, Johannes Schindelin escribió:
> Hi,
>
> On Thu, 15 Nov 2007, Wincent Colaiuta wrote:
>
>> Commit 4d8b1dc850 added a couple of tests to t7004, and my testing
>> reveals
>> that this one has been broken on Leopard since then:
>>
>> * FAIL 83: message in editor has initial comment
>> GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
>> test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
>
> I think this is our good old friend, MacOSX' sed.
Yes, that's exactly what I said in the part of my post that you didn't
quote.
> I imagine that it is that MacOSX' sed is adding a trailing newline
> (not
> the regexp like you suggested). Which means that "wc -l" would
> print "1".
> (You can see for yourself if you run the script with "sh -x ...".)
Unless I am misreading the test, any output from "wc -l" that is
greater than 0 will cause the test to pass, so even if it outputted
"1" as you suggest then that wouldn't be the cause of the failure.
I do think the cause of the failure is the limited regexp syntax that
sed accepts on Leopard; witness: on Mac OS X the following prints 0:
echo "# hello" | sed -n "/^\(#\|\$\)/p" | wc -l
Whereas the following prints 1:
echo "# hello" | sed -n "/^[#\$]/p" | wc -l
Here's the output for the failing test run under "sh -x" as you
suggest, although I must admit that I can't really parse it myself.
+ test_expect_success 'message in editor has initial comment' '
GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
'
+ test 2 = 2
+ test_skip 'message in editor has initial comment' '
GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
'
++ expr ./t7004-tag.sh : '.*/\(t[0-9]*\)-[^/]*$'
+ this_test=t7004
++ expr 82 + 1
+ this_test=t7004.83
+ to_skip=
+ case "$to_skip" in
+ false
+ say 'expecting success:
GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
'
+ say_color info 'expecting success:
GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
'
+ case "$1" in
+ tput setaf 3
+ shift
+ echo '* expecting success:
GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
'
+ tput sgr0
+ test_run_ '
GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
'
+ eval '
GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
'
+ eval_ret=1
+ return 0
+ '[' 0 = 0 -a 1 = 0 ']'
+ test_failure_ 'message in editor has initial comment' '
GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
'
++ expr 82 + 1
+ test_count=83
++ expr 0 + 1
+ test_failure=1
+ say_color error 'FAIL 83: message in editor has initial comment'
+ case "$1" in
+ tput bold
+ tput setaf 1
+ shift
+ echo '* FAIL 83: message in editor has initial comment'
* FAIL 83: message in editor has initial comment
+ tput sgr0
+ shift
> IMHO a good solution would be
>
> test -z "$(grep -e '^#' -e '^$' actual)"
>
> Could you test, please?
Yes, the test passes with that, although it has to be written as
follows in the actual test file seeing as it's inside a single-quoted
string:
test -z "$(grep -e \"^#\" -e \"^$\" actual)"
Will follow this up with a patch that implements your proposed fix.
Cheers,
Wincent
^ permalink raw reply
* [PATCH] Fix git-tag test breakage caused by broken sed on Leopard
From: Wincent Colaiuta @ 2007-11-15 15:16 UTC (permalink / raw)
To: Git Mailing List; +Cc: Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0711151434060.30886@racer.site>
The 'message in editor has initial comment' test fails on Leopard (and
possibly on other versions of Mac OS X as well) due to the limited
sed syntax available on that platform.
Avoid the breakage by using grep instead (suggested by Johannes
Schindelin).
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
t/t7004-tag.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 096fe33..02ec9c3 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1007,7 +1007,7 @@ test_expect_failure \
test_expect_success \
'message in editor has initial comment' '
GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
- test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
+ test -z "$(grep -e \"^#\" -e \"^$\" actual)"
'
get_tag_header reuse $commit commit $time >expect
--
1.5.3.5
^ permalink raw reply related
* [PATCH v2] Fix git-tag test breakage caused by broken sed on Leopard
From: Wincent Colaiuta @ 2007-11-15 15:47 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Johannes Schindelin
In-Reply-To: <90D416F6-A3CA-43C8-B71F-38EA955A762B@wincent.com>
The 'message in editor has initial comment' test fails on Leopard (and
possibly on other versions of Mac OS X as well) due to the limited
sed syntax available on that platform.
Avoid the breakage by using grep instead (suggested by Johannes
Schindelin).
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
The patch I previously sent had the test sense inverted (it used 'test
-z' to test for an empty string when we should have actually been
looking for a non-empty string), so it really only passed by mistake.
This revised version maintains the sense of the original, sed-based
test.
t/t7004-tag.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 096fe33..b54c2e0 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1007,7 +1007,7 @@ test_expect_failure \
test_expect_success \
'message in editor has initial comment' '
GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
- test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
+ test $(grep -e "^#" -e "^\$" actual | wc -l ) -gt 0
'
get_tag_header reuse $commit commit $time >expect
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH] t7501-commit: Add test for git commit <file> with dirty index.
From: Johannes Schindelin @ 2007-11-15 15:55 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: gitster, git
In-Reply-To: <1195138198-24511-1-git-send-email-krh@redhat.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 784 bytes --]
Hi,
On Thu, 15 Nov 2007, Kristian Høgsberg wrote:
> ---
> t/t7501-commit.sh | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
> index 5aed3de..3627d9f 100644
> --- a/t/t7501-commit.sh
> +++ b/t/t7501-commit.sh
> @@ -259,4 +259,14 @@ test_expect_success 'amend commit to fix author' '
> diff expected current
>
> '
> +
> +test_expect_success 'git commit <file> with dirty index' '
> + echo tacocat > elif &&
> + echo tehlulz > chz &&
> + git add chz &&
> + git commit elif -m "tacocat is a palindrome" &&
> + git show --stat | grep elif &&
> + git diff --cached | grep chz
> +'
> +
Funny... I have something similar, but with a fix for builtin-commit ;-)
Will send out in a minute.
Ciao,
Dscho
^ permalink raw reply
* Re: [BUG] t9101 (master) busted on Leopard
From: Brian Gernhardt @ 2007-11-15 16:04 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Git Mailing List
In-Reply-To: <D68F81D3-5833-460B-BC7A-98C7E1D8B3E4@wincent.com>
On Nov 15, 2007, at 8:46 AM, Wincent Colaiuta wrote:
> Was just running the test suite against the master branch and saw
> that t9101 is currently failing on Leopard, and a review with git-
> bisect indicates that it has been ever since it was first introduced
> (in commit 15153451). Not sure if this problem is Leopard-specific
> or not as I only have one machine.
It is not a Leopard specific problem, as far as I can tell. I just
ran the test and had no errors on my Leopard machine. So perhaps it's
some other detail of your setup?
> I'm not a git-svn user myself, but if there's anything I can do to
> help diagnose this problem further on Leopard please let me know.
I just tested it using svn from fink and (after discovering it exists)
from Leopard. No problems. Do you have an old svn package (client,
admin, or perl binding) installed from Darwin Ports or Fink perhaps?
~~ Brian
^ permalink raw reply
* Re: [BUG] t9101 (master) busted on Leopard
From: Wincent Colaiuta @ 2007-11-15 16:11 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git Mailing List
In-Reply-To: <BB9A8E3F-DC19-4844-80E1-6AEAADF926CD@silverinsanity.com>
El 15/11/2007, a las 17:04, Brian Gernhardt escribió:
> On Nov 15, 2007, at 8:46 AM, Wincent Colaiuta wrote:
>
>> Was just running the test suite against the master branch and saw
>> that t9101 is currently failing on Leopard, and a review with git-
>> bisect indicates that it has been ever since it was first
>> introduced (in commit 15153451). Not sure if this problem is
>> Leopard-specific or not as I only have one machine.
>
> It is not a Leopard specific problem, as far as I can tell. I just
> ran the test and had no errors on my Leopard machine. So perhaps
> it's some other detail of your setup?
>
>> I'm not a git-svn user myself, but if there's anything I can do to
>> help diagnose this problem further on Leopard please let me know.
>
> I just tested it using svn from fink and (after discovering it
> exists) from Leopard. No problems. Do you have an old svn package
> (client, admin, or perl binding) installed from Darwin Ports or Fink
> perhaps?
I don't use Darwin Ports or Fink, and this is a clean Leopard install
(ie. nothing installed in /usr/local apart from git and a very small
number of other tools that aren't related to Subversion).
This is the output of "/usr/bin/svn --version":
svn, version 1.4.4 (r25188)
compiled Sep 23 2007, 22:32:34
Perhaps then it is something in the environment.
Cheers,
Wincent
^ permalink raw reply
* [PATCH] builtin-commit: fix "git add x y && git commit y" committing x, too
From: Johannes Schindelin @ 2007-11-15 16:11 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: gitster, git
In-Reply-To: <1195138198-24511-1-git-send-email-krh@redhat.com>
Earlier, builtin commit would implicitly commit also the staged
changes.
This patch fixes that.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
The function reset_index_to_head() could be moved to somewhere
more central and be reused in builtin-reset.c instead of
reset_index_file() later...
builtin-add.c | 1 +
builtin-commit.c | 30 +++++++++++++++++++++++++++++-
t/t7500-commit.sh | 10 ++++++++++
3 files changed, 40 insertions(+), 1 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 77dcde6..017c8f2 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -100,6 +100,7 @@ static void update_callback(struct diff_queue_struct *q,
case DIFF_STATUS_UNMERGED:
case DIFF_STATUS_MODIFIED:
case DIFF_STATUS_TYPE_CHANGED:
+ case DIFF_STATUS_ADDED:
add_file_to_cache(path, verbose);
break;
case DIFF_STATUS_DELETED:
diff --git a/builtin-commit.c b/builtin-commit.c
index 535039c..0dc6e1c 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -19,6 +19,7 @@
#include "strbuf.h"
#include "utf8.h"
#include "parse-options.h"
+#include "unpack-trees.h"
static const char * const builtin_commit_usage[] = {
"git-commit [options] [--] <filepattern>...",
@@ -77,6 +78,31 @@ static struct option builtin_commit_options[] = {
OPT_END()
};
+static int reset_index_to_head(void)
+{
+ struct unpack_trees_options opts;
+ struct tree_desc tree_desc;
+ struct tree *tree;
+ unsigned char sha1[20];
+
+ /* ignore if it is an initial commit */
+ if (get_sha1("HEAD", sha1))
+ return 0;
+ tree = parse_tree_indirect(sha1);
+ if (!tree || parse_tree(tree))
+ return error("Could not get HEAD's tree");
+ init_tree_desc(&tree_desc, tree->buffer, tree->size);
+
+ memset(&opts, 0, sizeof(opts));
+ opts.index_only = 1;
+ opts.merge = 1;
+ opts.head_idx = 1;
+ opts.fn = oneway_merge;
+ if (unpack_trees(1, &tree_desc, &opts))
+ return error("Could not reset temporary index to HEAD");
+ return 0;
+}
+
static char *prepare_index(const char **files, const char *prefix)
{
int fd;
@@ -120,12 +146,14 @@ static char *prepare_index(const char **files, const char *prefix)
die("failed to read HEAD tree object");
}
+ if (reset_index_to_head())
+ die ("failed to reset temporary index to HEAD");
+
/* Use a lock file to garbage collect the temporary index file. */
next_index_lock = xmalloc(sizeof(*next_index_lock));
fd = hold_lock_file_for_update(next_index_lock,
git_path("next-index-%d", getpid()), 1);
add_files_to_cache(verbose, prefix, files);
- refresh_cache(REFRESH_QUIET);
if (write_cache(fd, active_cache, active_nr) || close(fd))
die("unable to write new_index file");
diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
index c9d65e5..d4d7ed7 100755
--- a/t/t7500-commit.sh
+++ b/t/t7500-commit.sh
@@ -139,4 +139,14 @@ test_expect_success '--signoff' '
diff expect output
'
+test_expect_success 'implicit --only only commits specified files' '
+ echo "tonight: " > take &&
+ echo "over the" > world &&
+ git add world take &&
+ test_tick &&
+ git commit -m partial world &&
+ git diff-tree HEAD^..HEAD -- take &&
+ ! git diff-index --cached --exit-code HEAD -- take
+'
+
test_done
--
1.5.3.5.1786.gdaaa
^ permalink raw reply related
* [PATCH] refs.c: Remove unused get_ref_sha1()
From: Johannes Sixt @ 2007-11-15 16:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
refs.c | 12 ------------
refs.h | 3 ---
2 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/refs.c b/refs.c
index aff02cd..ae53254 100644
--- a/refs.c
+++ b/refs.c
@@ -580,18 +580,6 @@ int for_each_remote_ref(each_ref_fn fn, void *cb_data)
return do_for_each_ref("refs/remotes/", fn, 13, cb_data);
}
-/* NEEDSWORK: This is only used by ssh-upload and it should go; the
- * caller should do resolve_ref or read_ref like everybody else. Or
- * maybe everybody else should use get_ref_sha1() instead of doing
- * read_ref().
- */
-int get_ref_sha1(const char *ref, unsigned char *sha1)
-{
- if (check_ref_format(ref))
- return -1;
- return read_ref(mkpath("refs/%s", ref), sha1);
-}
-
/*
* Make sure "ref" is something reasonable to have under ".git/refs/";
* We do not like it if:
diff --git a/refs.h b/refs.h
index 6eb98a4..9dc8aa0 100644
--- a/refs.h
+++ b/refs.h
@@ -26,9 +26,6 @@ extern int for_each_remote_ref(each_ref_fn, void *);
extern int peel_ref(const char *, unsigned char *);
-/** Reads the refs file specified into sha1 **/
-extern int get_ref_sha1(const char *ref, unsigned char *sha1);
-
/** Locks a "refs/" ref returning the lock on success and NULL on failure. **/
extern struct ref_lock *lock_ref_sha1(const char *ref, const unsigned char *old_sha1);
--
1.5.3.5.578.g1f8ec
^ permalink raw reply related
* Re: stgit 0.13 + git 1.5.3.5 bogus "empty patch" status, and other problems
From: Catalin Marinas @ 2007-11-15 16:37 UTC (permalink / raw)
To: Adam J. Richter; +Cc: git
In-Reply-To: <200711120039.lAC0dgex015049@freya.yggdrasil.com>
On 12/11/2007, Adam J. Richter <adam@yggdrasil.com> wrote:
> So, did repeated "stg pop" commands to get to the point where
> the change to parser.y is applied, did an "stg new", deleted
> y.tab.{c,h}, did "stg rm y.tab.{c,h}" and "stg refresh". So far, so
> good. Then I tried to do an "stg push" to re-integrate the next
> patch, and I got a complaint from stgit about some git object not
> existing. This patch did not touch y.tab.{c,h} or any files touched
> by any of the other patches I had pushed on.
I don't know the exact error but are you sure that changes to
y.tab.{c,h} are not involuntarily included in other patches?
> I don't know stgit well
> enough to recover from the situation gracefully, so I just wiped the
> stgit tree and tried to apply the patches again, which brings me to
> bug #2.
If the error is a conflict, 'stg push --undo' should revert the pushed
patch to its previous state. Otherwise, fix the conflict and run 'stg
refresh'.
> I made a new stgit tree of the program (bash), pulling from a
> local git tree, and attempted to apply the first patch, with usuaul
> "stg new...make changes...stg refresh". Then stg refresh informed
> printed this message ("invalid_multibyte_sequence" is the name of the
> new patch):
>
> Checking for changes in the working directory ... done
> Refreshing patch "invalid_multibyte_sequence" ... done (empty patch)
>
> "stg diff" still shows the changes as if I had not done an
> "stg refresh". Obviously, stg commits have worked for me in the past.
> I suspect that a recent upgrade of git or other system software
> triggered the break.
I haven't seen this type of error before. There might be some
inconsistency between the HEAD and the index. Can you try
'git-read-tree HEAD' and run 'stg refresh' afterwards?
You might also want to try the latest StGIT snapshot. It should be
pretty stable as we are preparing it for a 0.14 release.
--
Catalin
^ 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