Re: git-svn and mergeinfo

From: Bryan Jacobs <bjacobs@woti.com>
Date: Sep 1, 2011, 14:43 UTC
Message-ID: <20110901104327.14d4dba6@robyn.woti.com>
In-Reply-To: <4E5F4987.5040205@alum.mit.edu>

On Thu, 01 Sep 2011 10:59:51 +0200 Michael Haggerty <mhagger@alum.mit.edu> wrote:

Show 26 quoted lines

> On 08/29/2011 07:20 PM, Bryan Jacobs wrote:
> > I have been (ab)using git-svn for committing to a central SVN
> > repository while doing my work locally with git. To this end, I've
> > written a set of scripts and hooks which perform squash merges
> > locally and then dcommit them with proper svn:mergeinfo
> > annotations. The final result is the perfect appearance of having
> > done a native SVN merge in the central repository, while using only
> > local git commands and gaining the full benefit of git's conflict
> > resolution and developer convenience.
> > 
> > However, to make this work with git 1.7.6, I needed to make *one*
> > change to the git internals: --merge-info does not allow setting
> > mergeinfo for more than one branch. Because it's a complete
> > overwrite operation instead of an update, this is a serious issue
> > preventing its use for nontrivial branches.
> > 
> > Might I suggest adding a block like the following around line 552 of
> > git-svn?
> > 
> >     if (defined($_merge_info))
> >     {  
> >         $_merge_info =~ tr{ }{\n};
> >     }
> 
> Naive question: why can't you pass a newline (properly quoted, of
> course) directly within the string argument to the --mergeinfo option?

The only way I know of to do that in bash is to assign the newline-bearing string to a variable, and then use the variable in a command line option. Extremely awkward.

I think the long-term solution for this issue is probably to have git-svn populate the mergeinfo on its own, reducing the need for users manipulating the value directly. This could in theory be done for both cherry picks and merges, provided that the merge was --no-ff or bears a body (so there is a commit object to carry the property change) and both parents are tagged with SVN revs at the time the merge is dcommitted (or, correspondingly, that the cherry-pick source carries an SVN revision number). I will send patches for some to all of this shortly as I pull my bash scripts into git-svn.perl and clean up the code.

The cost of the automatic svn:mergeinfo pushing will be an SVN property retrieval before each dcommit operation. I plan to have this behavior disabled by default.

Bryan Jacobs