{"thread":{"id":"9532","subject":"Multiple branches and git-svn","startedAt":"2007-08-15T10:17:15Z","lastAt":"2007-08-21T17:55:01Z","messageCount":9,"participants":["David Kastrup","Benoit SIGOURE","David Watson","Pierre Habouzit"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"50762","messageId":"864pj16r10.fsf@lola.quinscape.zz","threadId":"9532","inReplyTo":null,"subject":"Multiple branches and git-svn","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-15T10:17:15Z","receivedAt":"2007-08-15T10:17:15Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\nAfter having had several embarrassing occurences with git-svn dcommit,\nI think it would not be amiss to mention in the docs just how git-svn\nhappens to figure out which Subversion remote it is associated with.\n\nOne surprising relevation was that this association changed after a\ngit-rebase.\n\nIt may be a general git thing, or it may be git-svn specific, but it\nwas not exactly what I expected. And the docs were not really that\nhelpful.\n\nIn particular, man git-svn is completely silent about this.\n\n-- \nDavid Kastrup\n"},{"id":"51159","messageId":"9FD13095-36B5-4663-B658-082981B1ACD9@lrde.epita.fr","threadId":"9532","inReplyTo":"864pj16r10.fsf@lola.quinscape.zz","subject":"Re: Multiple branches and git-svn","fromName":"Benoit SIGOURE","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-08-21T10:06:36Z","receivedAt":"2007-08-21T10:06:36Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"On Aug 15, 2007, at 12:17 PM, David Kastrup wrote:\n\n>\n> After having had several embarrassing occurences with git-svn dcommit,\n> I think it would not be amiss to mention in the docs just how git-svn\n> happens to figure out which Subversion remote it is associated with.\n>\n> One surprising relevation was that this association changed after a\n> git-rebase.\n>\n> It may be a general git thing, or it may be git-svn specific, but it\n> was not exactly what I expected. And the docs were not really that\n> helpful.\n>\n> In particular, man git-svn is completely silent about this.\n>\n\nWhat I do usually is that I look in git log until I see a git-svn-id \nline:\ngit-svn-id: https://svn.foo.com/svn/project/branches/bar@ \n\nAFAIK git-svn dcommit will commit in the branch specified in the last \ngit-svn-id. I also dcommitted in the wrong branch after a rebase \nbecause I imported commits from another branch and the topmost commit \nin git-log was \"pointing to\" a different branch.\n\nI hope this helps.\n\nCheers,\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n\n\n"},{"id":"51160","messageId":"861wdxgncz.fsf@lola.quinscape.zz","threadId":"9532","inReplyTo":"9FD13095-36B5-4663-B658-082981B1ACD9@lrde.epita.fr","subject":"Re: Multiple branches and git-svn","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-21T11:04:28Z","receivedAt":"2007-08-21T11:04:28Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Benoit SIGOURE writes:\n\n> On Aug 15, 2007, at 12:17 PM, David Kastrup wrote:\n>\n>>\n>> After having had several embarrassing occurences with git-svn dcommit,\n>> I think it would not be amiss to mention in the docs just how git-svn\n>> happens to figure out which Subversion remote it is associated with.\n>>\n>> One surprising relevation was that this association changed after a\n>> git-rebase.\n>>\n>> It may be a general git thing, or it may be git-svn specific, but it\n>> was not exactly what I expected. And the docs were not really that\n>> helpful.\n>>\n>> In particular, man git-svn is completely silent about this.\n>\n> What I do usually is that I look in git log until I see a git-svn-id\n> line:\n> git-svn-id: https://svn.foo.com/svn/project/branches/bar@\n> \n> AFAIK git-svn dcommit will commit in the branch specified in the last\n> git-svn-id. I also dcommitted in the wrong branch after a rebase\n> because I imported commits from another branch and the topmost commit\n> in git-log was \"pointing to\" a different branch.\n\nSounds insane: apparently one result is that when you do a merge and\ndcommit, the commit will go to the branch you merged.\n\nThe whole point of merging is to stay on one's current branch.\n\n-- \nDavid Kastrup\n"},{"id":"51161","messageId":"20070821115611.GA21410@mimvista.com","threadId":"9532","inReplyTo":"861wdxgncz.fsf@lola.quinscape.zz","subject":"Re: Multiple branches and git-svn","fromName":"David Watson","fromEmail":"dwatson@mimvista.com","sentAt":"2007-08-21T11:56:11Z","receivedAt":"2007-08-21T11:56:11Z","isPatch":false,"sender":{"key":"dwatson@mimvista.com","avatar":null},"body":"Yes, that's quite true. It took me quite a while to figure that out when I\nfirst started using git-svn, and its non-sensicalness nearly put me off using\ngit entirely. My workflow at this point is to use git-cherry-pick -e to pull in\nany changes from other branches, then delete the git-svn-id line. \n\nEssentially, merging using git-svn is almost entirely broken, since an\ninconsistent tool is worthless - you spend more time figuring out if it's going\nto break, and working around the breakage, than you save using it.\n\nNow, I'm not sure this is 100% the fault of git-svn. Perhaps keeping its\nmetadata about which SVN branch it's connected to isn't the best thing, but\ngit-merge is doing exactly what you ask for. Perhaps we need a merge command in\ngit-svn that does the right thing? Although what that right thing would be, I'm\nnot quite sure. Either way, there needs to be a BIG GIGANTIC WARNING in the\ngit-svn manual that if you actually use git for what it claims to be great at\n(i.e., merging) you may be in for a world of pain, with your coworkers and boss\ncoming at you with pitchforks and torches. Especially because there are\nso many git users who need to interoperate with SVN.\n\nOn Tue, Aug 21, 2007 at 01:04:28PM +0200, David Kastrup wrote:\n> Benoit SIGOURE writes:\n> \n> > On Aug 15, 2007, at 12:17 PM, David Kastrup wrote:\n> >\n> >>\n> >> After having had several embarrassing occurences with git-svn dcommit,\n> >> I think it would not be amiss to mention in the docs just how git-svn\n> >> happens to figure out which Subversion remote it is associated with.\n> >>\n> >> One surprising relevation was that this association changed after a\n> >> git-rebase.\n> >>\n> >> It may be a general git thing, or it may be git-svn specific, but it\n> >> was not exactly what I expected. And the docs were not really that\n> >> helpful.\n> >>\n> >> In particular, man git-svn is completely silent about this.\n> >\n> > What I do usually is that I look in git log until I see a git-svn-id\n> > line:\n> > git-svn-id: https://svn.foo.com/svn/project/branches/bar@\n> > \n> > AFAIK git-svn dcommit will commit in the branch specified in the last\n> > git-svn-id. I also dcommitted in the wrong branch after a rebase\n> > because I imported commits from another branch and the topmost commit\n> > in git-log was \"pointing to\" a different branch.\n> \n> Sounds insane: apparently one result is that when you do a merge and\n> dcommit, the commit will go to the branch you merged.\n> \n> The whole point of merging is to stay on one's current branch.\n> \n> -- \n> David Kastrup\n> \n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n\n-- \nDave Watson\n"},{"id":"51162","messageId":"86wsvpf4k7.fsf@lola.quinscape.zz","threadId":"9532","inReplyTo":"20070821115611.GA21410@mimvista.com","subject":"Re: Multiple branches and git-svn","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-21T12:35:52Z","receivedAt":"2007-08-21T12:35:52Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"David Watson writes:\n\n> Yes, that's quite true. It took me quite a while to figure that out\n> when I first started using git-svn, and its non-sensicalness nearly\n> put me off using git entirely. My workflow at this point is to use\n> git-cherry-pick -e to pull in any changes from other branches, then\n> delete the git-svn-id line.\n>\n> Essentially, merging using git-svn is almost entirely broken, since\n> an inconsistent tool is worthless - you spend more time figuring out\n> if it's going to break, and working around the breakage, than you\n> save using it.\n\nFull agreement.\n\n> Now, I'm not sure this is 100% the fault of git-svn. Perhaps keeping\n> its metadata about which SVN branch it's connected to isn't the best\n> thing, but git-merge is doing exactly what you ask for. Perhaps we\n> need a merge command in git-svn that does the right thing?\n\nGit svn needs to recognize a merge for what it is, and has to ignore\nthe branch which has been merged, looking further for git-svn-id lines\nor whatever. Cherrypicking is harder to contain. Basically, I think\nit is a mistake to use something as fragile as the git-svn-id line in\nthe log for determining the branch to use for committing. Instead, a\nfixed association of git branches with git-svn should be established.\nEven if one needs to write this manually into some configuration file.\nBefore git-svn does not have reliable information, it should refuse to\ncommit. One could specify this on the command line, too: that is a\nsmall price to pay for being sure that one commits where one wants to.\n\n> Although what that right thing would be, I'm not quite sure. Either\n> way, there needs to be a BIG GIGANTIC WARNING in the git-svn manual\n> that if you actually use git for what it claims to be great at\n> (i.e., merging) you may be in for a world of pain, with your\n> coworkers and boss coming at you with pitchforks and\n> torches. Especially because there are so many git users who need to\n> interoperate with SVN.\n\nYes.\n\n-- \nDavid Kastrup\n"},{"id":"51164","messageId":"86sl6df3qk.fsf@lola.quinscape.zz","threadId":"9532","inReplyTo":"86wsvpf4k7.fsf@lola.quinscape.zz","subject":"Re: Multiple branches and git-svn","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-21T12:53:39Z","receivedAt":"2007-08-21T12:53:39Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"David Kastrup writes:\n\n> David Watson writes:\n>\n>> Yes, that's quite true. It took me quite a while to figure that out\n>> when I first started using git-svn, and its non-sensicalness nearly\n>> put me off using git entirely. My workflow at this point is to use\n>> git-cherry-pick -e to pull in any changes from other branches, then\n>> delete the git-svn-id line.\n>>\n>> Essentially, merging using git-svn is almost entirely broken, since\n>> an inconsistent tool is worthless - you spend more time figuring out\n>> if it's going to break, and working around the breakage, than you\n>> save using it.\n>\n> Full agreement.\n>\n>> Now, I'm not sure this is 100% the fault of git-svn. Perhaps keeping\n>> its metadata about which SVN branch it's connected to isn't the best\n>> thing, but git-merge is doing exactly what you ask for. Perhaps we\n>> need a merge command in git-svn that does the right thing?\n>\n> Git svn needs to recognize a merge for what it is, and has to ignore\n> the branch which has been merged, looking further for git-svn-id lines\n> or whatever. Cherrypicking is harder to contain. Basically, I think\n> it is a mistake to use something as fragile as the git-svn-id line in\n> the log for determining the branch to use for committing. Instead, a\n> fixed association of git branches with git-svn should be established.\n> Even if one needs to write this manually into some configuration file.\n> Before git-svn does not have reliable information, it should refuse to\n> commit. One could specify this on the command line, too: that is a\n> small price to pay for being sure that one commits where one wants to.\n\nPostScriptum: that is probably all nonsense. git-svn fetch knows what\nto fetch, and probably also what to merge (this should be quite\nsimilar to git pull's behavior), and git-svn rebase/dcommit should not\ndo anything different.\n\n-- \nDavid Kastrup\n"},{"id":"51172","messageId":"20070821151243.GA29020@artemis.corp","threadId":"9532","inReplyTo":"20070821115611.GA21410@mimvista.com","subject":"Re: Multiple branches and git-svn","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-08-21T15:12:43Z","receivedAt":"2007-08-21T15:12:43Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Tue, Aug 21, 2007 at 11:56:11AM +0000, David Watson wrote:\n> Now, I'm not sure this is 100% the fault of git-svn. Perhaps keeping its\n> metadata about which SVN branch it's connected to isn't the best thing, but\n> git-merge is doing exactly what you ask for. Perhaps we need a merge command in\n> git-svn that does the right thing? Although what that right thing would be, I'm\n> not quite sure. Either way, there needs to be a BIG GIGANTIC WARNING in the\n> git-svn manual that if you actually use git for what it claims to be great at\n> (i.e., merging) you may be in for a world of pain, with your coworkers and boss\n> coming at you with pitchforks and torches. Especially because there are\n> so many git users who need to interoperate with SVN.\n\n IMHO here is what git-svn should do. It should use the not-so-new\nremotes mechanism, and have all the svn remotes branches under a remote\nnamespace, clean, simple, and also knowing which \"upstream\" svn \"thing\"\nit's following.\n\n Then, when you just git checkout --track -b \n\n hack hack hack\n git commit\n hack hack hack\n git commit\n git merge \n hack hack hack\n git commit\n\n and then you just want to:\n\n git svn dcommit.\n\n Using the fact that tracks and that\n is in fact the plain mirror of upstream's branch foo,\nit should be able to know where to actually commit and wrt what it has\nto make history clean.\n\n\n IMHO a git-$scm gateway just has to feed \"remotes\" branches, and\nprovide some plumbing commands (like dcommit) to be able to feed some\nchanges to the other $scm, with a workflow like this one:\n\n 1. pull $scm into a shadow git repository\n 2. import/merge $scm changes into your local branch\n 3. make changes / merges whatever\n 4. push $scm.. into $scm\n 5. goto 1, so that you can \"win\" your changes from 4. back in the $scm\n local shadow repository.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"51186","messageId":"883671F6-F11C-4962-8BEE-763267DA9FEE@lrde.epita.fr","threadId":"9532","inReplyTo":"20070821151243.GA29020@artemis.corp","subject":"Re: Multiple branches and git-svn","fromName":"Benoit SIGOURE","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-08-21T17:51:05Z","receivedAt":"2007-08-21T17:51:05Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"On Aug 21, 2007, at 5:12 PM, Pierre Habouzit wrote:\n\n> On Tue, Aug 21, 2007 at 11:56:11AM +0000, David Watson wrote:\n>> Now, I'm not sure this is 100% the fault of git-svn. Perhaps \n>> keeping its\n>> metadata about which SVN branch it's connected to isn't the best \n>> thing, but\n>> git-merge is doing exactly what you ask for. Perhaps we need a \n>> merge command in\n>> git-svn that does the right thing? Although what that right thing \n>> would be, I'm\n>> not quite sure. Either way, there needs to be a BIG GIGANTIC \n>> WARNING in the\n>> git-svn manual that if you actually use git for what it claims to \n>> be great at\n>> (i.e., merging) you may be in for a world of pain, with your \n>> coworkers and boss\n>> coming at you with pitchforks and torches. Especially because \n>> there are\n>> so many git users who need to interoperate with SVN.\n>\n> IMHO here is what git-svn should do. It should use the not-so-new\n> remotes mechanism, and have all the svn remotes branches under a \n> remote\n> namespace, clean, simple, and also knowing which \"upstream\" svn \n> \"thing\"\n> it's following.\n\nIsn't what git-svn already does if you git-svn clone with `-T trunk - \nb branches -t tags'? At least in my git-svn repositories I do see \nthe SVN branches as remote branches with `git branch -r'\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n\n\n"},{"id":"51188","messageId":"09C6E878-619D-458E-8076-4304C20D5A52@lrde.epita.fr","threadId":"9532","inReplyTo":"20070821115611.GA21410@mimvista.com","subject":"Re: Multiple branches and git-svn","fromName":"Benoit SIGOURE","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-08-21T17:55:01Z","receivedAt":"2007-08-21T17:55:01Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"On Aug 21, 2007, at 1:56 PM, David Watson wrote:\n\n> Yes, that's quite true. It took me quite a while to figure that out \n> when I\n> first started using git-svn, and its non-sensicalness nearly put me \n> off using\n> git entirely. My workflow at this point is to use git-cherry-pick - \n> e to pull in\n> any changes from other branches, then delete the git-svn-id line.\n>\n> Essentially, merging using git-svn is almost entirely broken, since an\n> inconsistent tool is worthless - you spend more time figuring out \n> if it's going\n> to break, and working around the breakage, than you save using it.\n\nTo me this sounds exaggerated, I fell in the pitfall once after a git- \nrebase but never had the problem again since then.\n\n>\n> Now, I'm not sure this is 100% the fault of git-svn. Perhaps \n> keeping its\n> metadata about which SVN branch it's connected to isn't the best \n> thing, but\n> git-merge is doing exactly what you ask for. Perhaps we need a \n> merge command in\n> git-svn that does the right thing? Although what that right thing \n> would be, I'm\n> not quite sure. Either way, there needs to be a BIG GIGANTIC \n> WARNING in the\n> git-svn manual that if you actually use git for what it claims to \n> be great at\n> (i.e., merging) you may be in for a world of pain, with your \n> coworkers and boss\n> coming at you with pitchforks and torches. Especially because there \n> are\n> so many git users who need to interoperate with SVN.\n>\n\nIMO the only think that git-svn dcommit needs is an option to specify \nto which SVN branch you want to commit in case you want your commit \nto go in another branch than that specified in the last git-svn-id line.\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n\n\n"}]}