* Re: Solaris 'make' & Git Makefile
From: Junio C Hamano @ 2007-11-16 23:49 UTC (permalink / raw)
To: Guido Ostkamp; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711162353170.7281@bianca.dialin.t-online.de>
Guido Ostkamp <git@ostkamp.fastmail.fm> writes:
> Question: Do you require the GNU make utility for Git?
>
> If yes, then I think this should be mentioned in README or INSTALL.
I think that would be a sensible thing to do. Please make it
happen.
^ permalink raw reply
* Re: Solaris 'make' & Git Makefile
From: Pierre Habouzit @ 2007-11-16 23:29 UTC (permalink / raw)
To: Guido Ostkamp; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711162353170.7281@bianca.dialin.t-online.de>
[-- Attachment #1: Type: text/plain, Size: 833 bytes --]
On Fri, Nov 16, 2007 at 10:59:48PM +0000, Guido Ostkamp wrote:
> Hello Junio, *,
>
> the Solaris 'make' utility cannot handle the 'Makefile' that is delivered
> with Git or generated by Git's configure.
>
> A Solaris make run breaks around line 138.
>
> Question: Do you require the GNU make utility for Git?
Well, the fact that solaris make doesn't understands @ is well... no
comments. But we also require ifdef/endif to work, and bsd make doesn't
grok that e.g. SO yes, I believe GNU Make is somehow required. The
Makefiles don't use double expansions and such tricks, so even quite
antiquated GNU Make versions should work fine
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Solaris 'make' & Git Makefile
From: Guido Ostkamp @ 2007-11-16 22:59 UTC (permalink / raw)
To: git; +Cc: git
Hello Junio, *,
the Solaris 'make' utility cannot handle the 'Makefile' that is delivered
with Git or generated by Git's configure.
A Solaris make run breaks around line 138.
Question: Do you require the GNU make utility for Git?
If yes, then I think this should be mentioned in README or INSTALL. If
not, then the Makefile or configure needs to be fixed.
Regards
Guido
^ permalink raw reply
* Re: [PATCH] Fix Solaris compiler warnings
From: Guido Ostkamp @ 2007-11-16 22:52 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Guido Ostkamp, git
In-Reply-To: <20071116074850.GA3400@steel.home>
On Fri, 16 Nov 2007, Alex Riesen wrote:
> Hmm... Guido, I owe you an appology.
accepted ;-)
> Still, consider this patch instead (it does not fix the return in
> xdiff/xdiffi.c though):
If your intention is to have a final 'return' statement for stupid
compilers, this should work (though I haven't verified it on a live system
I think it looks reasonably well).
Are you going to include it?
What about the xdiff/xdiffi.c problem that should also be solved?
Regards
Guido
^ permalink raw reply
* Re: [PATCH] Fix and improve t7004
From: Benoit Sigoure @ 2007-11-16 21:47 UTC (permalink / raw)
To: Mike Hommey; +Cc: Git Mailing List
In-Reply-To: <20071116213538.GA30076@glandium.org>
[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]
On Nov 16, 2007, at 10:35 PM, Mike Hommey wrote:
> On Fri, Nov 16, 2007 at 10:31:15PM +0100, Benoit Sigoure wrote:
>> On Nov 16, 2007, at 10:11 PM, Mike Hommey wrote:
>>
>>> On Fri, Nov 16, 2007 at 10:04:57PM +0100, Benoit Sigoure wrote:
>>>> On Nov 16, 2007, at 9:28 PM, Mike Hommey wrote:
>>>>> 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
>>>>> + ( read empty ;
>>>>> + [ "$empty" ] && exit 1 ;
>>>>
>>>> What is this meant to do? Did you mean [ -n "$empty" ] ?
>>>
>>> Replacing with [ -n "$empty" ] would not work properly, except if
>>> you
>>> replace the following ; with &&. Does that really make a readability
>>> difference ?
>>
>> I don't get it. As far as I understand, you're trying to check
>> whether
>> $empty is indeed empty, right? So how is `[ "$empty" ]' meant to
>> work?
>> [ -n "$empty" ] && exit 1
>>
>> will exit 1 if empty isn't empty.
>
> Sorry, I read '-z', not '-n'. [ "$empty" ] and [ -n "$empty" ] are the
> same thing.
Heh, forgive my ignorance, I did not know the [ "string" ] notation.
Amazing, after all these years of shell scripting...
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix and improve t7004
From: Junio C Hamano @ 2007-11-16 21:42 UTC (permalink / raw)
To: Mike Hommey; +Cc: Benoit Sigoure, git
In-Reply-To: <20071116211148.GA28966@glandium.org>
Mike Hommey <mh@glandium.org> writes:
>>> + ( read empty ;
>>> + [ "$empty" ] && exit 1 ;
>>
>> What is this meant to do? Did you mean [ -n "$empty" ] ?
>
> Replacing with [ -n "$empty" ] would not work properly, except if you
> replace the following ; with &&. Does that really make a readability
> difference ?
>
>>> + ! grep -ve "^#" > /dev/null 2>&1 ) < actual
>>
>> The double negation is harder to read. May I suggest something along these
>> lines (which seems more readable to me):
>> while read line; do
>> case $line in #(
>> '#'*) ;; # Accept comments (
>> *) exit 1;;
>> esac
>> done
>
> I'm not really convinced. What do other people have to say ?
As shell "read" loses information (a backslash sequence is
interpreted, and trailing whitespaces are stripped and not
assigned to "line" above), it is not such a good vehicle if you
want to make a reasonably strict test on top of. Some shells
do not implement "read -r" either, so it is also a portability
hassle.
Perhaps...
# check the first line --- should be empty
first=$(sed -e 1q <actual) &&
test -z "$first" &&
# remove commented lines from the remainder -- should be empty
rest=$(sed -e 1d -e '/^#/d' <actual) &&
test -z "$rest"
^ permalink raw reply
* Re: [PATCH] Fix and improve t7004
From: Mike Hommey @ 2007-11-16 21:35 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: git, Junio C Hamano
In-Reply-To: <EC3B30DC-E81C-4ECA-BE7F-F237E1338603@lrde.epita.fr>
On Fri, Nov 16, 2007 at 10:31:15PM +0100, Benoit Sigoure wrote:
> On Nov 16, 2007, at 10:11 PM, Mike Hommey wrote:
>
>> On Fri, Nov 16, 2007 at 10:04:57PM +0100, Benoit Sigoure wrote:
>>> On Nov 16, 2007, at 9:28 PM, Mike Hommey wrote:
>>>> 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
>>>> + ( read empty ;
>>>> + [ "$empty" ] && exit 1 ;
>>>
>>> What is this meant to do? Did you mean [ -n "$empty" ] ?
>>
>> Replacing with [ -n "$empty" ] would not work properly, except if you
>> replace the following ; with &&. Does that really make a readability
>> difference ?
>
> I don't get it. As far as I understand, you're trying to check whether
> $empty is indeed empty, right? So how is `[ "$empty" ]' meant to work?
> [ -n "$empty" ] && exit 1
>
> will exit 1 if empty isn't empty.
Sorry, I read '-z', not '-n'. [ "$empty" ] and [ -n "$empty" ] are the
same thing.
Mike
^ permalink raw reply
* Re: [PATCH] Fix and improve t7004
From: Benoit Sigoure @ 2007-11-16 21:31 UTC (permalink / raw)
To: Mike Hommey; +Cc: git, Junio C Hamano
In-Reply-To: <20071116211148.GA28966@glandium.org>
[-- Attachment #1: Type: text/plain, Size: 933 bytes --]
On Nov 16, 2007, at 10:11 PM, Mike Hommey wrote:
> On Fri, Nov 16, 2007 at 10:04:57PM +0100, Benoit Sigoure wrote:
>> On Nov 16, 2007, at 9:28 PM, Mike Hommey wrote:
>>> 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
>>> + ( read empty ;
>>> + [ "$empty" ] && exit 1 ;
>>
>> What is this meant to do? Did you mean [ -n "$empty" ] ?
>
> Replacing with [ -n "$empty" ] would not work properly, except if you
> replace the following ; with &&. Does that really make a readability
> difference ?
I don't get it. As far as I understand, you're trying to check
whether $empty is indeed empty, right? So how is `[ "$empty" ]'
meant to work?
[ -n "$empty" ] && exit 1
will exit 1 if empty isn't empty.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix and improve t7004
From: Mike Hommey @ 2007-11-16 21:11 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: git, Junio C Hamano
In-Reply-To: <EEE710FA-0408-489F-8128-B4C1F06D34FF@lrde.epita.fr>
On Fri, Nov 16, 2007 at 10:04:57PM +0100, Benoit Sigoure wrote:
> On Nov 16, 2007, at 9:28 PM, Mike Hommey wrote:
>
>> Brown paper bag fix to avoid using non portable sed syntax. The
>> test by itself didn't catch what it was supposed to, anyways.
>>
>> The new test first checks whether the user exited the editor
>> without editing the file, then whether what the user was
>> presented in the editor was any useful to her, which we define
>> as the following:
>> * It begins with a single blank line, where the invoked editor
>> would typically place the editing curser at so that the user
>> can immediately start typing;
>>
>> * It has some instruction but that comes after that initial
>> blank line, all lines prefixed with "#".
>>
>> * And it has nothing else, as the expected behaviour is "Hey
>> you did not leave any message".
>>
>> Signed-off-by: Mike Hommey <mh@glandium.org>
>> ---
>> t/t7004-tag.sh | 9 ++++++++-
>> 1 files changed, 8 insertions(+), 1 deletions(-)
>>
>> diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
>> index 096fe33..42b1f97 100755
>> --- a/t/t7004-tag.sh
>> +++ b/t/t7004-tag.sh
>> @@ -1004,10 +1004,17 @@ test_expect_failure \
>> 'verify signed tag fails when public key is not present' \
>> 'git-tag -v signed-tag'
>>
>> +test_expect_failure \
>> + 'git-tag -a fails if tag annotation is empty' '
>> + GIT_EDITOR=cat git tag -a initial-comment > /dev/null 2>&1
>> +'
>> +
>> 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
>> + ( read empty ;
>> + [ "$empty" ] && exit 1 ;
>
> What is this meant to do? Did you mean [ -n "$empty" ] ?
Replacing with [ -n "$empty" ] would not work properly, except if you
replace the following ; with &&. Does that really make a readability
difference ?
>> + ! grep -ve "^#" > /dev/null 2>&1 ) < actual
>
> The double negation is harder to read. May I suggest something along these
> lines (which seems more readable to me):
> while read line; do
> case $line in #(
> '#'*) ;; # Accept comments (
> *) exit 1;;
> esac
> done
I'm not really convinced. What do other people have to say ?
Mike
^ permalink raw reply
* Re: [PATCH] Fix and improve t7004
From: Benoit Sigoure @ 2007-11-16 21:04 UTC (permalink / raw)
To: Mike Hommey; +Cc: git, Junio C Hamano
In-Reply-To: <1195244917-25659-1-git-send-email-mh@glandium.org>
[-- Attachment #1: Type: text/plain, Size: 2185 bytes --]
On Nov 16, 2007, at 9:28 PM, Mike Hommey wrote:
> Brown paper bag fix to avoid using non portable sed syntax. The
> test by itself didn't catch what it was supposed to, anyways.
>
> The new test first checks whether the user exited the editor
> without editing the file, then whether what the user was
> presented in the editor was any useful to her, which we define
> as the following:
> * It begins with a single blank line, where the invoked editor
> would typically place the editing curser at so that the user
> can immediately start typing;
>
> * It has some instruction but that comes after that initial
> blank line, all lines prefixed with "#".
>
> * And it has nothing else, as the expected behaviour is "Hey
> you did not leave any message".
>
> Signed-off-by: Mike Hommey <mh@glandium.org>
> ---
> t/t7004-tag.sh | 9 ++++++++-
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
> index 096fe33..42b1f97 100755
> --- a/t/t7004-tag.sh
> +++ b/t/t7004-tag.sh
> @@ -1004,10 +1004,17 @@ test_expect_failure \
> 'verify signed tag fails when public key is not present' \
> 'git-tag -v signed-tag'
>
> +test_expect_failure \
> + 'git-tag -a fails if tag annotation is empty' '
> + GIT_EDITOR=cat git tag -a initial-comment > /dev/null 2>&1
> +'
> +
> 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
> + ( read empty ;
> + [ "$empty" ] && exit 1 ;
What is this meant to do? Did you mean [ -n "$empty" ] ?
> + ! grep -ve "^#" > /dev/null 2>&1 ) < actual
The double negation is harder to read. May I suggest something along
these lines (which seems more readable to me):
while read line; do
case $line in #(
'#'*) ;; # Accept comments (
*) exit 1;;
esac
done
Advantages:
The purpose of the test is more obvious
The test is more easily extendable
The test saves a fork ;o
> '
>
> get_tag_header reuse $commit commit $time >expect
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* [PATCH] Fix and improve t7004
From: Mike Hommey @ 2007-11-16 20:28 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vlk8yx9rp.fsf@gitster.siamese.dyndns.org>
Brown paper bag fix to avoid using non portable sed syntax. The
test by itself didn't catch what it was supposed to, anyways.
The new test first checks whether the user exited the editor
without editing the file, then whether what the user was
presented in the editor was any useful to her, which we define
as the following:
* It begins with a single blank line, where the invoked editor
would typically place the editing curser at so that the user
can immediately start typing;
* It has some instruction but that comes after that initial
blank line, all lines prefixed with "#".
* And it has nothing else, as the expected behaviour is "Hey
you did not leave any message".
Signed-off-by: Mike Hommey <mh@glandium.org>
---
t/t7004-tag.sh | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 096fe33..42b1f97 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1004,10 +1004,17 @@ test_expect_failure \
'verify signed tag fails when public key is not present' \
'git-tag -v signed-tag'
+test_expect_failure \
+ 'git-tag -a fails if tag annotation is empty' '
+ GIT_EDITOR=cat git tag -a initial-comment > /dev/null 2>&1
+'
+
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
+ ( read empty ;
+ [ "$empty" ] && exit 1 ;
+ ! grep -ve "^#" > /dev/null 2>&1 ) < actual
'
get_tag_header reuse $commit commit $time >expect
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH] Fix t7004 which fails with retarded sed
From: Junio C Hamano @ 2007-11-16 19:36 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20071116191715.GB7624@glandium.org>
Mike Hommey <mh@glandium.org> writes:
>> So the earlier part of the test
>>
>> GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
>>
>> is already bogus with respect to the latter point. It will
>> happily continue if "git tag" erroneously returns success, and
>> the above does not catch it.
>>
>> if GIT_EDITOR=cat git tag -a initial-comment >actual
>> then
>> echo >&2 oops we should have errored out
>> false
>> else
>> : happy -- anything else we want to check?
>> fi
>
> This should probably be tested in another test block.
Fair enough; please make it so.
> Which is roughly what my patch does, except it doesn't check for
> ordering.
... which I think is more important part. If the blank like
were at the end, that would be irritating for the user, wouldn't
it?
^ permalink raw reply
* Re: [PATCH] Fix t7004 which fails with retarded sed
From: Mike Hommey @ 2007-11-16 19:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpryaxczx.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 16, 2007 at 10:26:58AM -0800, Junio C Hamano wrote:
> Mike Hommey <mh@glandium.org> writes:
>
> > Brown paper bag fix to avoid test failure with retarded sed. The test
> > by itself didn't catch what it was supposed to, anyways.
>
> I'd rather not to say "retarded sed". It is not fair to blame
> the implementation when the script we feed to it is not
> portable.
>
> > 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
> > + grep -e "^$" actual > /dev/null 2>&1 &&
> > + grep -e "^#" actual > /dev/null 2>&1 &&
> > + ! grep -e "^[^#]" actual > /dev/null 2>&1
>
> The test simulates a case where
>
> $ git tag -a initial-comment
>
> is run and the user exits the editor without editing the file to
> add any text to annotate the tag. The behaviour we want from
> such an invocation is (1) the user sees a sensible template in
> the editor, and (2) the command to error out, saying "Hey, you
> did not leave any message for us to use".
>
> So the earlier part of the test
>
> GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
>
> is already bogus with respect to the latter point. It will
> happily continue if "git tag" erroneously returns success, and
> the above does not catch it.
>
> if GIT_EDITOR=cat git tag -a initial-comment >actual
> then
> echo >&2 oops we should have errored out
> false
> else
> : happy -- anything else we want to check?
> fi
This should probably be tested in another test block.
> The "actual" file contains what the user saw in the editor and
> returned to the "git tag" command.
>
> The template we give to the user begins with a blank line,
> followed by a brief instruction "write a tag message" as
> comments to be stripped. The test is trying to make sure that
> is what was given to the user. As you already discussed in the
> thread, the exact wording may change in the future and we would
> not want to adjust the test every time.
>
> I think the important points about this template are:
>
> * It begins with a single blank line, where the invoked editor
> would typically place the editing curser at so that the user
> can immediately start typing;
>
> * It has some instruction but that comes after that initial
> blank line, all lines prefixed with "#". I do not think we
> would want to check the wording of this instruction.
>
> * And it has nothing else, as the expected behaviour is "Hey
> you did not leave any message".
Which is roughly what my patch does, except it doesn't check for
ordering.
Mike
^ permalink raw reply
* Re: [PATCH] Fix t7004 which fails with retarded sed
From: Mike Hommey @ 2007-11-16 19:15 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Git Mailing List
In-Reply-To: <6E925AF7-FCCB-4793-936F-7BC513272E75@lrde.epita.fr>
On Fri, Nov 16, 2007 at 06:58:21PM +0100, Benoit Sigoure wrote:
> On Nov 16, 2007, at 6:26 PM, Mike Hommey wrote:
>
>> Brown paper bag fix to avoid test failure with retarded sed. The test
>> by itself didn't catch what it was supposed to, anyways.
>>
>> So now, we test whether the editor gets at least an empty line, some
>> commented lines, and doesn't get anything else.
>>
>> Signed-off-by: Mike Hommey <mh@glandium.org>
>> ---
>> t/t7004-tag.sh | 4 +++-
>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
>> index 096fe33..3813f23 100755
>> --- a/t/t7004-tag.sh
>> +++ b/t/t7004-tag.sh
>> @@ -1007,7 +1007,9 @@ 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
>> + grep -e "^$" actual > /dev/null 2>&1 &&
>> + grep -e "^#" actual > /dev/null 2>&1 &&
>> + ! grep -e "^[^#]" actual > /dev/null 2>&1
>> '
>>
>> get_tag_header reuse $commit commit $time >expect
>
> If your system has a retarded `sed', it will most likely also have a
> brain-dead `/bin/sh' which doesn't handle `! command'. So I suggest you
> rewrite the last line as:
> grep -ve "^[^#]" actual > /dev/null 2>&1
A whole lot of the test suite uses `! command', which is why i chose to
use it.
Mike
^ permalink raw reply
* [PATCH] Add mkdtemp() workaround for Sun Solaris 10
From: Guido Ostkamp @ 2007-11-16 18:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Guido Ostkamp, git
In-Reply-To: <7v640340kp.fsf@gitster.siamese.dyndns.org>
On Thu, 15 Nov 2007, Junio C Hamano wrote:
> Are there problems with the implementation in compat/ directory, we ship
> specifically to help platforms without mkdtemp()?
I checked again and the answer is 'yes'. The reason is trivial - for
Solaris 10 the workaround is not activated and my version of Solaris 10
(Sparc) has no mkdtemp() in libc.so.
The following patch should fix this:
Activate mkdtemp() workaround for Solaris 10.
Signed-off-by: Guido Ostkamp <git@ostkamp.fastmail.fm>
---
Makefile | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index e830bc7..9dc01df 100644
--- a/Makefile
+++ b/Makefile
@@ -431,6 +431,9 @@ ifeq ($(uname_S),SunOS)
NO_C99_FORMAT = YesPlease
NO_STRTOUMAX = YesPlease
endif
+ ifeq ($(uname_R),5.10)
+ NO_MKDTEMP = YesPlease
+ endif
INSTALL = ginstall
TAR = gtar
BASIC_CFLAGS += -D__EXTENSIONS__
--
1.5.3.5.721.g039b
^ permalink raw reply related
* [PATCH] Documentation: fix git-clone manpage not to refer to itself
From: Sergei Organov @ 2007-11-16 18:43 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: Sergei Organov <osv@javad.com>
---
Documentation/git-clone.txt | 1 +
Documentation/urls.txt | 6 ++++++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 14e58f3..c90bcec 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -130,6 +130,7 @@ OPTIONS
for "host.xz:foo/.git"). Cloning into an existing directory
is not allowed.
+:git-clone: 1
include::urls.txt[]
Examples
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index e67f914..4f66738 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -36,5 +36,11 @@ To sync with a local directory, you can use:
- file:///path/to/repo.git/
===============================================================
+ifndef::git-clone[]
They are mostly equivalent, except when cloning. See
gitlink:git-clone[1] for details.
+endif::git-clone[]
+
+ifdef::git-clone[]
+They are equivalent, except the former implies --local option.
+endif::git-clone[]
--
1.5.3.4
^ permalink raw reply related
* Fwd: [postmaster@vger.kernel.org: Delivery reports about your email [FAILED(1)]]
From: Matti Aarnio @ 2007-11-16 18:35 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 63 bytes --]
Here is a sample message that NEEDS proper charset mime tags.
[-- Attachment #2: Type: message/rfc822, Size: 9118 bytes --]
[-- Attachment #2.1.1: Type: text/plain, Size: 3638 bytes --]
This is a collection of reports about email delivery
process concerning a message you originated.
Some explanations/translations for these reports
can be found at:
http://www.zmailer.org/delivery-report-decoding.html
Generic VGER note: Joining/leaving VGER's lists thru server:
majordomo@vger.kernel.org
Reporting-MTA: dns; vger.kernel.org
Return-Path: <stable-commits-owner@vger.kernel.org>
Arrival-Date: Fri, 16 Nov 2007 13:09:40 -0500
Local-Spool-ID: S1751399AbXKPSJk
FAILED:
Original Recipient:
rfc822;jfunk@funktronics.ca
Final Recipient:
RFC822;jfunk@funktronics.ca
Status:
5.1.1 (bad destination mailbox)
Remote MTA:
dns; elseed.funktronics.ca (65.61.206.36|25|209.132.176.167|48741)
Last Attempt Date:
Fri, 16 Nov 2007 13:10:02 -0500
X-ZTAID:
smtp[6139]
Diagnostic Code:
smtp; 550 (Error: improper use of 8-bit data in message body)
Control data:
smtp funktronics.ca jfunk@funktronics.ca 99
Diagnostic texts:
<<- MAIL From:<stable-commits-owner@vger.kernel.org> BODY=8BITMIME SIZE=3712
->> 250 Ok
<<- RCPT To:<jfunk@funktronics.ca>
->> 250 Ok
<<- DATA
->> 354 End data with <CR><LF>.<CR><LF>
<<- .
->> 550 Error: improper use of 8-bit data in message body
Following is a copy of MESSAGE/DELIVERY-STATUS format section below.
It is copied here in case your email client is unable to show it to you.
The information here below is in Internet Standard format designed to
assist automatic, and accurate presentation and usage of said information.
In case you need human assistance from the Postmaster(s) of the system which
sent you this report, please include this information in your question!
Virtually Yours,
Automatic Email Delivery Software
Reporting-MTA: dns; vger.kernel.org
Arrival-Date: Fri, 16 Nov 2007 13:09:40 -0500
Local-Spool-ID: S1751399AbXKPSJk
Original-Recipient: rfc822;jfunk@funktronics.ca
Final-Recipient: RFC822;jfunk@funktronics.ca
Action: failed
Status: 5.1.1 (bad destination mailbox)
Remote-MTA: dns; elseed.funktronics.ca (65.61.206.36|25|209.132.176.167|48741)
Last-Attempt-Date: Fri, 16 Nov 2007 13:10:02 -0500
Diagnostic-Code: smtp; 550 (Error: improper use of 8-bit data in message body)
Following is copy of the message headers. Original message content may
be in subsequent parts of this MESSAGE/DELIVERY-STATUS structure.
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S1751399AbXKPSJk; Fri, 16 Nov 2007 13:09:40 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756649AbXKPSJk
(ORCPT <rfc822;stable-commits-outgoing>);
Fri, 16 Nov 2007 13:09:40 -0500
Received: from ns2.suse.de ([195.135.220.15]:33829 "EHLO mx2.suse.de"
rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
id S1751399AbXKPSJj (ORCPT <rfc822;stable-commits@vger.kernel.org>);
Fri, 16 Nov 2007 13:09:39 -0500
Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx2.suse.de (Postfix) with ESMTP id 142E02BDB9;
Fri, 16 Nov 2007 19:09:38 +0100 (CET)
Subject: patch tcp-make-sure-write_queue_from-does-not-begin-with-null-ptr.patch queued to -stable tree
To: ilpo.jarvinen@helsinki.fi, davem@davemloft.net
Cc: <stable@kernel.org>, <stable-commits@vger.kernel.org>
From: <gregkh@suse.de>
Date: Fri, 16 Nov 2007 10:08:58 -0800
Message-Id: <20071116180937.250A0144AB0C@imap.suse.de>
Sender: stable-commits-owner@vger.kernel.org
Precedence: bulk
Reply-To: linux-kernel@vger.kernel.org
X-Mailing-List: stable-commits@vger.kernel.org
[-- Attachment #2.1.2: Type: message/delivery-status, Size: 473 bytes --]
[-- Attachment #2.1.3: Type: message/rfc822, Size: 3603 bytes --]
From: <gregkh@suse.de>
To: ilpo.jarvinen@helsinki.fi, davem@davemloft.net
Cc: <stable@kernel.org>, <stable-commits@vger.kernel.org>
Subject: patch tcp-make-sure-write_queue_from-does-not-begin-with-null-ptr.patch queued to -stable tree
Date: Fri, 16 Nov 2007 10:08:58 -0800
Message-ID: <20071116180937.250A0144AB0C@imap.suse.de>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2.1.3.1: Type: text/plain, Size: 2368 bytes --]
From: <gregkh@suse.de>
To: ilpo.jarvinen@helsinki.fi, davem@davemloft.net
Cc: <stable@kernel.org>, <stable-commits@vger.kernel.org>
Subject: patch tcp-make-sure-write_queue_from-does-not-begin-with-null-ptr.patch queued to -stable tree
Date: Fri, 16 Nov 2007 10:08:58 -0800
Message-ID: <20071116180937.250A0144AB0C@imap.suse.de>
This is a note to let you know that we have just queued up the patch titled
Subject: TCP: Make sure write_queue_from does not begin with NULL ptr (CVE-2007-5501)
to the 2.6.23-stable tree. Its filename is
tcp-make-sure-write_queue_from-does-not-begin-with-null-ptr.patch
A git repo of this tree can be found at
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>From 96a2d41a3e495734b63bff4e5dd0112741b93b38 Mon Sep 17 00:00:00 2001
From: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Date: Wed, 14 Nov 2007 15:47:18 -0800
Subject: TCP: Make sure write_queue_from does not begin with NULL ptr (CVE-2007-5501)
From: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
patch 96a2d41a3e495734b63bff4e5dd0112741b93b38 in mainline.
NULL ptr can be returned from tcp_write_queue_head to cached_skb
and then assigned to skb if packets_out was zero. Without this,
system is vulnerable to a carefully crafted ACKs which obviously
is remotely triggerable.
Besides, there's very little that needs to be done in sacktag
if there weren't any packets outstanding, just skipping the rest
doesn't hurt.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/tcp_input.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1012,6 +1012,9 @@ tcp_sacktag_write_queue(struct sock *sk,
if (before(TCP_SKB_CB(ack_skb)->ack_seq, prior_snd_una - tp->max_window))
return 0;
+ if (!tp->packets_out)
+ goto out;
+
/* SACK fastpath:
* if the only SACK change is the increase of the end_seq of
* the first block then only apply that SACK block
@@ -1280,6 +1283,8 @@ tcp_sacktag_write_queue(struct sock *sk,
(!tp->frto_highmark || after(tp->snd_una, tp->frto_highmark)))
tcp_update_reordering(sk, ((tp->fackets_out + 1) - reord), 0);
+out:
+
#if FASTRETRANS_DEBUG > 0
BUG_TRAP((int)tp->sacked_out >= 0);
BUG_TRAP((int)tp->lost_out >= 0);
Patches currently in stable-queue which might be from ilpo.jarvinen@helsinki.fi are
queue-2.6.23/tcp-make-sure-write_queue_from-does-not-begin-with-null-ptr.patch
-
To unsubscribe from this list: send the line "unsubscribe stable-commits" 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] Fix t7004 which fails with retarded sed
From: Junio C Hamano @ 2007-11-16 18:26 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <1195233971-12288-1-git-send-email-mh@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> Brown paper bag fix to avoid test failure with retarded sed. The test
> by itself didn't catch what it was supposed to, anyways.
I'd rather not to say "retarded sed". It is not fair to blame
the implementation when the script we feed to it is not
portable.
> 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
> + grep -e "^$" actual > /dev/null 2>&1 &&
> + grep -e "^#" actual > /dev/null 2>&1 &&
> + ! grep -e "^[^#]" actual > /dev/null 2>&1
The test simulates a case where
$ git tag -a initial-comment
is run and the user exits the editor without editing the file to
add any text to annotate the tag. The behaviour we want from
such an invocation is (1) the user sees a sensible template in
the editor, and (2) the command to error out, saying "Hey, you
did not leave any message for us to use".
So the earlier part of the test
GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
is already bogus with respect to the latter point. It will
happily continue if "git tag" erroneously returns success, and
the above does not catch it.
if GIT_EDITOR=cat git tag -a initial-comment >actual
then
echo >&2 oops we should have errored out
false
else
: happy -- anything else we want to check?
fi
The "actual" file contains what the user saw in the editor and
returned to the "git tag" command.
The template we give to the user begins with a blank line,
followed by a brief instruction "write a tag message" as
comments to be stripped. The test is trying to make sure that
is what was given to the user. As you already discussed in the
thread, the exact wording may change in the future and we would
not want to adjust the test every time.
I think the important points about this template are:
* It begins with a single blank line, where the invoked editor
would typically place the editing curser at so that the user
can immediately start typing;
* It has some instruction but that comes after that initial
blank line, all lines prefixed with "#". I do not think we
would want to check the wording of this instruction.
* And it has nothing else, as the expected behaviour is "Hey
you did not leave any message".
^ permalink raw reply
* Fwd: problem with a fork on repo.or.cz
From: Benoit Sigoure @ 2007-11-16 18:07 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <97E2BA6B-E66F-45BB-BA74-C73E7E2918FC@lrde.epita.fr>
[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]
Hi list,
Petr did not reply to my email, so even though this is off-topic WRT
Git (forgive me please :D), I guess someone on this ML may be able to
have a clue.
Begin forwarded message:
> From: Benoit Sigoure <tsuna@lrde.epita.fr>
> Date: November 12, 2007 10:06:02 AM CEST
> To: Petr Baudis <pasky@suse.cz>
> Subject: problem with a fork on repo.or.cz
>
> Hi Petr,
>
> I'd like to use repo.or.cz to publish my patches for Autoconf. I
> created a new
> `autoconf' project that mirrors the GNU Autoconf Git repository.
> Then I forked it as
> autoconf/tsuna (http://repo.or.cz/w/autoconf/tsuna.git). Now I'm
> trying to push my
> changes to that repo but, for some reason, it fails:
>
> $ git remote show repo
> * remote repo
> URL: git+ssh://repo.or.cz/srv/git/autoconf/tsuna.git
> $ git push -v --all repo
> Pushing to git+ssh://repo.or.cz/srv/git/autoconf/tsuna.git
> updating 'refs/heads/bootclean'
> from 0000000000000000000000000000000000000000
> to 793c1b38a094f57e6218653719bca30881cca5d0
> updating 'refs/heads/docfix'
> from 0000000000000000000000000000000000000000
> to e61c348bcd8036ab76deedf0952215d64a6cbfcb
> updating 'refs/heads/master'
> from 0000000000000000000000000000000000000000
> to 00865ec8426eed430d9a36c906d6ce7d307f8cf1
> updating 'refs/heads/mybootclean'
> from 0000000000000000000000000000000000000000
> to 8475204ea4094c864a40216a93f176a817906744
> Counting objects: 63, done.
> Compressing objects: 100% (45/45), done.
> Writing objects: 100% (45/45), done.
> Total 45 (delta 40), reused 0 (delta 0)
> error: unable to create temporary sha1 filename ./objects/
> tmp_obj_XTRbjJ: Permission denied
> fatal: failed to write object
> unpack unpacker exited with error code
> ng refs/heads/bootclean n/a (unpacker error)
> ng refs/heads/docfix n/a (unpacker error)
> ng refs/heads/master n/a (unpacker error)
> ng refs/heads/mybootclean n/a (unpacker error)
> error: failed to push to 'git+ssh://repo.or.cz/srv/git/autoconf/
> tsuna.git'
> $ git version
> git version 1.5.3.5.654.gdd5ec
>
>
> any idea?
>
> Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix t7004 which fails with retarded sed
From: Wincent Colaiuta @ 2007-11-16 18:02 UTC (permalink / raw)
To: Mike Hommey; +Cc: git, Junio C Hamano
In-Reply-To: <1195233971-12288-1-git-send-email-mh@glandium.org>
El 16/11/2007, a las 18:26, Mike Hommey escribió:
> diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
> index 096fe33..3813f23 100755
> --- a/t/t7004-tag.sh
> +++ b/t/t7004-tag.sh
> @@ -1007,7 +1007,9 @@ 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
> + grep -e "^$" actual > /dev/null 2>&1 &&
> + grep -e "^#" actual > /dev/null 2>&1 &&
> + ! grep -e "^[^#]" actual > /dev/null 2>&1
> '
Yep, that works here, and is a much more rigourous test than what we
had.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Fix t7004 which fails with retarded sed
From: Benoit Sigoure @ 2007-11-16 17:58 UTC (permalink / raw)
To: Mike Hommey; +Cc: Git Mailing List
In-Reply-To: <1195233971-12288-1-git-send-email-mh@glandium.org>
[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]
On Nov 16, 2007, at 6:26 PM, Mike Hommey wrote:
> Brown paper bag fix to avoid test failure with retarded sed. The test
> by itself didn't catch what it was supposed to, anyways.
>
> So now, we test whether the editor gets at least an empty line, some
> commented lines, and doesn't get anything else.
>
> Signed-off-by: Mike Hommey <mh@glandium.org>
> ---
> t/t7004-tag.sh | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
> index 096fe33..3813f23 100755
> --- a/t/t7004-tag.sh
> +++ b/t/t7004-tag.sh
> @@ -1007,7 +1007,9 @@ 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
> + grep -e "^$" actual > /dev/null 2>&1 &&
> + grep -e "^#" actual > /dev/null 2>&1 &&
> + ! grep -e "^[^#]" actual > /dev/null 2>&1
> '
>
> get_tag_header reuse $commit commit $time >expect
If your system has a retarded `sed', it will most likely also have a
brain-dead `/bin/sh' which doesn't handle `! command'. So I suggest
you rewrite the last line as:
grep -ve "^[^#]" actual > /dev/null 2>&1
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix t9101 test failure caused by Subversion "auto-props"
From: Benoit Sigoure @ 2007-11-16 17:56 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Björn Steinbrink, Git Mailing List,
Väinö Järvelä, Junio Hamano
In-Reply-To: <2F7DFDC9-D4E2-42D0-9E48-E51E7905FF42@wincent.com>
[-- Attachment #1: Type: text/plain, Size: 1720 bytes --]
On Nov 16, 2007, at 2:25 PM, Wincent Colaiuta wrote:
> If a user has an "auto-prop" in his/her ~/.subversion/config file for
> automatically setting the svn:keyword Id property on all ".c" files
> (a reasonably common configuration in the Subversion world) then one
> of the "svn propset" operations in the very first test would become a
> no-op, which in turn would make the next commit a no-op.
>
> This then caused the 25th test ('test propget') to fail because it
> expects a certain number of commits to have taken place but the actual
> number of commits was off by one.
>
> Björn Steinbrink identified the "auto-prop" feature as the cause
> of the failure. This patch avoids it by passing the "--no-auto-prop"
> flag to "svn import" when setting up the test repository, thus
> ensuring
> that the "svn propset" operation is no longer a no-op, regardless
> of the
> users' settings in their config.
>
> Signed-off-by: Wincent Colaiuta <win@wincent.com>
> ---
> t/t9101-git-svn-props.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/t/t9101-git-svn-props.sh b/t/t9101-git-svn-props.sh
> index 3c83127..d7a7047 100755
> --- a/t/t9101-git-svn-props.sh
> +++ b/t/t9101-git-svn-props.sh
> @@ -48,7 +48,7 @@ EOF
> printf "\r\n" > empty_crlf
> a_empty_crlf=`git-hash-object -w empty_crlf`
>
> - svn import -m 'import for git-svn' . "$svnrepo" >/dev/null
> + svn import --no-auto-props -m 'import for git-svn' .
> "$svnrepo" >/dev/null
> cd ..
>
> rm -rf import
Great, thank you for tackling this issue. It wasn't easy to find.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* [PATCH] Fix t7004 which fails with retarded sed
From: Mike Hommey @ 2007-11-16 17:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20071116165944.GB29272@glandium.org>
Brown paper bag fix to avoid test failure with retarded sed. The test
by itself didn't catch what it was supposed to, anyways.
So now, we test whether the editor gets at least an empty line, some
commented lines, and doesn't get anything else.
Signed-off-by: Mike Hommey <mh@glandium.org>
---
t/t7004-tag.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 096fe33..3813f23 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1007,7 +1007,9 @@ 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
+ grep -e "^$" actual > /dev/null 2>&1 &&
+ grep -e "^#" actual > /dev/null 2>&1 &&
+ ! grep -e "^[^#]" actual > /dev/null 2>&1
'
get_tag_header reuse $commit commit $time >expect
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH v2] Fix git-tag test breakage caused by broken sed on Leopard
From: Wincent Colaiuta @ 2007-11-16 17:25 UTC (permalink / raw)
To: Mike Hommey; +Cc: Junio C Hamano, Johannes Schindelin, Git Mailing List
In-Reply-To: <20071116165944.GB29272@glandium.org>
El 16/11/2007, a las 17:59, Mike Hommey escribió:
> On Fri, Nov 16, 2007 at 02:48:09PM +0100, Wincent Colaiuta wrote:
>> El 16/11/2007, a las 14:45, Wincent Colaiuta escribió:
>>
>>> El 16/11/2007, a las 6:14, Junio C Hamano escribió:
>>>
>>>> Wincent Colaiuta <win@wincent.com> writes:
>>>>
>>>>> 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
>>>>> '
>>>>
>>>> Heh, doesn't grep exit with zero only when it found some lines
>>>> that match the pattern already? What's that "wc -l" for?
>>>
>>>
>>> I was just trying to make the minimal change (swapping grep for
>>> sed), but if you want a shorter version then we don't even need the
>>> "test"; it could just be:
>>>
>>> - test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
>>> + grep -e "^#" -e "^\$" actual
>>
>> Although I don't know if we should be testing for empty lines there
>> because an 0-byte empty "actual" file would spuriously pass the test.
>> Perhaps this would be better:
>>
>> - test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
>> + grep -e "^#" actual
>
> Matching both would as in your previous pseudo patch wouldn't catch
> empty file. On the other hand, both my initial bloated version and
> yours
> won't catch a file that doesn't contain the comment.
But if git-tag works then it will contain a comment; and isn't the
purpose of the test to confirm the comment's presence?
> grep -e "^$" actual && grep -e "^#" actual would actually be a better
> test.
What are we really trying to test here? The test is labelled as
'message in editor has initial comment'. Basically the editor will be
prepopulated with a blank line followed by this:
#
# Write a tag message
#
So it's the presence of that text which we want to confirm.
If I understand the intent of the original sed-based test, it was to
confirm that there were 1 or more lines that started with "#" or were
empty. It also suffered from the bug that an empty message (by which I
mean a 1-byte file containing only an LF) would pass the test
(spuriously in my opinion), and my first attempt faithfully translated
that bug into grep syntax.
The alternative you suggest will (correctly) fail on a zero byte file,
and pass on 1-byte file containing only a LF, just like the other
approaches. So I'm still wondering, what is it that we're trying to
test here? We could test for the exact "Write a tag message" text, but
that may be brittle (must be updated if/when the text ever changes),
but looking at other tests I see there are some which do precise
equality tests for expected results.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH v2] Fix git-tag test breakage caused by broken sed on Leopard
From: Mike Hommey @ 2007-11-16 16:59 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Junio C Hamano, Johannes Schindelin, Git Mailing List
In-Reply-To: <03D3DFCD-B5F7-47CF-AFD2-F1408BB11AB3@wincent.com>
On Fri, Nov 16, 2007 at 02:48:09PM +0100, Wincent Colaiuta wrote:
> El 16/11/2007, a las 14:45, Wincent Colaiuta escribió:
>
> > El 16/11/2007, a las 6:14, Junio C Hamano escribió:
> >
> >> Wincent Colaiuta <win@wincent.com> writes:
> >>
> >>> 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
> >>> '
> >>
> >> Heh, doesn't grep exit with zero only when it found some lines
> >> that match the pattern already? What's that "wc -l" for?
> >
> >
> > I was just trying to make the minimal change (swapping grep for
> > sed), but if you want a shorter version then we don't even need the
> > "test"; it could just be:
> >
> > - test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
> > + grep -e "^#" -e "^\$" actual
>
> Although I don't know if we should be testing for empty lines there
> because an 0-byte empty "actual" file would spuriously pass the test.
> Perhaps this would be better:
>
> - test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
> + grep -e "^#" actual
Matching both would as in your previous pseudo patch wouldn't catch
empty file. On the other hand, both my initial bloated version and yours
won't catch a file that doesn't contain the comment.
grep -e "^$" actual && grep -e "^#" actual would actually be a better
test.
Mike
^ 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