* Re: [PATCH] remote-hg: Fix biridectionality -> bidirectionality typos
From: Junio C Hamano @ 2013-01-08 17:32 UTC (permalink / raw)
To: W. Trevor King
Cc: Felipe Contreras, git, Jeff King, Sverre Rabbelier,
Johannes Schindelin, Ilari Liusvaara, Daniel Barkalow,
Michael J Gruber
In-Reply-To: <20130108154737.GA4662@odin.tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
>
> I was looking for one of my older messages to the Git list, and I
> found this, which seems to have fallen through the cracks:
Thanks; didn't Documentation/SubmittingPatches ask you not to do PGP
multipart but send patches in plain text?
> On Wed, Nov 28, 2012 at 03:23:20PM -0500, W. Trevor King wrote:
>> I'm not sure if this is the most recent patch iteration for this
>> feature, but I just saw this typo in `pu`.
>>
>> On Sun, Nov 04, 2012 at 03:13:29AM +0100, Felipe Contreras wrote:
>> > +# Commits are modified to preserve hg information and allow biridectionality.
>> ^^^^^^^^
>> s/biridectionality/bidirectionality/
>
> This fixes that instance (which has since landed in master) and
> another similar typo.
>
> contrib/remote-helpers/git-remote-hg | 2 +-
> contrib/remote-helpers/test-hg-bidi.sh | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
> index 016cdad..c700600 100755
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -31,7 +31,7 @@ import urllib
> # hg:
> # Emulate hg-git.
> # Only hg bookmarks are exported as git branches.
> -# Commits are modified to preserve hg information and allow biridectionality.
> +# Commits are modified to preserve hg information and allow bidirectionality.
> #
>
> NAME_RE = re.compile('^([^<>]+)')
> diff --git a/contrib/remote-helpers/test-hg-bidi.sh b/contrib/remote-helpers/test-hg-bidi.sh
> index a94eb28..1d61982 100755
> --- a/contrib/remote-helpers/test-hg-bidi.sh
> +++ b/contrib/remote-helpers/test-hg-bidi.sh
> @@ -6,7 +6,7 @@
> # https://bitbucket.org/durin42/hg-git/src
> #
>
> -test_description='Test biridectionality of remote-hg'
> +test_description='Test bidirectionality of remote-hg'
>
> . ./test-lib.sh
^ permalink raw reply
* Re: git push --recurse-submodules=on-demand with submodule push tag
From: Jens Lehmann @ 2013-01-08 17:33 UTC (permalink / raw)
To: 乙酸鋰; +Cc: git
In-Reply-To: <CAHtLG6TDqqG09WBkuWzGeWUGog6GOrWQZZtbF5xx_m4ishvzyQ@mail.gmail.com>
Am 08.01.2013 17:35, schrieb 乙酸鋰:
> In superproject, can I call git push --recurse-submodules=on-demand
> that pushes submodule with the submodule's tags?
As that seems to call a plain "git push" in the submodule I think
the tags won't be pushed by this command.
> Very often I change version and tag the submodule
> and change version and tag the superproject at the same time.
Won't "git submodule foreach 'git push --tags'" do what you want?
^ permalink raw reply
* Re: [PATCH] clone: forbid --bare --separate-git-dir <dir>
From: Junio C Hamano @ 2013-01-08 17:45 UTC (permalink / raw)
To: Jens Lehmann
Cc: Duy Nguyen, Jonathan Nieder, git, Heiko Voigt, Manlio Perillo,
W. Trevor King
In-Reply-To: <50EC543D.5090100@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Am 08.01.2013 15:16, schrieb Duy Nguyen:
>> On Sun, Jan 06, 2013 at 02:19:48AM -0800, Jonathan Nieder wrote:
>>> Unfortunately we forgot to forbid the --bare
>>> --separate-git-dir combination. In practice, we know no one
>>> could be using --bare with --separate-git-dir because it is
>>> broken in the following way: <explanation here>. So it is
>>> safe to make good on our mistake and forbid the combination,
>>> making the command easier to explain.
>>>
>>> I don't know what would go in the <explanation here> blank above,
>>> though. Is it possible that some people are relying on this option
>>> combination?
>>
>> I can't say it's broken in what way. Maybe it's easier to just support
>> this case, it's not much work anyway. Jens, maybe squash this to your
>> original patch?
>
> I'd be fine with that, though my gut feeling is that this should
> be a patch of its own (My patch handles the git dir, your's handles
> a work tree issue).
I agree that these are totally unrelated issues.
After all, Jonathan's suggestion to forbid it was because the
combination does not make sense and does not have practical uses,
and forbidding it would make the command easier to explain than
leaving it accepted from the command line. If you choose to go in
the opposite direction and make "clone --bare --separate-git-dir" do
something useful, it should be explained very well in the
documentation part of the patch why such a combination is a good
idea, and in what situation the behaviour is useful and the user may
want to consider using it, I think.
^ permalink raw reply
* Re: Moving (renaming) submodules, recipe/script
From: W. Trevor King @ 2013-01-08 17:48 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Jonathan Nieder, Git, Peter Collingbourne
In-Reply-To: <50EC536D.8050606@web.de>
[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]
On Tue, Jan 08, 2013 at 06:12:13PM +0100, Jens Lehmann wrote:
> Am 08.01.2013 15:32, schrieb W. Trevor King:
> > The Git directory for the
> > submodule stays in .git/modules/submod-1/ (good), but the worktree in
> > .git/modules/submod-1/config still points to ../../../submod-1 (bad).
>
> You'll not only have to update the gitfile but also the core.worktree
> setting in the repo. Sorry I missed that when you posted your script.
My git-submodule-mv.sh script does update core.worktree. The problem
is that `git checkout`, `git merge`, etc. do not.
> > This means that submodule moves are possible, but anyone trying to
> > share them between several repositories (or trying to rebase across
> > the move within their own repository) is in for a world of suffering
> > ;). I'm not sure how this should be addressed, but I didn't see
> > anything handling it in Jens' new series.
>
> If you adjust core.worktree properly you'll just have the old
> submodule work tree lying around (just like you do after you rm'd
> it) and everything apart from that should just work.
>
> As I mentioned that will be fixed by recursive submodule checkout.
> I'll see if I can polish my preliminary branch so that interested
> people can play around with it if anyone is interested.
Sounds like a fix will be in here. I'll definitely help put the
branch through its paces ;).
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] remote-hg: Fix biridectionality -> bidirectionality typos
From: W. Trevor King @ 2013-01-08 17:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: Felipe Contreras, git, Jeff King, Sverre Rabbelier,
Johannes Schindelin, Ilari Liusvaara, Daniel Barkalow,
Michael J Gruber
In-Reply-To: <7vboczfunc.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 253 bytes --]
On Tue, Jan 08, 2013 at 09:32:07AM -0800, Junio C Hamano wrote:
> Thanks; didn't Documentation/SubmittingPatches ask you not to do PGP
> multipart but send patches in plain text?
Gah. I need to tell myself to reread that every time I send a patch
:p.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4] git-completion.bash: add support for path completion
From: Manlio Perillo @ 2013-01-08 17:54 UTC (permalink / raw)
To: Marc Khouzam
Cc: Junio C Hamano, git@vger.kernel.org, szeder@ira.uka.de,
felipe.contreras@gmail.com
In-Reply-To: <E59706EF8DB1D147B15BECA3322E4BDC0681FA@eusaamb103.ericsson.se>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 05/01/2013 21:23, Marc Khouzam ha scritto:
> [...]
> 4- Completion choices include their entire path, which is not what bash does by default. For example:
>> cd git/contrib
>> ls completion/git-<tab>
> git-completion.bash git-completion.tcsh git-completion.zsh git-prompt.sh
> but
>> git rm completion/git-<tab>
> completion/git-completion.bash completion/git-completion.tcsh completion/git-completion.zsh completion/git-prompt.sh
> notice the extra 'completion/' before each completion. This can get pretty large when completing with
> many directory prefixes. The current tcsh completion has the same problem which I couldn't fix. However, I am
> not sure if it can be fixed for bash.
>
> I personally don't think this is regression, just an slight annoyance.
>
After some searching, I found how this is supposed to be done.
It is possible to use the -o filenames option to tell Bash completion
that "the compspec generates filenames, so it can perform any
filename-specific processing".
Unfortunately this option must be passed to the complete builtin
command, and we can not do this, since the comspec not always contains
filenames.
> [...]
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDsXUEACgkQscQJ24LbaURMlgCdEyeSRTRktKtGuDxq4HX1meWt
IV4AmwS6wasCip+1u4vS2FwG8AlXXB7r
=pN8F
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] remote-hg: Fix biridectionality -> bidirectionality typos
From: Junio C Hamano @ 2013-01-08 18:10 UTC (permalink / raw)
To: W. Trevor King
Cc: Felipe Contreras, git, Jeff King, Sverre Rabbelier,
Johannes Schindelin, Ilari Liusvaara, Daniel Barkalow,
Michael J Gruber
In-Reply-To: <20130108175001.GG4662@odin.tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> On Tue, Jan 08, 2013 at 09:32:07AM -0800, Junio C Hamano wrote:
>> Thanks; didn't Documentation/SubmittingPatches ask you not to do PGP
>> multipart but send patches in plain text?
>
> Gah. I need to tell myself to reread that every time I send a patch
> :p.
No need to worry; thanks for a patch---applied to 'maint'.
^ permalink raw reply
* Re: [PATCH v4] git-completion.bash: add support for path completion
From: John Keeping @ 2013-01-08 18:05 UTC (permalink / raw)
To: Manlio Perillo
Cc: Marc Khouzam, Junio C Hamano, git@vger.kernel.org,
szeder@ira.uka.de, felipe.contreras@gmail.com
In-Reply-To: <50EC5D41.6030209@gmail.com>
On Tue, Jan 08, 2013 at 06:54:09PM +0100, Manlio Perillo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Il 05/01/2013 21:23, Marc Khouzam ha scritto:
>> [...]
>> 4- Completion choices include their entire path, which is not what bash does by default. For example:
>>> cd git/contrib
>>> ls completion/git-<tab>
>> git-completion.bash git-completion.tcsh git-completion.zsh git-prompt.sh
>> but
>>> git rm completion/git-<tab>
>> completion/git-completion.bash completion/git-completion.tcsh completion/git-completion.zsh completion/git-prompt.sh
>> notice the extra 'completion/' before each completion. This can get pretty large when completing with
>> many directory prefixes. The current tcsh completion has the same problem which I couldn't fix. However, I am
>> not sure if it can be fixed for bash.
>>
>> I personally don't think this is regression, just an slight annoyance.
>>
>
> After some searching, I found how this is supposed to be done.
> It is possible to use the -o filenames option to tell Bash completion
> that "the compspec generates filenames, so it can perform any
> filename-specific processing".
>
> Unfortunately this option must be passed to the complete builtin
> command, and we can not do this, since the comspec not always contains
> filenames.
You should also be able to pass it to 'compopt' during completion in
order to change the behaviour for only the current completion.
John
^ permalink raw reply
* submodule name and path
From: 乙酸鋰 @ 2013-01-08 18:17 UTC (permalink / raw)
To: git
Hi,
In doc, "submodule name" is not clearly mentioned?
What is the purpose of "submodule name"?
Must be same as "submodule path"?
"submodule path" can be repeated, while "submodule name" unique?
^ permalink raw reply
* Re: [PATCH v4] git-completion.bash: add support for path completion
From: Manlio Perillo @ 2013-01-08 18:28 UTC (permalink / raw)
To: John Keeping
Cc: Marc Khouzam, Junio C Hamano, git@vger.kernel.org,
szeder@ira.uka.de, felipe.contreras@gmail.com
In-Reply-To: <20130108180518.GO6440@serenity.lan>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 08/01/2013 19:05, John Keeping ha scritto:
> [...]
>>
>> After some searching, I found how this is supposed to be done.
>> It is possible to use the -o filenames option to tell Bash completion
>> that "the compspec generates filenames, so it can perform any
>> filename-specific processing".
>>
>> Unfortunately this option must be passed to the complete builtin
>> command, and we can not do this, since the comspec not always contains
>> filenames.
>
> You should also be able to pass it to 'compopt' during completion in
> order to change the behaviour for only the current completion.
>
Thanks, compopt is what I wanted.
I was reading an old Bash manual (for Bash 3.1), and compopt is only
available starting from Bash 4.0.
I will do some test, being careful to not break the code for Bash < 4.0
and the other supported shells.
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDsZVgACgkQscQJ24LbaUQlAACdGbhOuGICCYFwkRTPJla+3JGT
EcQAoINEGvdwtOz1QFbAA4FqoI3c7VSa
=5Oqw
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: submodule name and path
From: W. Trevor King @ 2013-01-08 18:29 UTC (permalink / raw)
To: 乙酸鋰; +Cc: git
In-Reply-To: <CAHtLG6TuHtk2P3w70-vUVGkdrv7R3VWyMzkGA4sr=G8xiSuEjA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 921 bytes --]
On Wed, Jan 09, 2013 at 02:17:42AM +0800, 乙酸鋰 wrote:
> In doc, "submodule name" is not clearly mentioned?
> What is the purpose of "submodule name"?
> Must be same as "submodule path"?
> "submodule path" can be repeated, while "submodule name" unique?
The submodule name starts out the same as the submodule path, but the
name stays constant through submodule moves, replacements, etc. The
constant name is useful because out-of-tree configuration (e.g. stuff
in .git/config and .git/modules/) won't have to adjust to submodule
renames (except for core.worktree in .git/modules/*/config).
See:
http://article.gmane.org/gmane.comp.version-control.git/49621
http://article.gmane.org/gmane.comp.version-control.git/206659
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 2/7] contrib/subtree: Use %B for Split Subject/Body
From: Junio C Hamano @ 2013-01-08 18:29 UTC (permalink / raw)
To: David A. Greene; +Cc: git, Techlive Zheng
In-Reply-To: <1357646997-28675-3-git-send-email-greened@obbligato.org>
"David A. Greene" <greened@obbligato.org> writes:
> From: Techlive Zheng <techlivezheng@gmail.com>
>
> Use %B to format the commit message and body to avoid an extra newline
> if a commit only has a subject line.
>
> Signed-off-by: Techlive Zheng <techlivezheng@gmail.com>
>
> Signed-off-by: David A. Greene <greened@obbligato.org>
> ---
This time (only), I'll try to fix them up at my end, but please
check your toolchain, find out where the extra blank line between
S-o-b: lines we see above come from, and fix that, so that I won't
have to do so again.
> contrib/subtree/git-subtree.sh | 6 +++++-
> contrib/subtree/t/t7900-subtree.sh | 15 +++++++++++++++
> 2 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
> index 920c664..5341b36 100755
> --- a/contrib/subtree/git-subtree.sh
> +++ b/contrib/subtree/git-subtree.sh
> @@ -296,7 +296,11 @@ copy_commit()
> # We're going to set some environment vars here, so
> # do it in a subshell to get rid of them safely later
> debug copy_commit "{$1}" "{$2}" "{$3}"
> - git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%s%n%n%b' "$1" |
> + # Use %B rather than %s%n%n%b to handle the special case of a
> + # commit that only has a subject line. We don't want to
> + # introduce a newline after the subject, causing generation of
> + # a new hash.
> + git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%B' "$1" |
The new format template is fine, but I do not think the comment
should be there. It does not give any useful information to people
who are reading the end result of applying this patch and is useful
only in the context of comparing the old and new templates, iow, it
belongs to the commit log message.
> (
> read GIT_AUTHOR_NAME
> read GIT_AUTHOR_EMAIL
> diff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t7900-subtree.sh
> index 6cf9fb9..3f17f55 100755
> --- a/contrib/subtree/t/t7900-subtree.sh
> +++ b/contrib/subtree/t/t7900-subtree.sh
> @@ -74,6 +74,10 @@ test_expect_success 'add sub1' '
> git branch -m master subproj
> '
>
> +# Save this hash for testing later.
> +
> +subdir_hash=`git rev-parse HEAD`
> +
> test_expect_success 'add sub2' '
> create sub2 &&
> git commit -m "sub2" &&
> @@ -211,6 +215,17 @@ test_expect_success 'check split with --branch' '
> check_equal ''"$(git rev-parse splitbr1)"'' "$spl1"
> '
>
> +test_expect_success 'check hash of split' '
> + spl1=$(git subtree split --prefix subdir) &&
> + undo &&
> + git subtree split --prefix subdir --branch splitbr1test &&
> + check_equal ''"$(git rev-parse splitbr1test)"'' "$spl1"
We'd need to clean up these no-op '' from this, but not doing so in
this patch is perfectly fine (and is even preferred).
> + git checkout splitbr1test &&
> + new_hash=$(git rev-parse HEAD~2) &&
> + git checkout mainline &&
> + check_equal ''"$new_hash"'' "$subdir_hash"
> +'
> +
> test_expect_success 'check split with --branch for an existing branch' '
> spl1=''"$(git subtree split --annotate='"'*'"' --prefix subdir --onto FETCH_HEAD --message "Split & rejoin" --rejoin)"'' &&
> undo &&
Thanks.
^ permalink raw reply
* troublesome branch name in remote repo causes .git/config inconsistency in cloned repo
From: Pavel Pospíšil @ 2013-01-08 18:30 UTC (permalink / raw)
To: git
Hi,
I think I came across a bug. I use git version 1.7.10.4 on Ubuntu
12.10. I haven't tried to find out if it's a known bug.
Reproduction scenario:
1. create a git repo:
$ mkdir -p tmp/bezdek
$ cd tmp/bezdek/
$ echo "*.swp" > .gitignore
$ git init
$ git add .
$ git commit -m "Initial commit"
2. clone the "remote" repo:
$ cd ../..
$ mkdir -p tmp/cloned
$ git clone ../bezdek/
3. create the troublesome branch in the "remote" repo
$ cd ../bezdek
$ git checkout -b
MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek
$ echo "*.bak" >> .gitignore
$ git add .
$ git commit -m "Some changes"
4. pull and checkout to the
MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek
branch in the cloned repo
$ cd ../cloned/bezdek
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = /home/pospispa/tmp/tmp/cloned/../bezdek/
[branch "master"]
remote = origin
merge = refs/heads/master
$ git pull
remote: Counting objects: 5, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 33% (1/3)
Unpacking objects: 66% (2/3)
Unpacking objects: 100% (3/3)
Unpacking objects: 100% (3/3), done.
From /home/pospispa/tmp/tmp/cloned/../bezdek
* [new branch]
MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek
-> origin/MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek
Already up-to-date.
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = /home/pospispa/tmp/tmp/cloned/../bezdek/
[branch "master"]
remote = origin
merge = refs/heads/master
$ git checkout MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek
fatal: bad config file line 12 in .git/config
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = /home/pospispa/tmp/tmp/cloned/../bezdek/
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek"]
remote = origin
I think that the problem may be with the branch name length. I think
that git branch allows to created branches with very long names,
however, such long name are not allowed in .git/config or the git
checkout <very-long-remote-branch-name> has some problems with it.
I recovered from this problem in this way:
1. deleted last two lines in tmp/cloned/bezdek/.git/config file and
deleted index and working tree
$ git reset HEAD *
$ git checkout -- *
2. renamed the troublesome branch in "remote" repo:
$ cd ../../bezdek
$ git branch -m
MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek
MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek
3. pull from "remote" to cloned again
$ cd ../cloned/bezdek
$ git pull
From /home/pospispa/tmp/tmp/cloned/../bezdek
* [new branch]
MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek ->
origin/MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek
Already up-to-date.
$ git branch -r
origin/HEAD -> origin/master
origin/MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek
origin/MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek
origin/master
$ git checkout MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek
Branch MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek
set up to track remote branch
MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek
from origin.
Switched to a new branch
'MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek'
Best regards,
Pavel Pospisil
^ permalink raw reply
* Re: [PATCH 3/7] contrib/subtree: Add --unannotate
From: Junio C Hamano @ 2013-01-08 18:45 UTC (permalink / raw)
To: David A. Greene; +Cc: git, James Nylen
In-Reply-To: <1357646997-28675-4-git-send-email-greened@obbligato.org>
"David A. Greene" <greened@obbligato.org> writes:
> diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt
> index c5bce41..75aa690 100644
> --- a/contrib/subtree/git-subtree.txt
> +++ b/contrib/subtree/git-subtree.txt
> @@ -198,6 +198,21 @@ OPTIONS FOR split
> git subtree tries to make it work anyway, particularly
> if you use --rejoin, but it may not always be effective.
>
> +--unannotate=<annotation>::
> + This option is only valid for the split command.
> +
> + When generating synthetic history, try to remove the prefix
> + <annotation> from each commit message (using bash's "strip
> + shortest match from beginning" command, which supports
> + globbing). This makes sense if you format library commits
> + like "library: Change something or other" when you're working
> + in your project's repository, but you want to remove this
> + prefix when pushing back to the library's upstream repository.
> + (In this case --unannotate='*: ' would work well.)
> +
> + Like --annotate, you need to use the same <annotation>
> + whenever you split, or you may run into problems.
I think this paragraph inherits existing breakage from the beginning
of time, but I do not think the above will format the second and
subsequent paragraphs correctly.
I've applied all seven patches in the series with minor fix-ups, and
will merge it to 'pu'.
Thanks.
^ permalink raw reply
* Re: [PATCH 4/7] contrib/subtree: Better Error Handling for add
From: Junio C Hamano @ 2013-01-08 18:45 UTC (permalink / raw)
To: David A. Greene; +Cc: git
In-Reply-To: <1357646997-28675-5-git-send-email-greened@obbligato.org>
"David A. Greene" <greened@obbligato.org> writes:
> From: "David A. Greene" <greened@obbligato.org>
>
> Check refspecs for validity before passing them on to other commands.
> This lets us generate more helpful error messages.
>
> Signed-off-by: David A. Greene <greened@obbligato.org>
> ---
> contrib/subtree/git-subtree.sh | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
> index cac0680..d53eaee 100755
> --- a/contrib/subtree/git-subtree.sh
> +++ b/contrib/subtree/git-subtree.sh
> @@ -508,12 +508,18 @@ cmd_add()
> ensure_clean
>
> if [ $# -eq 1 ]; then
> - "cmd_add_commit" "$@"
> + git rev-parse -q --verify "$1^{commit}" >/dev/null ||
> + die "'$1' does not refer to a commit"
Where do these uneven indentation come from? Is it mimicking
existing breakage in the script?
> +
> + "cmd_add_commit" "$@"
> elif [ $# -eq 2 ]; then
> - "cmd_add_repository" "$@"
> + git rev-parse -q --verify "$2^{commit}" >/dev/null ||
> + die "'$2' does not refer to a commit"
> +
> + "cmd_add_repository" "$@"
> else
> say "error: parameters were '$@'"
> - die "Provide either a refspec or a repository and refspec."
> + die "Provide either a commit or a repository and commit."
> fi
> }
^ permalink raw reply
* Re: [RFH] NetBSD 6?
From: Greg Troxel @ 2013-01-08 18:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvcbew895.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]
Junio C Hamano <gitster@pobox.com> writes:
>> [OLD_ICONV]
> It refers to the type of the second parameter to iconv(); OLD_ICONV
> makes it take "const char *", as opposed to "char *", the latter of
> which matches
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html
I just wanted to follow up on this. It turns out that the old POSIX
standard was buggy (header file and function spec were different), and
they resolved it in favor of non-const. NetBSD followed the const way,
and just now documented that with links to the standards email archives.
Interestingly, GNU iconv 1.14 seems to define it as const also:
https://www.gnu.org/savannah-checkouts/gnu/libiconv/documentation/libiconv-1.14/iconv.3.html
(which matches man/iconv.3 in the tarball).
When I build libiconv-1.14, it produces a .h with const. But it has a
configure test to check if there is a host include file with const, and
puts the const in the built header file or not to match!
In include/iconv.h.in, there is:
extern size_t iconv (iconv_t cd,
@ICONV_CONST@ char* * inbuf, size_t *inbytesleft,
char* * outbuf, size_t *outbytesleft);
Someday, it would be nice to have the configure test not fail an iconv
implementation just because of the const, unless the presence of const
is causing a real problem. But I can understand that no one thinks
that's important enough to get around to.
[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]
^ permalink raw reply
* Re: troublesome branch name in remote repo causes .git/config inconsistency in cloned repo
From: Junio C Hamano @ 2013-01-08 18:59 UTC (permalink / raw)
To: Pavel Pospíšil; +Cc: git
In-Reply-To: <CADDfn-L_VWk5Rkn_P8aTf3pwBcbbYT=PZTrG=pFvJpNjgRg-5A@mail.gmail.com>
Pavel Pospíšil <pospispa@gmail.com> writes:
> I think that the problem may be with the branch name length. I think
> that git branch allows to created branches with very long names,
> however, such long name are not allowed in .git/config ...
I think we lifted this limit back in 1.8.0.1 timeframe.
^ permalink raw reply
* Re: [RFH] NetBSD 6?
From: Junio C Hamano @ 2013-01-08 19:03 UTC (permalink / raw)
To: Greg Troxel; +Cc: git
In-Reply-To: <rmiobgz4icr.fsf@fnord.ir.bbn.com>
Greg Troxel <gdt@ir.bbn.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>>> [OLD_ICONV]
>
>> It refers to the type of the second parameter to iconv(); OLD_ICONV
>> makes it take "const char *", as opposed to "char *", the latter of
>> which matches
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html
>
> I just wanted to follow up on this. It turns out that the old POSIX
> standard was buggy (header file and function spec were different), and
> they resolved it in favor of non-const. NetBSD followed the const way,
> and just now documented that with links to the standards email archives.
>
> Interestingly, GNU iconv 1.14 seems to define it as const also:
>
> https://www.gnu.org/savannah-checkouts/gnu/libiconv/documentation/libiconv-1.14/iconv.3.html
>
> (which matches man/iconv.3 in the tarball).
>
> When I build libiconv-1.14, it produces a .h with const. But it has a
> configure test to check if there is a host include file with const, and
> puts the const in the built header file or not to match!
> In include/iconv.h.in, there is:
>
> extern size_t iconv (iconv_t cd,
> @ICONV_CONST@ char* * inbuf, size_t *inbytesleft,
> char* * outbuf, size_t *outbytesleft);
>
> Someday, it would be nice to have the configure test not fail an iconv
> implementation just because of the const, unless the presence of const
> is causing a real problem. But I can understand that no one thinks
> that's important enough to get around to.
Interesting.
Don't get too offended by the "OLD_" prefix to that symbol, by the
way. I do not think "old" means "old and broken hence fixed in
newer version and you are low life if you live on a platform that
has to define it" ;-).
We just needed to have a boolean to tell which variant it is to let
the compiler build objects without complaining, and we named that
switch as OLD_ICONV.
^ permalink raw reply
* Re: [RFH] NetBSD 6?
From: Greg Troxel @ 2013-01-08 19:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy5g3cx9v.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 841 bytes --]
Junio C Hamano <gitster@pobox.com> writes:
> Don't get too offended by the "OLD_" prefix to that symbol, by the
> way. I do not think "old" means "old and broken hence fixed in
> newer version and you are low life if you live on a platform that
> has to define it" ;-).
Thanks - it did throw me at the beginning, because I expected that it
lead to using a copy of GNU iconv and not using the native one.
But it will probably confuse few enough people that changing to
CONST_ICONV is not warranted...
> We just needed to have a boolean to tell which variant it is to let
> the compiler build objects without complaining, and we named that
> switch as OLD_ICONV.
I get that, now that I read utf8.c. It's amusing that git's own
function is const, and on non-OLD_ICONV platforms has to cast away the
const for standards-compliant iconv.
[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]
^ permalink raw reply
* [PATCH v3] git-fast-import(1): remove duplicate '--done' option
From: John Keeping @ 2013-01-08 19:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Eric S. Raymond, Sverre Rabbelier, git
In-Reply-To: <20130105160652.GE6440@serenity.lan>
The '--done' option to git-fast-import is documented twice in its manual
page. Combine the best bits of each description, keeping the location
of the instance that was added first.
Signed-off-by: John Keeping <john@keeping.me.uk>
---
The commit description gained some noise in v2; this version should be
the really correct, final version.
Sorry for the noise.
Documentation/git-fast-import.txt | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 68bca1a..4ef5721 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -39,10 +39,6 @@ OPTIONS
See ``Date Formats'' below for details about which formats
are supported, and their syntax.
--- done::
- Terminate with error if there is no 'done' command at the
- end of the stream.
-
--force::
Force updating modified existing branches, even if doing
so would cause commits to be lost (as the new commit does
@@ -108,7 +104,8 @@ OPTIONS
output.
--done::
- Require a `done` command at the end of the stream.
+ Terminate with error if there is no `done` command at the
+ end of the stream.
This option might be useful for detecting errors that
cause the frontend to terminate before it has started to
write a stream.
--
1.8.0.2
^ permalink raw reply related
* Re: [PATCH] wincred: improve compatibility with windows versions
From: Erik Faye-Lund @ 2013-01-08 20:13 UTC (permalink / raw)
To: blees; +Cc: git, msysgit, Jeff King
In-Reply-To: <50EC473A.6060203@gmail.com>
On Tue, Jan 8, 2013 at 5:20 PM, Karsten Blees <karsten.blees@gmail.com> wrote:
> Am 04.01.2013 22:57, schrieb Erik Faye-Lund:
>> The only reason why I used Cred[Un]PackAuthenticationBuffer, were that
>> I wasn't aware that it was possible any other way. I didn't even know
>> there was a Windows Credential Manager in Windows XP.
>>
>
> I believe the Cred* API was introduced in Win2k. The XP control panel applet supports domain credentials only, but cmdkey.exe from Windows Server 2003 can be used on XP to manage generic credentials.
>
Thanks for the background-info.
>> The credential attributes were because they were convenient, and I'm
>> not sure I understand what you mean about the Win7 credential manager
>> tools. I did test my code with it - in fact, it was a very useful tool
>> for debugging the helper.
>>
>> Are you referring to the credentials not *looking* like normal
>> HTTP-credentials?
>
> No, I was referring to creating / editing git credentials with Windows tools manually. For example, changing your password in control panel removes all credential attributes, so the current wincred won't find them any longer...same for git credentials created e.g. via 'cmdkey /generic:git:http://me@example.com /user:me /pass:secret'.
>
> The 'puzzling' part is that those credentials *look* exactly the same as if created by wincred, but they don't work. And wincred isn't exactly verbose in its error messages :-)
>
Right, thanks for clearing that up.
>> But, if we do any of these changes, does this mean I will lose my
>> existing credentials? It's probably not a big deal, but it's worth a
>> mention, isn't it?
>>
>
> Yes, existing stored credentials are lost after this patch. Will add a note to the commit message.
>
> We _could_ try to detect the old format, but I don't think it's worth the trouble.
>
Nah, I don't think it's worth the trouble. It's a bit unfortunate that
people might get stale credentials clogging up the system, but I don't
really thing this is a big deal.
>>> static int match_cred(const CREDENTIALW *cred)
>>> {
>>> - return (!wusername || !wcscmp(wusername, cred->UserName)) &&
>>> - match_attr(cred, L"git_protocol", protocol) &&
>>> - match_attr(cred, L"git_host", host) &&
>>> - match_attr(cred, L"git_path", path);
>>> + LPCWSTR target = cred->TargetName;
>>> + if (wusername && wcscmp(wusername, cred->UserName))
>>> + return 0;
>>> +
>>> + return match_part(&target, L"git", L":") &&
>>> + match_part(&target, protocol, L"://") &&
>>> + match_part(&target, wusername, L"@") &&
>>> + match_part(&target, host, L"/") &&
>>> + match_part(&target, path, L"");
>>> }
>>>
>>
>> Ugh, it feels a bit wrong to store and verify the username twice. Do
>> we really have to?
>>
>> The target needs to be unique, even if two different usernames are
>> stored for the same site under the same conditions. So probably. It
>> just doesn't feel quite right.
>>
>
> I don't really see why you would need several usernames to connect to the same target. I can imagine different credentials for reading / writing, but then the protocol would usually be different as well, wouldn't it? (e.g. http vs. ssh)
>
I can kind of make up some theoretical reasons, but they are a bit exotic ;)
> One of my interim solutions was to remove the username part from the URL entirely. That enabled me to change credentials in control panel (including the username), and wincred would use them. However, that version failed the 'helper can store multiple users' test, so I ended up with storing / checking username twice.
>
I don't think breaking this is a good idea. It just feels a bit silly,
but I see now that other applications does the same duplication. So
let's just stick to it, even if it's a bit icky ;)
^ permalink raw reply
* [PATCH] commit: make default of "cleanup" option configurable
From: Ralf Thielow @ 2013-01-08 20:16 UTC (permalink / raw)
To: git; +Cc: gitster, Ralf Thielow
The default of the "cleanup" option in "git commit"
is not configurable. Users who don't want to use the
default have to pass this option on every commit since
there's no way to configure it. This commit introduces
a new config option "commit.cleanup" which can be used
to change the default of the "cleanup" option in
"git commit".
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
---
Documentation/config.txt | 4 ++++
builtin/commit.c | 29 ++++++++++++++++++-----------
2 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 53c4ca1..3f76cd1 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -917,6 +917,10 @@ column.tag::
Specify whether to output tag listing in `git tag` in columns.
See `column.ui` for details.
+commit.cleanup::
+ This setting overrides the default of the `--cleanup` option in
+ `git commit`. See linkgit:git-commit[1] for details.
+
commit.status::
A boolean to enable/disable inclusion of status information in the
commit message template when using an editor to prepare the commit
diff --git a/builtin/commit.c b/builtin/commit.c
index d6dd3df..42acde7 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -103,7 +103,7 @@ static enum {
CLEANUP_NONE,
CLEANUP_ALL
} cleanup_mode;
-static char *cleanup_arg;
+const static char *cleanup_arg;
static enum commit_whence whence;
static int use_editor = 1, include_status = 1;
@@ -966,6 +966,20 @@ static const char *read_commit_message(const char *name)
return out;
}
+static void parse_cleanup_arg()
+{
+ if (!cleanup_arg || !strcmp(cleanup_arg, "default"))
+ cleanup_mode = use_editor ? CLEANUP_ALL : CLEANUP_SPACE;
+ else if (!strcmp(cleanup_arg, "verbatim"))
+ cleanup_mode = CLEANUP_NONE;
+ else if (!strcmp(cleanup_arg, "whitespace"))
+ cleanup_mode = CLEANUP_SPACE;
+ else if (!strcmp(cleanup_arg, "strip"))
+ cleanup_mode = CLEANUP_ALL;
+ else
+ die(_("Invalid cleanup mode %s"), cleanup_arg);
+}
+
static int parse_and_validate_options(int argc, const char *argv[],
const struct option *options,
const char * const usage[],
@@ -1044,18 +1058,9 @@ static int parse_and_validate_options(int argc, const char *argv[],
only_include_assumed = _("Clever... amending the last one with dirty index.");
if (argc > 0 && !also && !only)
only_include_assumed = _("Explicit paths specified without -i nor -o; assuming --only paths...");
- if (!cleanup_arg || !strcmp(cleanup_arg, "default"))
- cleanup_mode = use_editor ? CLEANUP_ALL : CLEANUP_SPACE;
- else if (!strcmp(cleanup_arg, "verbatim"))
- cleanup_mode = CLEANUP_NONE;
- else if (!strcmp(cleanup_arg, "whitespace"))
- cleanup_mode = CLEANUP_SPACE;
- else if (!strcmp(cleanup_arg, "strip"))
- cleanup_mode = CLEANUP_ALL;
- else
- die(_("Invalid cleanup mode %s"), cleanup_arg);
handle_untracked_files_arg(s);
+ parse_cleanup_arg();
if (all && argc > 0)
die(_("Paths with -a does not make sense."));
@@ -1320,6 +1325,8 @@ static int git_commit_config(const char *k, const char *v, void *cb)
include_status = git_config_bool(k, v);
return 0;
}
+ if (!strcmp(k, "commit.cleanup"))
+ return git_config_string(&cleanup_arg, k, v);
status = git_gpg_config(k, v, NULL);
if (status)
--
1.8.1.165.gd94bd4e.dirty
^ permalink raw reply related
* [PATCH] t1402: work around shell quoting issue on NetBSD
From: René Scharfe @ 2013-01-08 20:23 UTC (permalink / raw)
To: git discussion list; +Cc: Junio C Hamano, Jonathan Nieder, Michael Haggerty
The test fails for me on NetBSD 6.0.1 and reports:
ok 1 - ref name '' is invalid
ok 2 - ref name '/' is invalid
ok 3 - ref name '/' is invalid with options --allow-onelevel
ok 4 - ref name '/' is invalid with options --normalize
error: bug in the test script: not 2 or 3 parameters to test-expect-success
The alleged bug is in this line:
invalid_ref NOT_MINGW '/' '--allow-onelevel --normalize'
invalid_ref() constructs a test case description using its last argument,
but the shell seems to split it up into two pieces if it contains a
space. Minimal test case:
# on NetBSD with /bin/sh
$ a() { echo $#-$1-$2; }
$ t="x"; a "${t:+$t}"
1-x-
$ t="x y"; a "${t:+$t}"
2-x-y
$ t="x y"; a "${t:+x y}"
1-x y-
# and with bash
$ t="x y"; a "${t:+$t}"
1-x y-
$ t="x y"; a "${t:+x y}"
1-x y-
This may be a bug in the shell, but here's a simple workaround: Construct
the description string first and store it in a variable, and then use
that to call test_expect_success().
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
t/t1402-check-ref-format.sh | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/t1402-check-ref-format.sh b/t/t1402-check-ref-format.sh
index 1ae4d87..1a5a5f3 100755
--- a/t/t1402-check-ref-format.sh
+++ b/t/t1402-check-ref-format.sh
@@ -11,7 +11,8 @@ valid_ref() {
prereq=$1
shift
esac
- test_expect_success $prereq "ref name '$1' is valid${2:+ with options $2}" "
+ desc="ref name '$1' is valid${2:+ with options $2}"
+ test_expect_success $prereq "$desc" "
git check-ref-format $2 '$1'
"
}
@@ -22,7 +23,8 @@ invalid_ref() {
prereq=$1
shift
esac
- test_expect_success $prereq "ref name '$1' is invalid${2:+ with options $2}" "
+ desc="ref name '$1' is invalid${2:+ with options $2}"
+ test_expect_success $prereq "$desc" "
test_must_fail git check-ref-format $2 '$1'
"
}
--
1.7.12
^ permalink raw reply related
* Re: [PATCH] t1402: work around shell quoting issue on NetBSD
From: Junio C Hamano @ 2013-01-08 20:39 UTC (permalink / raw)
To: René Scharfe; +Cc: git discussion list, Jonathan Nieder, Michael Haggerty
In-Reply-To: <50EC8025.8000707@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> The test fails for me on NetBSD 6.0.1 and reports:
>
> ok 1 - ref name '' is invalid
> ok 2 - ref name '/' is invalid
> ok 3 - ref name '/' is invalid with options --allow-onelevel
> ok 4 - ref name '/' is invalid with options --normalize
> error: bug in the test script: not 2 or 3 parameters to test-expect-success
>
> The alleged bug is in this line:
>
> invalid_ref NOT_MINGW '/' '--allow-onelevel --normalize'
>
> invalid_ref() constructs a test case description using its last argument,
> but the shell seems to split it up into two pieces if it contains a
> space. Minimal test case:
>
> # on NetBSD with /bin/sh
> $ a() { echo $#-$1-$2; }
> $ t="x"; a "${t:+$t}"
> 1-x-
> $ t="x y"; a "${t:+$t}"
> 2-x-y
> $ t="x y"; a "${t:+x y}"
> 1-x y-
>
> # and with bash
> $ t="x y"; a "${t:+$t}"
> 1-x y-
> $ t="x y"; a "${t:+x y}"
> 1-x y-
>
> This may be a bug in the shell, but here's a simple workaround: Construct
> the description string first and store it in a variable, and then use
> that to call test_expect_success().
Interesting. I notice that t0008 added recently to 'pu' has the
same construct.
>
> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
> ---
> t/t1402-check-ref-format.sh | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/t/t1402-check-ref-format.sh b/t/t1402-check-ref-format.sh
> index 1ae4d87..1a5a5f3 100755
> --- a/t/t1402-check-ref-format.sh
> +++ b/t/t1402-check-ref-format.sh
> @@ -11,7 +11,8 @@ valid_ref() {
> prereq=$1
> shift
> esac
> - test_expect_success $prereq "ref name '$1' is valid${2:+ with options $2}" "
> + desc="ref name '$1' is valid${2:+ with options $2}"
> + test_expect_success $prereq "$desc" "
> git check-ref-format $2 '$1'
> "
> }
> @@ -22,7 +23,8 @@ invalid_ref() {
> prereq=$1
> shift
> esac
> - test_expect_success $prereq "ref name '$1' is invalid${2:+ with options $2}" "
> + desc="ref name '$1' is invalid${2:+ with options $2}"
> + test_expect_success $prereq "$desc" "
> test_must_fail git check-ref-format $2 '$1'
> "
> }
^ permalink raw reply
* Re: [PATCH] t1402: work around shell quoting issue on NetBSD
From: René Scharfe @ 2013-01-08 21:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: git discussion list, Jonathan Nieder, Michael Haggerty,
Adam Spiers
In-Reply-To: <7vr4lvcstt.fsf@alter.siamese.dyndns.org>
Am 08.01.2013 21:39, schrieb Junio C Hamano:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>> # on NetBSD with /bin/sh
>> $ a() { echo $#-$1-$2; }
>> $ t="x"; a "${t:+$t}"
>> 1-x-
>> $ t="x y"; a "${t:+$t}"
>> 2-x-y
>> $ t="x y"; a "${t:+x y}"
>> 1-x y-
>>
>> # and with bash
>> $ t="x y"; a "${t:+$t}"
>> 1-x y-
>> $ t="x y"; a "${t:+x y}"
>> 1-x y-
>>
>> This may be a bug in the shell, but here's a simple workaround: Construct
>> the description string first and store it in a variable, and then use
>> that to call test_expect_success().
>
> Interesting. I notice that t0008 added recently to 'pu' has the
> same construct.
A quick check shows that subtests 64-68 and 89-93 of t0008 fail for me
on Debian (10 in total) and subtests 64 and 89 fail on NetBSD (2 in
total). Unlike t1402 they don't report "bug in the test script".
t0008 only uses ${:+} substitution on variables that don't contain
spaces. With the test changed to store the description in a variable
first I still get the same 2 failures.
There must be something else going on here. The different results are
interesting, especially the higher number of failures on Debian.
René
^ 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