Re: [RFC/PATCH] git svn: Set default --prefix='origin/' if --prefix is not given

From: Johan Herland <johan@herland.net>
Date: Oct 1, 2013, 06:12 UTC
Message-ID: <CALKQrgf0tBN9ymZ0Yq6iW95dwayhJC1a_9LZBagW6B_hBo5owA@mail.gmail.com>
In-Reply-To: <20131001040752.GA882@dcvr.yhbt.net>

On Tue, Oct 1, 2013 at 6:07 AM, Eric Wong <normalperson@yhbt.net> wrote:

Show 18 quoted lines

> Johan Herland <johan@herland.net> wrote:
>> git-svn by default puts its Subversion-tracking refs directly in
>> refs/remotes/*. This runs counter to Git's convention of using
>> refs/remotes/$remote/* for storing remote-tracking branches.
>
>> Furthermore, combining git-svn with regular git remotes run the risk of
>> clobbering refs under refs/remotes (e.g. if you have a git remote
>> called "tags" with a "v1" branch, it will overlap with the git-svn's
>> tracking branch for the "v1" tag from Subversion.
>>
>> Even though the git-svn refs stored in refs/remotes/* are not "proper"
>> remote-tracking branches (since they are not covered by a proper git
>> remote's refspec), they clearly represent a similar concept, and would
>> benefit from following the same convention.
>
> I regretted my original naming shortly after introducing it (IIRC,
> git-svn was the first refs/remotes/* user).  However, this risks
> breaking existing code and 3rd-party docs/tutorials.

True. Although the patch does not affect existing git-svn configurations, it does affect all future (where the user does not pass --prefix), and all documentation and scripts that will come to work on those must be adjusted accordingly.

> How about we put a big warning of impending change in there for now and
> wait until git 1.9/2.0 to make the actual change?

Sounds sensible. What should the warning look like, and where should it be placed? I'm thinking that if you run git svn init/clone without --prefix, there should be a verbose warning explaining (a) the trouble you're likely to encounter when using no prefix, and (b) the upcoming change in default prefix. Obviuosly, there should be a corresponding note in the git-svn manual page. Any other places in git.git that warrants changing? Hopefully this should be sufficient to trigger corresponding adjustments in third-party tools + docs ahead of the actual change in 1.9/2.0.

> Thanks for bringing this up again!

Thanks for your comments!

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net