git-svn and mergeinfo

Dear git Developers,

Apologies if this is not the right forum for bug reports. I was unable to find a Bugzilla/Redmine/Flyspray instance for issue maintenance, nor some "proper procedure" on the git web page.

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};
    }

This will replace any spaces in --merge-info with newlines, allowing specification of an svn:mergeinfo that contains merges from more than a singe branch. So the user can provide "--merge-info '/branch1:r2323-3849,r8888 /branch2:r9999'" and the like.

Thank you for your consideration. I am not subscribed to this list, so if there are any replies, please copy my address.

Bryan Jacobs

On Mon, Aug 29, 2011 at 01:20:52PM -0400, Bryan Jacobs wrote:

Yes, this is the right place. This question seems to be coming up a lot lately. And indeed, looking at the webpage and the wiki, we are not very clear that the mailing list is the place for such things.

Do you mind telling us where you looked? That will give us at least one spot that we know should be more clear. :)

In the meantime, I've updated:

  1. The GitCommunity wiki page to mention that bug reports should go
     to the list.

  2. Added an entry "How do I report a bug in git?" to the FAQ on the
     wiki.

  3. Sent Scott a patch for git-scm.org to mention bug reporting under
     the big "Got questions" banner on the front page that points people
     to the mailing list. Pull request is here:

       https://github.com/schacon/gitscm/pull/11

     It may make sense to have a specific page on reporting bugs, and
     link to it via a bigger "how to report bugs" somewhere on the front
     page of git-scm.org.

-Peff

On Mon, 29 Aug 2011 15:26:18 -0400 Jeff King <peff@peff.net> wrote:

I looked at the git-scm.com main page, the "documentation" sub-page, the wiki front page, and googled the site for terms like "issue tracker" and "bug reports", then read the FAQ.

Thank you very much for your efforts. It looks like you hit all but one of the places I looked. I agree that having a link from some part of the git-scm landing page would make sense, that's common practice for software projects and seems to me a logical place for it. I (obviously) read the text under the "got questions" bit; it was what sent me to this list. If it had said "report a bug here" I would have felt more confident about sending this message.

Bryan Jacobs

Jeff King <peff@peff.net> writes:

Thanks. I've also made sure that the very first paragraph of "A note fromt he maintainer" talks about it (yes it already does).

Heya,

On Mon, Aug 29, 2011 at 22:44, Junio C Hamano <gitster@pobox.com> wrote:

While we're at it, should we also make sure that these places mention Documentation/SubmittingPatches?

Heya,

On Mon, Aug 29, 2011 at 19:20, Bryan Jacobs <bjacobs@woti.com> wrote:

This is indeed the correct way of reporting bugs :).

Why not submit this as a proper patch [0] to the list, I reckon Eric (cc-ed, the maintainer of git-svn) wouldn't mind including it.

That's the policy on this list anyway :).

[0] http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/SubmittingPatches;hb=HEAD

On Wed, 31 Aug 2011 15:59:26 +0200 Sverre Rabbelier <srabbelier@gmail.com> wrote:

I have submitted a patch, following your conventions as best I could. I forgot the CC line, sorry Eric!

There was an inaccurate line in the documentation concerning the svn:mergeinfo property ("git-svn does not currently make use of this") which I clobbered with my documentation change. I did not document the whole of how "git svn fetch" deals with the property, but this should probably be done at some point.

Side notes: It may also be productive to automatically set mergeinfo when all parents of a merge commit have git-svn-info annotations, but I have not done this (as I said earlier, I use scripts external to git for this task). Finally, I am uncertain why the git-svn-info lines are stored in commit bodies instead of as notes; a notes-based approach would not involve commit hashes changing when they are pushed to an upstream SVN server.

Thanks all, Bryan Jacobs

Heya,

On Wed, Aug 31, 2011 at 18:55, Bryan Jacobs <bjacobs@woti.com> wrote:

Hysterical raisins mostly. I think git-notes predates git-svn by several years :). I suspect that if someone would wade through the mess that is git-svn.perl and tought it to (optionally) use git-notes instead of commit messages that would be highly welcome.

On 08/29/2011 07:20 PM, Bryan Jacobs wrote:

Naive question: why can't you pass a newline (properly quoted, of course) directly within the string argument to the --mergeinfo option?

Michael

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

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

Bryan Jacobs <bjacobs@woti.com> writes:

Hmm, I think Michael meant by "properly quoted" something like this:

    $ git commit -s -m 'Fix blorb
    > 
    > As it stands, blorb feature is totally broken for such and
    > such reasons. Fix it by restructuring frotz and nitfol to
    > use the same xyzzy helper function.'

which is not all that awkward, even for a free-form text argument like commit log. In this case, you are talking about svn merge-info that is a lot more structured (it is much less likely to see a single-quote in there than my commit log message example above, for example) so...

On Thu, 2011-09-01 at 10:43 -0400, Bryan Jacobs wrote:

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

On Tue, 06 Sep 2011 14:56:38 +0200 Carlos Martín Nieto <cmn@elego.de> wrote:

Ah, a situation I neglected to consider! Perhaps we should revert this patch, since I worked up the initiative to write an auto-populating-mergeinfo patch for git-svn anyhow.

Bryan Jacobs

On Tue, 2011-09-06 at 09:52 -0400, Bryan Jacobs wrote:

As it can cause regressions, I think reverting is the right option. And since git-svn is going to learn to do it by itself, the functionality isn't a big loss.

Cheers,
   cmn