On Thu, 2011-09-01 at 10:43 -0400, Bryan Jacobs wrote:
> On Thu, 01 Sep 2011 10:59:51 +0200
> Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote:
>
> > 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.
You can also save the mergeinfo to a file, add the line, and use
--mergeinfo=$(cat /tmp/some-file) to set it. It is indeed awkward, but
blindly replacing every space with a newline is not always the right
option. If a merged directory contains a space, this change will break
the mergeinfo, even if you're properly quoting your variable or using
the $(cat /some/file) method.
Cheers,
cmn
Attachment:
signature.asc
Description: This is a digitally signed message part