Re: [spf:guess] Re: [PATCH] Teach dcommit --mergeinfo to handle multiple lines

[Bryan Jacobs <bjacobs@woti.com>]

On Wed, 31 Aug 2011 13:43:39 -0700
Sam Vilain <sam@vilain.net> wrote:

> On 8/31/11 1:21 PM, Eric Wong wrote:
> >> --- a/Documentation/git-svn.txt
> >> +++ b/Documentation/git-svn.txt
> >> @@ -211,8 +211,9 @@ discouraged.
> >>   	Add the given merge information during the dcommit
> >>   	(e.g. `--mergeinfo="/branches/foo:1-10"`). All svn
> >> server versions can store this information (as a property), and
> >> svn clients starting from
> >> -	version 1.5 can make use of it. 'git svn' currently does
> >> not use it
> >> -	and does not set it automatically.
> >> +	version 1.5 can make use of it. To specify merge
> >> information from multiple
> >> +	branches, use a single space character between the
> >> branches
> >> +	(`--mergeinfo="/branches/foo:1-10 /branches/bar:3,5-6,8"`)
> 
> This interface seems regrettably stupid.  Like, do I need to consider 
> the existing revisions that are already listed in the property?  Is
> it really impossible to derive the changes that were merged and
> generate the list automatically?

Nope, it's possible. I didn't create the original --mergeinfo
interface. I was very surprised when I first discovered it clobbered
instead of integrating - it's easy to nuke your SVN repo's ability to
merge with one careless use of this option. See below.

> But so long as it makes something previously impossible possible, it
> is a good change - my feeling is that it should be called something
> like --mergeinfo-raw or --mergeinfo-set to leave room for a possible 
> --mergeinfo-add which knows how the lists work and adds them (which
> is what I'd expect a plain --mergeinfo switch to do).

I completely agree. I think there should at least be a
--mergeinfo-update which fetches the current revision, merges that with
the provided set using the branch paths as keys (and compacts using
svn:mergeinfo rules), and sets the property to the final result.

I actually do this currently with external scripts, which is why I
wanted to make --mergeinfo capable of delivering my final payload. It
would make my life easier if all the logic were part of git-svn instead.

That said, this change is really small. That change would be larger.
So I submitted this first.

> Sam