{"thread":{"id":"20542","subject":"sharing git work while downstream from svn?","startedAt":"2009-08-11T22:55:15Z","lastAt":"2009-08-11T23:17:24Z","messageCount":4,"participants":["tom fogal","Avery Pennarun"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"120318","messageId":"auto-000020209577@sci.utah.edu","threadId":"20542","inReplyTo":null,"subject":"sharing git work while downstream from svn?","fromName":"tom fogal","fromEmail":"tfogal@alumni.unh.edu","sentAt":"2009-08-11T22:55:15Z","receivedAt":"2009-08-11T22:55:15Z","isPatch":false,"sender":{"key":"tfogal@alumni.unh.edu","avatar":"https://gravatar.com/avatar/a2f71bfbe12b2b73cad0be2386d554aa403fff7a89df2f79e812c97c7eab0498?d=mp&s=160"},"body":"How do others manage distributed version control when everyone is\nforced to rebase all the time?\n\nTo give a concrete example: in one project where I have this issue,\nthere's a developer who is effectively 'downstream' from me. There's\na few other developers who are peers, w/ commit bits set on the\ncentralized server. I'll make some patches that should end up on our\ncentralized trunk, and some that our for our experimental sub-project,\nso I use format-patch and send patches around for those.\n\nThis gets to be a mess when trunk changes: I'll rebase + potentially\nfix some conflicts. Other developers with some of the experimental\npatches will svn update, and get similar conflicts. These might differ\nin subtle ways, and now exchanging patches gets more difficult.\n\nI'm not sure getting them to use git would even help. Once I rebase,\nI screw my downstream. Yet I can't avoid rebasing since I need to\nupdate.\n\nAs I recall, some members of the gcc community are handling this\nproblem, somehow. How do you do it? Or do you just not collaborate at\nthe git level?\n\nThanks,\n\n-tom\n"},{"id":"120323","messageId":"32541b130908111603v1e3f6c42peac792caf7097e0d@mail.gmail.com","threadId":"20542","inReplyTo":"auto-000020209577@sci.utah.edu","subject":"Re: sharing git work while downstream from svn?","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-08-11T23:03:47Z","receivedAt":"2009-08-11T23:03:47Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Aug 11, 2009 at 10:55 PM, tom fogal wrote:\n> This gets to be a mess when trunk changes: I'll rebase + potentially\n> fix some conflicts.  Other developers with some of the experimental\n> patches will svn update, and get similar conflicts.  These might differ\n> in subtle ways, and now exchanging patches gets more difficult.\n\nWe use git-svn at Versabanq, and our process is very simple: never use\nrebase, period.\n\nInstead, do all your work in a branch *other* than the git-svn main\nbranch. When you're ready to merge your stuff into svn, do:\n\ngit checkout git-svn\ngit svn rebase\ngit checkout myworkingbranch\ngit merge git-svn\n # and resolve any conflicts\ngit checkout git-svn\ngit merge --no-ff myworkingbranch # the --no-ff is very important here!\ngit svn dcommit\n\nThis basically results in a *single* commit getting sent to svn,\nrather than the batch of all the git commits you've been working on.\nMost svn users don't care about this, because they lose all that\ngranularity whenever they merge a branch anyhow. Meanwhile, all your\ngit users never have to worry about rebasing *anything* and can use\nthe normal git merge/pull stuff.\n\nHave fun,\n\nAvery\n"},{"id":"120324","messageId":"auto-000020209671@sci.utah.edu","threadId":"20542","inReplyTo":"32541b130908111603v1e3f6c42peac792caf7097e0d@mail.gmail.com","subject":"Re: sharing git work while downstream from svn?","fromName":"tom fogal","fromEmail":"tfogal@alumni.unh.edu","sentAt":"2009-08-11T23:14:38Z","receivedAt":"2009-08-11T23:14:38Z","isPatch":false,"sender":{"key":"tfogal@alumni.unh.edu","avatar":"https://gravatar.com/avatar/a2f71bfbe12b2b73cad0be2386d554aa403fff7a89df2f79e812c97c7eab0498?d=mp&s=160"},"body":"Avery Pennarun writes:\n> On Tue, Aug 11, 2009 at 10:55 PM, tom fogal wrote:\n> > This gets to be a mess when trunk changes: I'll rebase + potentially\n> > fix some conflicts.  Other developers with some of the experimental\n> > patches will svn update, and get similar conflicts.  These might differ\n> > in subtle ways, and now exchanging patches gets more difficult.\n> \n> Instead, do all your work in a branch *other* than the git-svn main\n> branch. When you're ready to merge your stuff into svn, do:\n[snip]\n> This basically results in a *single* commit getting sent to svn,\n> rather than the batch of all the git commits you've been working\n> on. Most svn users don't care about this, because they lose all that\n> granularity whenever they merge a branch anyhow.\n\n... but I, as a git user forced to live in an svn world, *do* value all\nof that history. When I find a bug a month later, I want git-bisect\nto be useful. Further, when I'm reviewing sets of changes in a search\nfor some particular change, I want to be able to skip over large sets\nof patches simply by looking at the first line of a commit log. If I\nsquash all that history down, I have to wade into the patch itself.\n\n-tom\n"},{"id":"120327","messageId":"32541b130908111617m12fa4b97vddfa9793dff31f29@mail.gmail.com","threadId":"20542","inReplyTo":"auto-000020209671@sci.utah.edu","subject":"Re: sharing git work while downstream from svn?","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-08-11T23:17:24Z","receivedAt":"2009-08-11T23:17:24Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Aug 11, 2009 at 11:14 PM, tom fogal wrote:\n> Avery Pennarun writes:\n>> On Tue, Aug 11, 2009 at 10:55 PM, tom fogal wrote:\n>> > This gets to be a mess when trunk changes: I'll rebase + potentially\n>> > fix some conflicts.  Other developers with some of the experimental\n>> > patches will svn update, and get similar conflicts.  These might differ\n>> > in subtle ways, and now exchanging patches gets more difficult.\n>>\n>> Instead, do all your work in a branch *other* than the git-svn main\n>> branch.  When you're ready to merge your stuff into svn, do:\n> [snip]\n>> This basically results in a *single* commit getting sent to svn,\n>> rather than the batch of all the git commits you've been working\n>> on.  Most svn users don't care about this, because they lose all that\n>> granularity whenever they merge a branch anyhow.\n>\n> ... but I, as a git user forced to live in an svn world, *do* value all\n> of that history.  When I find a bug a month later, I want git-bisect\n> to be useful.  Further, when I'm reviewing sets of changes in a search\n> for some particular change, I want to be able to skip over large sets\n> of patches simply by looking at the first line of a commit log.  If I\n> squash all that history down, I have to wade into the patch itself.\n\nThat's the great thing! Your git history never gets lost with this\ntechnique, since you *never* rewind any branches. The detailed\nhistory just never makes it into svn, which has no way of representing\nit anyhow.\n\nAs a bonus, the fact that your git history becomes more and more\ndetailed vs. the svn history slowly makes your case for switching\neverybody else to git that much stronger :)\n\nHave fun,\n\nAvery\n\nP.S. Shameless plug: I wrote the chapter about git-svn in O'Reilly's\n\"Version Control With Git,\" in which I described this technique in\nmore detail. (I *don't* make any money on commissions on that book,\nas I'm not the primary author.)\n"}]}