Re: [ANNOUNCE] Git v2.0.0-rc0
On Wed, Apr 23, 2014 at 12:47 AM, Junio C Hamano gits...@pobox.com wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
What we could do instead is simply require a newer version of
Getopt::Long, which would let people continue using their ancient OSes
and install a newer version from CPAN if necessary. It's also the
proper way to specify the dependency.
Yes, but if its inability to properly grok --option= is the only
reason we want to add a dependency, wouldn't it suffice to simply
state in the documentation (1) how to recognise the symptom to see
if the version the user has is too old, e.g. if you see this error
message, run 'perl -v' to see if your perl is older than X,
etc. and (2) how to work it around, i.e. instead of giving an empty
value with --option='', say --option ''?
FWIW, the least intrusive approach is what I find most agreeable:
- Fix the tests to use --prefix instead of --prefix=
- Update the documentation like Junio suggests above.
- Reformat an example using --prefix
I.e. use Kyle's patch to t9117, plus something like this:
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 5b3c38d..9f579e0 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -91,6 +91,9 @@ COMMANDS
NOTE: Before Git v2.0, the default prefix was (no prefix). This
meant that SVN-tracking refs were put at refs/remotes/*, which is
incompatible with how Git's own remote-tracking refs are organized.
+If you still want the old default, you can get it by passing
+'--prefix ' on the command line ('--prefix=' may not work if
+your Perl's Getopt::Long is v2.37).
--ignore-paths=regex;;
When passed to 'init' or 'clone' this regular expression will
...Johan
--
Johan Herland, jo...@herland.net
www.herland.net
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v2.0.0-rc0
Johan Herland jo...@herland.net writes:
I.e. use Kyle's patch to t9117, plus something like this:
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 5b3c38d..9f579e0 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -91,6 +91,9 @@ COMMANDS
NOTE: Before Git v2.0, the default prefix was (no prefix). This
meant that SVN-tracking refs were put at refs/remotes/*, which is
incompatible with how Git's own remote-tracking refs are organized.
+If you still want the old default, you can get it by passing
+'--prefix ' on the command line ('--prefix=' may not work if
+your Perl's Getopt::Long is v2.37).
--ignore-paths=regex;;
When passed to 'init' or 'clone' this regular expression will
Thanks, will squash in.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v2.0.0-rc0
On Apr 18, 2014, at 12:37, Junio C Hamano wrote:
An early preview release Git v2.0.0-rc0 is now available for
testing at the usual places.
I have run into the following test failures with v2.0.0-rc0:
Test Summary Report
---
t9117-git-svn-init-clone.sh (Wstat: 256 Tests: 11 Failed: 2)
Failed tests: 10-11
Non-zero exit status: 1
Files=658, Tests=11878, 3684 wallclock secs
Result: FAIL
The cause of the failure in both tests is this:
$ git svn init -s $svnrepo/project project --prefix=
Option prefix requires an argument
The problem with --prefix= is this (from the Getopt::Long CHANGES file):
Changes in version 2.37
---
* Bugfix: With gnu_compat, --foo= will no longer trigger Option
requires an argument but return the empty string.
The system I ran the tests on happens to have Getopt::Long version 2.35.
The --prefix= option can be rewritten --prefix in both tests and then
they pass.
Alternatively this change can be made in git-svn.perl:
|diff --git a/git-svn.perl b/git-svn.perl
|index 7349ffea..284f458a 100755
|--- a/git-svn.perl
|+++ b/git-svn.perl
|@@ -149,7 +149,7 @@ my ($_trunk, @_tags, @_branches, $_stdlayout);
my %icv;
my %init_opts = ( 'template=s' = \$_template, 'shared:s' = \$_shared,
'trunk|T=s' = \$_trunk, 'tags|t=s@' = \@_tags,
- 'branches|b=s@' = \@_branches, 'prefix=s' = \$_prefix,
+ 'branches|b=s@' = \@_branches, 'prefix:s' = \$_prefix,
'stdlayout|s' = \$_stdlayout,
'minimize-url|m!' = \$Git::SVN::_minimize_url,
'no-metadata' = sub { $icv{noMetadata} = 1 },
Which makes the argument to --prefix optional (in which case it is set
to ).
I'm not really sure what the best thing to do here is. I thought the
documentation talked somewhere about using --prefix= (or just --prefix=)
to get the old behavior, but now I can't find that. In that
case I think probably just changing the tests to use --prefix
instead of --prefix= should take care of it especially since the log
message for fe191fca (which actually changes the default) talks about
using --prefix and not --prefix=. I have attached a patch below
(against master) to make that change to the two affected subtests of t9117.
--Kyle
8
Subject: [PATCH] t9117: use --prefix instead of --prefix=
Versions of Perl's Getopt::Long module before 2.37 do not contain
this fix that first appeared in Getopt::Long version 2.37:
* Bugfix: With gnu_compat, --foo= will no longer trigger Option
requires an argument but return the empty string.
Instead of using --prefix= use --prefix when testing an
explictly empty prefix string in order to work with older versions
of Perl's Getopt::Long module.
Signed-off-by: Kyle J. McKay mack...@gmail.com
---
t/t9117-git-svn-init-clone.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t9117-git-svn-init-clone.sh b/t/t9117-git-svn-init-clone.sh
index dfed76fe..a66f43c6 100755
--- a/t/t9117-git-svn-init-clone.sh
+++ b/t/t9117-git-svn-init-clone.sh
@@ -101,18 +101,18 @@ test_expect_success 'clone with -s/-T/-b/-t assumes
--prefix=origin/' '
rm -f warning
'
-test_expect_success 'init with -s/-T/-b/-t and --prefix= still works' '
+test_expect_success 'init with -s/-T/-b/-t and --prefix still works' '
test ! -d project
- git svn init -s $svnrepo/project project --prefix= 2warning
+ git svn init -s $svnrepo/project project --prefix 2warning
test_must_fail grep -q prefix warning
test_svn_configured_prefix
rm -rf project
rm -f warning
'
-test_expect_success 'clone with -s/-T/-b/-t and --prefix= still works' '
+test_expect_success 'clone with -s/-T/-b/-t and --prefix still works' '
test ! -d project
- git svn clone -s $svnrepo/project --prefix= 2warning
+ git svn clone -s $svnrepo/project --prefix 2warning
test_must_fail grep -q prefix warning
test_svn_configured_prefix
rm -rf project
--
1.8.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v2.0.0-rc0
Kyle J. McKay wrote:
The problem with --prefix= is this (from the Getopt::Long CHANGES file):
Changes in version 2.37
---
* Bugfix: With gnu_compat, --foo= will no longer trigger Option
requires an argument but return the empty string.
The system I ran the tests on happens to have Getopt::Long version 2.35.
Thanks for catching it.
Getopt::Long was updated to 2.37 in perl 5.8.9 (in 5.8.8 it was
updated to 2.35). INSTALL still only recommends Perl 5.8 so that's an
issue.
The --prefix= option can be rewritten --prefix in both tests and then
they pass.
Hm, perhaps we should introduce a 'no-prefix' option to work around
this.
|diff --git a/git-svn.perl b/git-svn.perl
|index 7349ffea..284f458a 100755
|--- a/git-svn.perl
|+++ b/git-svn.perl
|@@ -149,7 +149,7 @@ my ($_trunk, @_tags, @_branches, $_stdlayout);
my %icv;
my %init_opts = ( 'template=s' = \$_template, 'shared:s' = \$_shared,
'trunk|T=s' = \$_trunk, 'tags|t=s@' = \@_tags,
'branches|b=s@' = \@_branches, 'prefix=s' = \$_prefix,
+ 'no-prefix' = sub { $_prefix = },
'stdlayout|s' = \$_stdlayout,
'minimize-url|m!' = \$Git::SVN::_minimize_url,
'no-metadata' = sub { $icv{noMetadata} = 1 },
That way, normal usage of --prefix would still be consistent with
other git commands that prefer the form with argument attached
(--prefix=foo, not --prefix foo; see gitcli(7)).
Thoughts?
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v2.0.0-rc0
Kyle J. McKay mack...@gmail.com writes:
Alternatively this change can be made in git-svn.perl:
|diff --git a/git-svn.perl b/git-svn.perl
|index 7349ffea..284f458a 100755
|--- a/git-svn.perl
|+++ b/git-svn.perl
|@@ -149,7 +149,7 @@ my ($_trunk, @_tags, @_branches, $_stdlayout);
my %icv;
my %init_opts = ( 'template=s' = \$_template, 'shared:s' = \$_shared,
'trunk|T=s' = \$_trunk, 'tags|t=s@' = \@_tags,
- 'branches|b=s@' = \@_branches, 'prefix=s' = \$_prefix,
+ 'branches|b=s@' = \@_branches, 'prefix:s' = \$_prefix,
'stdlayout|s' = \$_stdlayout,
'minimize-url|m!' = \$Git::SVN::_minimize_url,
'no-metadata' = sub { $icv{noMetadata} = 1 },
Which makes the argument to --prefix optional (in which case it is set
to ).
We do want to learn what prefix the user wants to use when they
start their command line with git svn --prefix. Stopping the
command line right there and expecting it to default to whatever
built-in prefix is simply strange; the user could have omitted that
--prefix that lacks the argument. If the user did want us to use
the default by passing an empty string as its argument, both forms,
i.e. --prefix '' and --prefix='', ought to be usable, but if
older Getopt::Long() does not allow the latter form, at least the
former is the right way for the user to tell us that.
So I think your fix (workaround for a bug in older Getopt::Long) in
the patch is the right one. Johan may want to help me by pointing
out if I am missing something.
Thanks.
I'm not really sure what the best thing to do here is. I thought the
documentation talked somewhere about using --prefix= (or just --prefix=)
to get the old behavior, but now I can't find that. In that
case I think probably just changing the tests to use --prefix
instead of --prefix= should take care of it especially since the log
message for fe191fca (which actually changes the default) talks about
using --prefix and not --prefix=. I have attached a patch below
(against master) to make that change to the two affected subtests of t9117.
--Kyle
8
Subject: [PATCH] t9117: use --prefix instead of --prefix=
Versions of Perl's Getopt::Long module before 2.37 do not contain
this fix that first appeared in Getopt::Long version 2.37:
* Bugfix: With gnu_compat, --foo= will no longer trigger Option
requires an argument but return the empty string.
Instead of using --prefix= use --prefix when testing an
explictly empty prefix string in order to work with older versions
of Perl's Getopt::Long module.
Signed-off-by: Kyle J. McKay mack...@gmail.com
---
t/t9117-git-svn-init-clone.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t9117-git-svn-init-clone.sh b/t/t9117-git-svn-init-clone.sh
index dfed76fe..a66f43c6 100755
--- a/t/t9117-git-svn-init-clone.sh
+++ b/t/t9117-git-svn-init-clone.sh
@@ -101,18 +101,18 @@ test_expect_success 'clone with -s/-T/-b/-t assumes
--prefix=origin/' '
rm -f warning
'
-test_expect_success 'init with -s/-T/-b/-t and --prefix= still works' '
+test_expect_success 'init with -s/-T/-b/-t and --prefix still works' '
test ! -d project
- git svn init -s $svnrepo/project project --prefix= 2warning
+ git svn init -s $svnrepo/project project --prefix 2warning
test_must_fail grep -q prefix warning
test_svn_configured_prefix
rm -rf project
rm -f warning
'
-test_expect_success 'clone with -s/-T/-b/-t and --prefix= still works' '
+test_expect_success 'clone with -s/-T/-b/-t and --prefix still works' '
test ! -d project
- git svn clone -s $svnrepo/project --prefix= 2warning
+ git svn clone -s $svnrepo/project --prefix 2warning
test_must_fail grep -q prefix warning
test_svn_configured_prefix
rm -rf project
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v2.0.0-rc0
Jonathan Nieder jrnie...@gmail.com writes:
Hm, perhaps we should introduce a 'no-prefix' option to work around
this.
...
|diff --git a/git-svn.perl b/git-svn.perl
|index 7349ffea..284f458a 100755
|--- a/git-svn.perl
|+++ b/git-svn.perl
|@@ -149,7 +149,7 @@ my ($_trunk, @_tags, @_branches, $_stdlayout);
my %icv;
my %init_opts = ( 'template=s' = \$_template, 'shared:s' = \$_shared,
'trunk|T=s' = \$_trunk, 'tags|t=s@' = \@_tags,
'branches|b=s@' = \@_branches, 'prefix=s' = \$_prefix,
+ 'no-prefix' = sub { $_prefix = },
'stdlayout|s' = \$_stdlayout,
'minimize-url|m!' = \$Git::SVN::_minimize_url,
'no-metadata' = sub { $icv{noMetadata} = 1 },
That way, normal usage of --prefix would still be consistent with
other git commands that prefer the form with argument attached
(--prefix=foo, not --prefix foo; see gitcli(7)).
Thoughts?
I do not think that it is a good idea to use --no-anything for
something that is not a boolean.
I can buy --old-default-prefix, or --empty-prefix, but running
git svn --prefix '' (or --prefix='') would be OK and logically
consistent anyway (i.e. the option tells us what string to add after
refs/remotes/, and the old default that everybody hated were to
use an empty string), so...
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v2.0.0-rc0
Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: Hm, perhaps we should introduce a 'no-prefix' option to work around this. [...] That way, normal usage of --prefix would still be consistent with other git commands that prefer the form with argument attached (--prefix=foo, not --prefix foo; see gitcli(7)). Thoughts? I do not think that it is a good idea to use --no-anything for something that is not a boolean. Do you mean it is a bad idea to support or a bad idea to make use of such support? I suggested --no- for consistency with current git commands that use parseopt. But on second thought, I agree that it be confusing for --prefix=foo --no-prefix to mean something different from no --prefix parameter at all. The documentation says --prefix=prefix ... Before Git 2.0, the default prefix was (no prefix). This meant that ... which suggests that I can use --prefix= to mean no prefix. Perhaps it needs a note to suggest using '--prefix ' instead? Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v2.0.0-rc0
Jonathan Nieder jrnie...@gmail.com writes: Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: Hm, perhaps we should introduce a 'no-prefix' option to work around this. [...] That way, normal usage of --prefix would still be consistent with other git commands that prefer the form with argument attached (--prefix=foo, not --prefix foo; see gitcli(7)). Thoughts? I do not think that it is a good idea to use --no-anything for something that is not a boolean. Do you mean it is a bad idea to support or a bad idea to make use of such support? I suggested --no- for consistency with current git commands that use parseopt. But on second thought, I agree that it be confusing for --prefix=foo --no-prefix to mean something different from no --prefix parameter at all. The documentation says --prefix=prefix ... Before Git 2.0, the default prefix was (no prefix). This meant that ... which suggests that I can use --prefix= to mean no prefix. Perhaps it needs a note to suggest using '--prefix ' instead? Is there another --option that takes an arbitrary user string that could be an empty string (or will there be one in the future)? If that is the case, a better alternative might be to add an comment to say that those with older Getopt::Long may have to use --option instead of the --option= form for any option whose value happens to be an empty string to work around the command parser bug. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v2.0.0-rc0
Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: The documentation says --prefix=prefix ... Before Git 2.0, the default prefix was (no prefix). This meant that ... which suggests that I can use --prefix= to mean no prefix. Perhaps it needs a note to suggest using '--prefix ' instead? Is there another --option that takes an arbitrary user string that could be an empty string (or will there be one in the future)? In git in general, yes --- for example, 'git diff --src-prefix= HEAD^' tells git diff to leave off the usual c/ prefix in the src filename it prints. In git-svn, --trunk= or --message= might be meaningful, but not nearly as much as --prefix=. If that is the case, a better alternative might be to add an comment to say that those with older Getopt::Long may have to use --option instead of the --option= form for any option whose value happens to be an empty string to work around the command parser bug. Another possibility would be to require Perl 5.8.9 or newer. It was released in 2008. diff --git i/git-svn.perl w/git-svn.perl index 0a32372..ec7910d 100755 --- i/git-svn.perl +++ w/git-svn.perl @@ -1,7 +1,7 @@ #!/usr/bin/perl # Copyright (C) 2006, Eric Wong normalper...@yhbt.net # License: GPL v2 or later -use 5.008; +use 5.008_009; use warnings; use strict; use vars qw/ $AUTHOR $VERSION -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v2.0.0-rc0
brian m. carlson sand...@crustytoothpaste.net writes: On Tue, Apr 22, 2014 at 03:11:48PM -0700, Jonathan Nieder wrote: Another possibility would be to require Perl 5.8.9 or newer. It was released in 2008. RHEL 5 and CentOS 5 are still shipping with 5.8.8. They are still security-supported until 2017, and believe it or not people still develop on them. I am personally fine with this change, though. What we could do instead is simply require a newer version of Getopt::Long, which would let people continue using their ancient OSes and install a newer version from CPAN if necessary. It's also the proper way to specify the dependency. Yes, but if its inability to properly grok --option= is the only reason we want to add a dependency, wouldn't it suffice to simply state in the documentation (1) how to recognise the symptom to see if the version the user has is too old, e.g. if you see this error message, run 'perl -v' to see if your perl is older than X, etc. and (2) how to work it around, i.e. instead of giving an empty value with --option='', say --option ''? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [ANNOUNCE] Git v2.0.0-rc0
Junio C Hamano wrote: * transport-helper, fast-import and fast-export have been updated to allow the ref mapping and ref deletion in a way similar to the natively supported transports. Have they? % git --version git version 2.0.0.rc0 % git push origin origin master:foo /tmp/test[master] nysa searching for changes no changes found fatal: remote-helpers do not support old:new syntax ERROR: unhandled export command: I think you are missing the patches which I just resent[1]. [1] http://article.gmane.org/gmane.comp.version-control.git/246558 -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v2.0.0-rc0
Johan Herland jo...@herland.net writes: On Fri, Apr 18, 2014 at 9:37 PM, Junio C Hamano gits...@pobox.com wrote: An early preview release Git v2.0.0-rc0 is now available for testing at the usual places. This is supposed to have _all_ the v2.0 topics, correct? I'm unable to find the commit that actually _changes_ the default prefix for git svn (as announced in Documentation/git-svn.txt and the release notes for v1.8.5 and v1.9.0). Yes, I noticed that the topic has been in the release notes for a few cycles but the changes never came to my tree (perhaps review of the patch series never concluded?) at the beginning of this cycle, so dropped it from the release notes. For reference, it was posted as patch 3/3 back in October: http://thread.gmane.org/gmane.comp.version-control.git/232761/focus=235900 Very sorry for not discovering this earlier. Well, things happen X-. I see the other two contained in the merge from Eric at 1668b7d78f81 (Merge git://git.bogomips.org/git-svn, 2013-10-16). Is the last one still viable? From my point of view, it would be best if Eric can take another look on it and throw me a pull request (and I have to remember to resurrect the entry in the release notes). Alternatively I could revert the Warn about changing the default for now and defer the topic to v2.1. Eric, what do you think? My preference is not to revert but at the same time I am hesitant to take a patch that was posted as RFC this late in the cycle without input from the area expert, so... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v2.0.0-rc0
On Fri, Apr 18, 2014 at 9:37 PM, Junio C Hamano gits...@pobox.com wrote: An early preview release Git v2.0.0-rc0 is now available for testing at the usual places. This is supposed to have _all_ the v2.0 topics, correct? I'm unable to find the commit that actually _changes_ the default prefix for git svn (as announced in Documentation/git-svn.txt and the release notes for v1.8.5 and v1.9.0). For reference, it was posted as patch 3/3 back in October: http://thread.gmane.org/gmane.comp.version-control.git/232761/focus=235900 Very sorry for not discovering this earlier. ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
