Re: [ANNOUNCE] Git v2.0.0-rc0
Johan Herland 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=;;
> 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 Wed, Apr 23, 2014 at 12:47 AM, Junio C Hamano wrote:
> "brian m. carlson" 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=;;
When passed to 'init' or 'clone' this regular expression will
...Johan
--
Johan Herland,
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
"brian m. carlson" 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
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. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [ANNOUNCE] Git v2.0.0-rc0
Junio C Hamano wrote: > Jonathan Nieder writes: >> The documentation says >> >> --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 # 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
Jonathan Nieder writes: > Junio C Hamano wrote: >> Jonathan Nieder 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= > > ... > > 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 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= ... 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 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
"Kyle J. McKay" 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
> ---
> 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="" 2>warning &&
> + git svn init -s "$svnrepo"/project project --prefix "" 2>warning &&
> 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="" 2>warning &&
> + git svn clone -s "$svnrepo"/project --prefix "" 2>warning &&
> 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
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
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
---
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="" 2>warning &&
+ git svn init -s "$svnrepo"/project project --prefix "" 2>warning &&
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="" 2>warning &&
+ git svn clone -s "$svnrepo"/project --prefix "" 2>warning &&
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
Felipe Contreras writes: > 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? Yikes, no. This was me mischaracterizingg the merge at 90e6255a6d01 (Merge branch 'fc/transport-helper-fixes', 2014-03-18). It was about letting the transport respond to 'force', and not about ref mapping, I think. Thanks for spotting. Will remove that section from the release notes in the meantime. As to the resurrection of the series, that will have to cook outside 'master' at least for the remainder of this cycle. -- 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 writes: > On Fri, Apr 18, 2014 at 9:37 PM, Junio C Hamano 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 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, 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
