{"thread":{"id":"28249","subject":"git-svn and mergeinfo","startedAt":"2011-08-29T17:20:52Z","lastAt":"2011-09-06T14:28:22Z","messageCount":14,"participants":["Bryan Jacobs","Jeff King","Junio C Hamano","Sverre Rabbelier","Michael Haggerty","Carlos Martín Nieto"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"174470","messageId":"20110829132052.0ad7a088@robyn.woti.com","threadId":"28249","inReplyTo":null,"subject":"git-svn and mergeinfo","fromName":"Bryan Jacobs","fromEmail":"bjacobs@woti.com","sentAt":"2011-08-29T17:20:52Z","receivedAt":"2011-08-29T17:20:52Z","isPatch":false,"sender":{"key":"bjacobs@woti.com","avatar":null},"body":"Dear git Developers,\n\nApologies if this is not the right forum for bug reports. I was unable\nto find a Bugzilla/Redmine/Flyspray instance for issue maintenance, nor\nsome \"proper procedure\" on the git web page.\n\nI have been (ab)using git-svn for committing to a central SVN\nrepository while doing my work locally with git. To this end, I've\nwritten a set of scripts and hooks which perform squash merges locally\nand then dcommit them with proper svn:mergeinfo annotations. The final\nresult is the perfect appearance of having done a native SVN merge in\nthe central repository, while using only local git commands and\ngaining the full benefit of git's conflict resolution and developer\nconvenience.\n\nHowever, to make this work with git 1.7.6, I needed to make *one* change\nto the git internals: --merge-info does not allow setting mergeinfo for\nmore than one branch. Because it's a complete overwrite operation\ninstead of an update, this is a serious issue preventing its use for\nnontrivial branches.\n\nMight I suggest adding a block like the following around line 552 of\ngit-svn?\n\n if (defined($_merge_info))\n { \n $_merge_info =~ tr{ }{\\n};\n }\n\nThis will replace any spaces in --merge-info with newlines, allowing\nspecification of an svn:mergeinfo that contains merges from more than a\nsinge branch. So the user can provide \"--merge-info\n'/branch1:r2323-3849,r8888 /branch2:r9999'\" and the like.\n\nThank you for your consideration. I am not subscribed to this list, so\nif there are any replies, please copy my address.\n\nBryan Jacobs\n"},{"id":"174478","messageId":"20110829192618.GF756@sigill.intra.peff.net","threadId":"28249","inReplyTo":"20110829132052.0ad7a088@robyn.woti.com","subject":"git bug reporting","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-08-29T19:26:18Z","receivedAt":"2011-08-29T19:26:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 29, 2011 at 01:20:52PM -0400, Bryan Jacobs wrote:\n\n> Dear git Developers,\n> \n> Apologies if this is not the right forum for bug reports. I was unable\n> to find a Bugzilla/Redmine/Flyspray instance for issue maintenance, nor\n> some \"proper procedure\" on the git web page.\n\nYes, this is the right place. This question seems to be coming up a lot\nlately. And indeed, looking at the webpage and the wiki, we are not very\nclear that the mailing list is the place for such things.\n\nDo you mind telling us where you looked? That will give us at least one\nspot that we know should be more clear. :)\n\nIn the meantime, I've updated:\n\n 1. The GitCommunity wiki page to mention that bug reports should go\n to the list.\n\n 2. Added an entry \"How do I report a bug in git?\" to the FAQ on the\n wiki.\n\n 3. Sent Scott a patch for git-scm.org to mention bug reporting under\n the big \"Got questions\" banner on the front page that points people\n to the mailing list. Pull request is here:\n\n https://github.com/schacon/gitscm/pull/11\n\n It may make sense to have a specific page on reporting bugs, and\n link to it via a bigger \"how to report bugs\" somewhere on the front\n page of git-scm.org.\n\n-Peff\n"},{"id":"174479","messageId":"20110829153448.190baaa1@robyn.woti.com","threadId":"28249","inReplyTo":"20110829192618.GF756@sigill.intra.peff.net","subject":"Re: git bug reporting","fromName":"Bryan Jacobs","fromEmail":"bjacobs@woti.com","sentAt":"2011-08-29T19:34:48Z","receivedAt":"2011-08-29T19:34:48Z","isPatch":false,"sender":{"key":"bjacobs@woti.com","avatar":null},"body":"On Mon, 29 Aug 2011 15:26:18 -0400\nJeff King wrote:\n\n> On Mon, Aug 29, 2011 at 01:20:52PM -0400, Bryan Jacobs wrote:\n> \n> > Dear git Developers,\n> > \n> > Apologies if this is not the right forum for bug reports. I was\n> > unable to find a Bugzilla/Redmine/Flyspray instance for issue\n> > maintenance, nor some \"proper procedure\" on the git web page.\n> \n> Yes, this is the right place. This question seems to be coming up a\n> lot lately. And indeed, looking at the webpage and the wiki, we are\n> not very clear that the mailing list is the place for such things.\n> \n> Do you mind telling us where you looked? That will give us at least\n> one spot that we know should be more clear. :)\n\nI looked at the git-scm.com main page, the \"documentation\" sub-page,\nthe wiki front page, and googled the site for terms like \"issue tracker\"\nand \"bug reports\", then read the FAQ.\n\n> In the meantime, I've updated:\n> \n> 1. The GitCommunity wiki page to mention that bug reports should go\n> to the list.\n> \n> 2. Added an entry \"How do I report a bug in git?\" to the FAQ on the\n> wiki.\n> \n> 3. Sent Scott a patch for git-scm.org to mention bug reporting under\n> the big \"Got questions\" banner on the front page that points\n> people to the mailing list. Pull request is here:\n> \n> https://github.com/schacon/gitscm/pull/11\n> \n> It may make sense to have a specific page on reporting bugs, and\n> link to it via a bigger \"how to report bugs\" somewhere on the\n> front page of git-scm.org.\n\nThank you very much for your efforts. It looks like you hit all but one\nof the places I looked. I agree that having a link from some part of the\ngit-scm landing page would make sense, that's common practice for\nsoftware projects and seems to me a logical place for it. I (obviously)\nread the text under the \"got questions\" bit; it was what sent me to\nthis list. If it had said \"report a bug here\" I would have felt more\nconfident about sending this message.\n\nBryan Jacobs\n"},{"id":"174494","messageId":"7vpqjo54my.fsf@alter.siamese.dyndns.org","threadId":"28249","inReplyTo":"20110829192618.GF756@sigill.intra.peff.net","subject":"Re: git bug reporting","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-29T20:44:53Z","receivedAt":"2011-08-29T20:44:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> In the meantime, I've updated:\n> ...\n\nThanks. I've also made sure that the very first paragraph of \"A note fromt\nhe maintainer\" talks about it (yes it already does).\n"},{"id":"174609","messageId":"CAGdFq_h+KjWQUwwLdaqA-0j0p1zQznZkNNEVgfS46_o-Zfr3oQ@mail.gmail.com","threadId":"28249","inReplyTo":"20110829132052.0ad7a088@robyn.woti.com","subject":"Re: git-svn and mergeinfo","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-08-31T13:59:26Z","receivedAt":"2011-08-31T13:59:26Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Aug 29, 2011 at 19:20, Bryan Jacobs wrote:\n> Apologies if this is not the right forum for bug reports. I was unable\n> to find a Bugzilla/Redmine/Flyspray instance for issue maintenance, nor\n> some \"proper procedure\" on the git web page.\n\nThis is indeed the correct way of reporting bugs :).\n\n> However, to make this work with git 1.7.6, I needed to make *one* change\n> to the git internals: --merge-info does not allow setting mergeinfo for\n> more than one branch. Because it's a complete overwrite operation\n> instead of an update, this is a serious issue preventing its use for\n> nontrivial branches.\n>\n> Might I suggest adding a block like the following around line 552 of\n> git-svn?\n>\n>    if (defined($_merge_info))\n>    {\n>        $_merge_info =~ tr{ }{\\n};\n>    }\n>\n> This will replace any spaces in --merge-info with newlines, allowing\n> specification of an svn:mergeinfo that contains merges from more than a\n> singe branch. So the user can provide \"--merge-info\n> '/branch1:r2323-3849,r8888 /branch2:r9999'\" and the like.\n\nWhy not submit this as a proper patch [0] to the list, I reckon Eric\n(cc-ed, the maintainer of git-svn) wouldn't mind including it.\n\n> Thank you for your consideration. I am not subscribed to this list, so\n> if there are any replies, please copy my address.\n\nThat's the policy on this list anyway :).\n\n[0] http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/SubmittingPatches;hb=HEAD\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"174610","messageId":"CAGdFq_jtf9irk7mmikT2W8p5oEO-oUzy9Gq5c-s1xk-N3tSTKw@mail.gmail.com","threadId":"28249","inReplyTo":"7vpqjo54my.fsf@alter.siamese.dyndns.org","subject":"Re: git bug reporting","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-08-31T14:03:58Z","receivedAt":"2011-08-31T14:03:58Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Aug 29, 2011 at 22:44, Junio C Hamano wrote:\n> Jeff King writes:\n>> In the meantime, I've updated:\n>> ...\n>\n> Thanks. I've also made sure that the very first paragraph of \"A note fromt\n> he maintainer\" talks about it (yes it already does).\n\nWhile we're at it, should we also make sure that these places mention\nDocumentation/SubmittingPatches?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"174628","messageId":"20110831125557.56ccffe2@robyn.woti.com","threadId":"28249","inReplyTo":"CAGdFq_h+KjWQUwwLdaqA-0j0p1zQznZkNNEVgfS46_o-Zfr3oQ@mail.gmail.com","subject":"Re: git-svn and mergeinfo","fromName":"Bryan Jacobs","fromEmail":"bjacobs@woti.com","sentAt":"2011-08-31T16:55:57Z","receivedAt":"2011-08-31T16:55:57Z","isPatch":false,"sender":{"key":"bjacobs@woti.com","avatar":null},"body":"On Wed, 31 Aug 2011 15:59:26 +0200\nSverre Rabbelier wrote:\n\n> \n> Why not submit this as a proper patch [0] to the list, I reckon Eric\n> (cc-ed, the maintainer of git-svn) wouldn't mind including it.\n\nI have submitted a patch, following your conventions as best I could. I\nforgot the CC line, sorry Eric!\n\nThere was an inaccurate line in the documentation concerning the\nsvn:mergeinfo property (\"git-svn does not currently make use of this\")\nwhich I clobbered with my documentation change. I did not document the\nwhole of how \"git svn fetch\" deals with the property, but this should\nprobably be done at some point.\n\nSide notes: It may also be productive to automatically set mergeinfo\nwhen all parents of a merge commit have git-svn-info annotations, but I\nhave not done this (as I said earlier, I use scripts external to git\nfor this task). Finally, I am uncertain why the git-svn-info lines are\nstored in commit bodies instead of as notes; a notes-based approach\nwould not involve commit hashes changing when they are pushed to an\nupstream SVN server.\n\nThanks all,\nBryan Jacobs\n"},{"id":"174631","messageId":"CAGdFq_gG6NGCzsURg7ERZ8XgV1bP5=vwg8dii7itmnakPzt4VA@mail.gmail.com","threadId":"28249","inReplyTo":"20110831125557.56ccffe2@robyn.woti.com","subject":"Re: git-svn and mergeinfo","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-08-31T17:01:41Z","receivedAt":"2011-08-31T17:01:41Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, Aug 31, 2011 at 18:55, Bryan Jacobs wrote:\n> Finally, I am uncertain why the git-svn-info lines are\n> stored in commit bodies instead of as notes\n\nHysterical raisins mostly. I think git-notes predates git-svn by\nseveral years :). I suspect that if someone would wade through the\nmess that is git-svn.perl and tought it to (optionally) use git-notes\ninstead of commit messages that would be highly welcome.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"174663","messageId":"4E5F4987.5040205@alum.mit.edu","threadId":"28249","inReplyTo":"20110829132052.0ad7a088@robyn.woti.com","subject":"Re: git-svn and mergeinfo","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2011-09-01T08:59:51Z","receivedAt":"2011-09-01T08:59:51Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 08/29/2011 07:20 PM, Bryan Jacobs wrote:\n> I have been (ab)using git-svn for committing to a central SVN\n> repository while doing my work locally with git. To this end, I've\n> written a set of scripts and hooks which perform squash merges locally\n> and then dcommit them with proper svn:mergeinfo annotations. The final\n> result is the perfect appearance of having done a native SVN merge in\n> the central repository, while using only local git commands and\n> gaining the full benefit of git's conflict resolution and developer\n> convenience.\n> \n> However, to make this work with git 1.7.6, I needed to make *one* change\n> to the git internals: --merge-info does not allow setting mergeinfo for\n> more than one branch. Because it's a complete overwrite operation\n> instead of an update, this is a serious issue preventing its use for\n> nontrivial branches.\n> \n> Might I suggest adding a block like the following around line 552 of\n> git-svn?\n> \n> if (defined($_merge_info))\n> { \n> $_merge_info =~ tr{ }{\\n};\n> }\n\nNaive question: why can't you pass a newline (properly quoted, of\ncourse) directly within the string argument to the --mergeinfo option?\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"174667","messageId":"20110901104327.14d4dba6@robyn.woti.com","threadId":"28249","inReplyTo":"4E5F4987.5040205@alum.mit.edu","subject":"Re: git-svn and mergeinfo","fromName":"Bryan Jacobs","fromEmail":"bjacobs@woti.com","sentAt":"2011-09-01T14:43:27Z","receivedAt":"2011-09-01T14:43:27Z","isPatch":false,"sender":{"key":"bjacobs@woti.com","avatar":null},"body":"On Thu, 01 Sep 2011 10:59:51 +0200\nMichael Haggerty wrote:\n\n> On 08/29/2011 07:20 PM, Bryan Jacobs wrote:\n> > I have been (ab)using git-svn for committing to a central SVN\n> > repository while doing my work locally with git. To this end, I've\n> > written a set of scripts and hooks which perform squash merges\n> > locally and then dcommit them with proper svn:mergeinfo\n> > annotations. The final result is the perfect appearance of having\n> > done a native SVN merge in the central repository, while using only\n> > local git commands and gaining the full benefit of git's conflict\n> > resolution and developer convenience.\n> > \n> > However, to make this work with git 1.7.6, I needed to make *one*\n> > change to the git internals: --merge-info does not allow setting\n> > mergeinfo for more than one branch. Because it's a complete\n> > overwrite operation instead of an update, this is a serious issue\n> > preventing its use for nontrivial branches.\n> > \n> > Might I suggest adding a block like the following around line 552 of\n> > git-svn?\n> > \n> > if (defined($_merge_info))\n> > { \n> > $_merge_info =~ tr{ }{\\n};\n> > }\n> \n> Naive question: why can't you pass a newline (properly quoted, of\n> course) directly within the string argument to the --mergeinfo option?\n\nThe only way I know of to do that in bash is to assign the\nnewline-bearing string to a variable, and then use the variable in a\ncommand line option. Extremely awkward.\n\nI think the long-term solution for this issue is probably to have\ngit-svn populate the mergeinfo on its own, reducing the need for\nusers manipulating the value directly. This could in theory be done for\nboth cherry picks and merges, provided that the merge was --no-ff or\nbears a body (so there is a commit object to carry the property\nchange) and both parents are tagged with SVN revs at the time the merge\nis dcommitted (or, correspondingly, that the cherry-pick source carries\nan SVN revision number). I will send patches for some to all of this\nshortly as I pull my bash scripts into git-svn.perl and clean up the\ncode.\n\nThe cost of the automatic svn:mergeinfo pushing will be an SVN property\nretrieval before each dcommit operation. I plan to have this behavior\ndisabled by default.\n\nBryan Jacobs\n"},{"id":"174672","messageId":"7vfwkgxnga.fsf@alter.siamese.dyndns.org","threadId":"28249","inReplyTo":"20110901104327.14d4dba6@robyn.woti.com","subject":"Re: git-svn and mergeinfo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-01T16:00:05Z","receivedAt":"2011-09-01T16:00:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bryan Jacobs writes:\n\n>> Naive question: why can't you pass a newline (properly quoted, of\n>> course) directly within the string argument to the --mergeinfo option?\n>\n> The only way I know of to do that in bash is to assign the\n> newline-bearing string to a variable, and then use the variable in a\n> command line option. Extremely awkward.\n\nHmm, I think Michael meant by \"properly quoted\" something like this:\n\n $ git commit -s -m 'Fix blorb\n > \n > As it stands, blorb feature is totally broken for such and\n > such reasons. Fix it by restructuring frotz and nitfol to\n > use the same xyzzy helper function.'\n\nwhich is not all that awkward, even for a free-form text argument like\ncommit log. In this case, you are talking about svn merge-info that is a\nlot more structured (it is much less likely to see a single-quote in there\nthan my commit log message example above, for example) so...\n"},{"id":"174923","messageId":"1315313800.9839.10.camel@bee.lab.cmartin.tk","threadId":"28249","inReplyTo":"20110901104327.14d4dba6@robyn.woti.com","subject":"Re: git-svn and mergeinfo","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2011-09-06T12:56:38Z","receivedAt":"2011-09-06T12:56:38Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Thu, 2011-09-01 at 10:43 -0400, Bryan Jacobs wrote:\n> On Thu, 01 Sep 2011 10:59:51 +0200\n> Michael Haggerty wrote:\n> \n> > On 08/29/2011 07:20 PM, Bryan Jacobs wrote:\n> > > I have been (ab)using git-svn for committing to a central SVN\n> > > repository while doing my work locally with git. To this end, I've\n> > > written a set of scripts and hooks which perform squash merges\n> > > locally and then dcommit them with proper svn:mergeinfo\n> > > annotations. The final result is the perfect appearance of having\n> > > done a native SVN merge in the central repository, while using only\n> > > local git commands and gaining the full benefit of git's conflict\n> > > resolution and developer convenience.\n> > > \n> > > However, to make this work with git 1.7.6, I needed to make *one*\n> > > change to the git internals: --merge-info does not allow setting\n> > > mergeinfo for more than one branch. Because it's a complete\n> > > overwrite operation instead of an update, this is a serious issue\n> > > preventing its use for nontrivial branches.\n> > > \n> > > Might I suggest adding a block like the following around line 552 of\n> > > git-svn?\n> > > \n> > > if (defined($_merge_info))\n> > > { \n> > > $_merge_info =~ tr{ }{\\n};\n> > > }\n> > \n> > Naive question: why can't you pass a newline (properly quoted, of\n> > course) directly within the string argument to the --mergeinfo option?\n> \n> The only way I know of to do that in bash is to assign the\n> newline-bearing string to a variable, and then use the variable in a\n> command line option. Extremely awkward.\n\nYou can also save the mergeinfo to a file, add the line, and use\n--mergeinfo=$(cat /tmp/some-file) to set it. It is indeed awkward, but\nblindly replacing every space with a newline is not always the right\noption. If a merged directory contains a space, this change will break\nthe mergeinfo, even if you're properly quoting your variable or using\nthe $(cat /some/file) method.\n\nCheers,\n cmn\n"},{"id":"174925","messageId":"20110906095256.205dd5d0@robyn.woti.com","threadId":"28249","inReplyTo":"1315313800.9839.10.camel@bee.lab.cmartin.tk","subject":"Re: git-svn and mergeinfo","fromName":"Bryan Jacobs","fromEmail":"bjacobs@woti.com","sentAt":"2011-09-06T13:52:56Z","receivedAt":"2011-09-06T13:52:56Z","isPatch":false,"sender":{"key":"bjacobs@woti.com","avatar":null},"body":"On Tue, 06 Sep 2011 14:56:38 +0200\nCarlos Martín Nieto wrote:\n\n> You can also save the mergeinfo to a file, add the line, and use\n> --mergeinfo=$(cat /tmp/some-file) to set it. It is indeed awkward, but\n> blindly replacing every space with a newline is not always the right\n> option. If a merged directory contains a space, this change will break\n> the mergeinfo, even if you're properly quoting your variable or using\n> the $(cat /some/file) method.\n> \n> Cheers,\n> cmn\n\nAh, a situation I neglected to consider! Perhaps we should revert this\npatch, since I worked up the initiative to write an\nauto-populating-mergeinfo patch for git-svn anyhow.\n\nBryan Jacobs\n"},{"id":"174929","messageId":"1315319309.9839.13.camel@bee.lab.cmartin.tk","threadId":"28249","inReplyTo":"20110906095256.205dd5d0@robyn.woti.com","subject":"Re: git-svn and mergeinfo","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2011-09-06T14:28:22Z","receivedAt":"2011-09-06T14:28:22Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Tue, 2011-09-06 at 09:52 -0400, Bryan Jacobs wrote:\n> On Tue, 06 Sep 2011 14:56:38 +0200\n> Carlos Martín Nieto wrote:\n> \n> > You can also save the mergeinfo to a file, add the line, and use\n> > --mergeinfo=$(cat /tmp/some-file) to set it. It is indeed awkward, but\n> > blindly replacing every space with a newline is not always the right\n> > option. If a merged directory contains a space, this change will break\n> > the mergeinfo, even if you're properly quoting your variable or using\n> > the $(cat /some/file) method.\n> > \n> > Cheers,\n> > cmn\n> \n> Ah, a situation I neglected to consider! Perhaps we should revert this\n> patch, since I worked up the initiative to write an\n> auto-populating-mergeinfo patch for git-svn anyhow.\n\nAs it can cause regressions, I think reverting is the right option. And\nsince git-svn is going to learn to do it by itself, the functionality\nisn't a big loss.\n\nCheers,\n cmn\n\n"}]}