git-svn and mergeinfo

git-svn and mergeinfo

[Bryan Jacobs]

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

git bug reporting

[Jeff King]

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

> 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.

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

Re: git bug reporting

[Bryan Jacobs]

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

> On Mon, Aug 29, 2011 at 01:20:52PM -0400, Bryan Jacobs wrote:
> 
> > 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.
> 
> 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. :)

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.

> 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.

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

Re: git bug reporting

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> In the meantime, I've updated:
> ...

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

Re: git bug reporting

[Sverre Rabbelier]

Heya,

On Mon, Aug 29, 2011 at 22:44, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>> In the meantime, I've updated:
>> ...
>
> Thanks. I've also made sure that the very first paragraph of "A note fromt
> he maintainer" talks about it (yes it already does).

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

-- 
Cheers,

Sverre Rabbelier

Re: git-svn and mergeinfo

[Sverre Rabbelier]

Heya,

On Mon, Aug 29, 2011 at 19:20, Bryan Jacobs <bjacobs@woti.com> wrote:
> 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.

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

> 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.

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.

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

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

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

-- 
Cheers,

Sverre Rabbelier

Re: git-svn and mergeinfo

[Bryan Jacobs]

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

> 
> 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.

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

Re: git-svn and mergeinfo

[Sverre Rabbelier]

Heya,

On Wed, Aug 31, 2011 at 18:55, Bryan Jacobs <bjacobs@woti.com> wrote:
> Finally, I am uncertain why the git-svn-info lines are
> stored in commit bodies instead of as notes

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.

-- 
Cheers,

Sverre Rabbelier

Re: git-svn and mergeinfo

[Michael Haggerty]

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?

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

Re: git-svn and mergeinfo

[Bryan Jacobs]

On Thu, 01 Sep 2011 10:59:51 +0200
Michael Haggerty <mhagger@alum.mit.edu> 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.

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

Re: git-svn and mergeinfo

[Junio C Hamano]

Bryan Jacobs <bjacobs@woti.com> writes:

>> 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.

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...

Re: git-svn and mergeinfo

[Carlos Martín Nieto]

[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]

On Thu, 2011-09-01 at 10:43 -0400, Bryan Jacobs wrote:
> On Thu, 01 Sep 2011 10:59:51 +0200
> Michael Haggerty <mhagger@alum.mit.edu> 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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: git-svn and mergeinfo

[Bryan Jacobs]

On Tue, 06 Sep 2011 14:56:38 +0200
Carlos Martín Nieto <cmn@elego.de> 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

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

Re: git-svn and mergeinfo

[Carlos Martín Nieto]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

On Tue, 2011-09-06 at 09:52 -0400, Bryan Jacobs wrote:
> On Tue, 06 Sep 2011 14:56:38 +0200
> Carlos Martín Nieto <cmn@elego.de> 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
> 
> 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.

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]