{"thread":{"id":"21750","subject":"Commiting changes onto more than one branch","startedAt":"2009-11-25T16:31:59Z","lastAt":"2009-11-25T23:56:31Z","messageCount":12,"participants":["Mike Jarmy","Eugene Sajine","Thomas Rast","Jakub Narebski","Avery Pennarun","Nicolas Pitre","Junio C Hamano","Daniel Barkalow","Andreas Schwab"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"128316","messageId":"6b4a562b0911250831q332ac3b5m6ee38f59e7a6f391@mail.gmail.com","threadId":"21750","inReplyTo":null,"subject":"Commiting changes onto more than one branch","fromName":"Mike Jarmy","fromEmail":"mjarmy@gmail.com","sentAt":"2009-11-25T16:31:59Z","receivedAt":"2009-11-25T16:31:59Z","isPatch":false,"sender":{"key":"mjarmy@gmail.com","avatar":null},"body":"Hi,\n\nAt my day job, I'm doing the groundwork for recommending that we\nswitch to a DVCS from a proprietary centralized VCS. I find git's\nbranching ability very compelling, and I think we would use it\nextensively. I work on a very large project (many thousands of files)\nthat has been around for many years, and has had several different\nreleases. Right now, each release has its own top level directory,\nbut I'd like to change that so we use branches instead, out of one\ngreat big git repository. My plan is to set up the repository such\nthat the initial state at switchover will have a branch for the\ncurrent state of each of our releases. Lets say that the branches for\neach release are called v1, v2, etc.\n\nMy question is this: How do I manage a checkin for a bugfix that\naffects, say, only branches v3, v4, and v5?\n\nSuppose that I checkout the v3 branch, and fix the bug by editing\nseveral different files. (Lets assume for now that the files in\nquestion have not diverged between any of the 3 branches, even though\ntons of other files have changed). How do I commit the bugfix into\nall of v3, v4 and v5? Clearly, merging the branches together would be\nbad. So I think what I should do is perform 3 different commits, but\nI'm not quite sure how to juggle the git index (or stash or whatever)\nto accomplish this. This may be a really obvious question, but I'm a\nconfused git newbie.\n\nAlso, even though I may need to do 3 commits, it would be nice if the\ncommits were related together in some way, since in a sense they\nrepresent only one action (namely, fixing the bug). Is there a way to\ndo that, so that its clear in gitk that it was really one unified\nthing? The very worst thing about our current VCS is that it has no\nconcept of a 'commit', only individual file histories. Git would fix\nthat for us, but it would be nirvana if we could group commits for a\ngiven bugfix across branches somehow, while not merging the branches\ntogether.\n\nOne last question -- lets make the problem slightly more complicated\nby specify that some of the edited files changed between, say, v4 and\nv5. I know how to handle a simple merge conflict in git, but is there\nanything different about my multi-branched, grouped-together case\nhere? The answer to this question may be obvious once I understand\nhow to do the simpler, unconflicting checkin.\n\nThanks,\nMike Jarmy\n"},{"id":"128317","messageId":"76c5b8580911250838x361ae081n271fcee2d1234703@mail.gmail.com","threadId":"21750","inReplyTo":"6b4a562b0911250831q332ac3b5m6ee38f59e7a6f391@mail.gmail.com","subject":"Re: Commiting changes onto more than one branch","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2009-11-25T16:38:39Z","receivedAt":"2009-11-25T16:38:39Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":">\n> Suppose that I checkout the v3 branch, and fix the bug by editing\n> several different files.  (Lets assume for now that the files in\n> question have not diverged between any of the 3 branches, even though\n> tons of other files have changed).  How do I commit the bugfix into\n> all of v3, v4 and v5?  Clearly, merging the branches together would be\n> bad.  So I think what I should do is perform 3 different commits, but\n> I'm not quite sure how to juggle the git index (or stash or whatever)\n> to accomplish this.  This may be a really obvious question, but I'm a\n> confused git newbie.\n\nIt as not as clear for me why you think merge will be bad?\nIf you commit your changes to the v3, then merging to v4 and v5 (which\nare not changed) should be very simple fast forward merge. Which means\njust move the pointer to the last commit from v3\n\nAm i missing something?\n\nThanks,\nEugene\n"},{"id":"128318","messageId":"6b4a562b0911250847x59116687iba1d1640ca6c3887@mail.gmail.com","threadId":"21750","inReplyTo":"76c5b8580911250838x361ae081n271fcee2d1234703@mail.gmail.com","subject":"Re: Commiting changes onto more than one branch","fromName":"Mike Jarmy","fromEmail":"mjarmy@gmail.com","sentAt":"2009-11-25T16:47:54Z","receivedAt":"2009-11-25T16:47:54Z","isPatch":false,"sender":{"key":"mjarmy@gmail.com","avatar":null},"body":"On Wed, Nov 25, 2009 at 11:38 AM, Eugene Sajine wrote:\n>>\n>> Suppose that I checkout the v3 branch, and fix the bug by editing\n>> several different files.  (Lets assume for now that the files in\n>> question have not diverged between any of the 3 branches, even though\n>> tons of other files have changed).  How do I commit the bugfix into\n>> all of v3, v4 and v5?  Clearly, merging the branches together would be\n>> bad.  So I think what I should do is perform 3 different commits, but\n>> I'm not quite sure how to juggle the git index (or stash or whatever)\n>> to accomplish this.  This may be a really obvious question, but I'm a\n>> confused git newbie.\n>\n> It as not as clear for me why you think merge will be bad?\n> If you commit your changes to the v3, then merging to v4 and v5 (which\n> are not changed) should be very simple fast forward merge. Which means\n> just move the pointer to the last commit from v3\n>\n> Am i missing something?\n\nI guess I didn't explain it too well, I made it sound like v3, v4 and\nv5 were still more-or-less the same. What I'm thinking about here is\na case where we have switched to git a while back, and then done a lot\nof work on the various different branches, so that v3, v4 and v5 have\ndiverged very far from each other. In that case, we would never want\nto merge them together.\n"},{"id":"128319","messageId":"200911251747.57456.trast@student.ethz.ch","threadId":"21750","inReplyTo":"6b4a562b0911250831q332ac3b5m6ee38f59e7a6f391@mail.gmail.com","subject":"Re: Commiting changes onto more than one branch","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-11-25T16:47:55Z","receivedAt":"2009-11-25T16:47:55Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Mike Jarmy wrote:\n> Suppose that I checkout the v3 branch, and fix the bug by editing\n> several different files. (Lets assume for now that the files in\n> question have not diverged between any of the 3 branches, even though\n> tons of other files have changed). How do I commit the bugfix into\n> all of v3, v4 and v5? Clearly, merging the branches together would be\n> bad. So I think what I should do is perform 3 different commits, but\n> I'm not quite sure how to juggle the git index (or stash or whatever)\n> to accomplish this. This may be a really obvious question, but I'm a\n> confused git newbie.\n\nYou can build the fix on top of the merge-base of v3, v4 and v5, i.e.\n\n git checkout -b myfix $(git merge-base v3 $(git merge-base v4 v5))\n # work\n git commit\n\nand then merge it to each of the version branches:\n\n for b in v3 v4 v5; do\n git checkout $b\n git merge myfix\n done\n\nSo much for the theory. In the model suggested in the gitworkflows(7)\nmanpage and used in git.git, v3 is contained in v4 and similar for v5.\nThis means that after merging (possibly several) fixes to v3, you can\nmerge v3 into v4 and v4 into v5 (and so on, through all versions) to\npropagate the fixes.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"128320","messageId":"m38wdublbq.fsf@localhost.localdomain","threadId":"21750","inReplyTo":"6b4a562b0911250831q332ac3b5m6ee38f59e7a6f391@mail.gmail.com","subject":"Re: Commiting changes onto more than one branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-11-25T16:50:55Z","receivedAt":"2009-11-25T16:50:55Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Mike Jarmy writes:\n\n> My question is this: How do I manage a checkin for a bugfix that\n> affects, say, only branches v3, v4, and v5?\n\nTake a look at \"Resolving conflicts/dependencies between topic\nbranches early\" blog post by Junio C Hamano (git maintainer) at \nhttp://gitster.livejournal.com/27297.html\n\nIn short the solution is to create separate topic branch for a bugfix,\nbranching off earliest place where it would be relevant, then merge\nthis bugfix branch into all development branches you need\n(e.g. maint-v3, maint-v4, maint-v5, master).\n\nThis means:\n\n $ git checkout -b fix-frobulator--issue-1235 maint-v3\n \n \n $ git checkout maint-v3\n $ git merge fix-frobulator--issue-1235\n \n\n $ git checkout maint-v4\n $ git merge fix-frobulator--issue-1235\n \n\n [...]\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"128322","messageId":"32541b130911250938y63a78e86p3f9b842999ff932c@mail.gmail.com","threadId":"21750","inReplyTo":"6b4a562b0911250847x59116687iba1d1640ca6c3887@mail.gmail.com","subject":"Re: Commiting changes onto more than one branch","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-11-25T17:38:56Z","receivedAt":"2009-11-25T17:38:56Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, Nov 25, 2009 at 11:47 AM, Mike Jarmy wrote:\n> I guess I didn't explain it too well, I made it sound like v3, v4 and\n> v5 were still more-or-less the same.  What I'm thinking about here is\n> a case where we have switched to git a while back, and then done a lot\n> of work on the various different branches, so that v3, v4 and v5 have\n> diverged very far from each other.  In that case, we would never want\n> to merge them together.\n\nWhat many people do is, in fact, to merge v3->v4->v5.\n\nThis isn't as crazy as it sounds. Once upon a time, v4 was just an\nearlier version of v3, right? And when you fix a bug in v3, it was\nusually also a bug in v4, right? So in fact, for many projects, it's\nsafe to say that \"after we created v4, all further changes to v3\nshould be propagated to v4.\" And likewise from v4 to v5.\n\nIn that case, you'd simply do\n\n git checkout v3\n # commit your fix\n git checkout v4\n git merge v3\n\nNow, setting that up in the *first* place can be a bit tricky, since\nthe way your imported history probably currently works, git doesn't\nactually know that the history of v4 is a superset of the history of\nv3; it thinks of them as two totally different histories, and merging\nfrom one to the other will be completely disastrous. So you have to\ndo a bit of setup first\n\n # manually make sure all your required patches from v3 are now in v4.\n # just do it the way you used to do it (the hard way)\n # now tell git that it's done:\n git checkout v4\n git merge -s ours v3\n\nAfter that, future merges from v3 to v4 will be easy (the first set of\nsteps above) and include only the newer changes.\n\nNote that merging fixes back from v4 to v3 is entirely different,\nbecause you'll *never* want to take *all* the changes from v4 and put\nthem into v3. The best thing to do is apply them to v3 first, then\nmerge them into v4, but of course that won't always be how developers\nend up doing it. In that case, you can backport them using 'git\ncherry-pick' (see the git docs).\n\nNote that using topic branches, as Thomas and Jakub mentioned, is\northogonal to this method. That is, your problem could be resolved by\ndoing that, or this, or both. (Although if the histories really are\ntotally disjoint, you'll still need to do something like the '-s ours'\ntrick first.) On my own projects, I do a bit of both methods; simple\nbugfixes go straight to the earliest relevant release branch, but\nbigger changes go on topic branches.\n\nHave fun,\n\nAvery\n"},{"id":"128323","messageId":"6b4a562b0911250940k29d5e7eck2bb35d6831ed3af9@mail.gmail.com","threadId":"21750","inReplyTo":"m38wdublbq.fsf@localhost.localdomain","subject":"Re: Commiting changes onto more than one branch","fromName":"Mike Jarmy","fromEmail":"mjarmy@gmail.com","sentAt":"2009-11-25T17:40:15Z","receivedAt":"2009-11-25T17:40:15Z","isPatch":false,"sender":{"key":"mjarmy@gmail.com","avatar":null},"body":"Jakub Narebski wrote:\n> Take a look at \"Resolving conflicts/dependencies between topic\n> branches early\" blog post by Junio C Hamano (git maintainer) at\n> http://gitster.livejournal.com/27297.html\n>\n> In short the solution is to create separate topic branch for a bugfix,\n> branching off earliest place where it would be relevant, then merge\n> this bugfix branch into all development branches you need\n> (e.g. maint-v3, maint-v4, maint-v5, master).\n\nThanks guys. I think some cross between this and the cherry-picking\nidea would work for us most of the time, if we go with the workflow\nthat I originally specified. I like the branch-per-bugfix idea -- its\ntaking some time for me to free my mind to the point where I grok how\nlightweight and flexible branching really is. Just branch off from\nthe earliest affected release, naming the branch after the bug\n('fix-frobulator--issue-1235'). When finished, merge/cherry-pick back\ninto the various branches.\n\nThomas's idea of using a more sophisticated workflow has definitely\ngot me thinking. Back in the day, once we started working on a new\nrelease, say v6, then the other branches to an extent become\nmothballed except for bugfixes. In that case, using a merge-base\napproach would make sense. More and more though, we have started to\nbuild separate sub-projects on top of specific releases -- in other\nwords, we are simultaneously making a new product on top of v4, while\npreparing to release v5, and getting ready to start work on v6 in\nearnest, all the while fixing bugs across mulitple releases going all\nthe way back to v2. Its getting very complicated :-). And our\ncurrent VCS is starting to become an active hindrance in helping us\nmanage all this in a sane way.\n\nWhat I'm going to do is set up a toy environment that mirrors what I\nhope our final repository will look like. Then I'll play with it for\na while and concoct corner-case scenarios and see how it holds up.\nOnce I have a workflow that I like, I can demonstrate it to my\ncolleagues in gitk, and we can think about how to make it better.\n\nThanks,\nMike Jarmy\n"},{"id":"128324","messageId":"alpine.LFD.2.00.0911251237000.2059@xanadu.home","threadId":"21750","inReplyTo":"6b4a562b0911250831q332ac3b5m6ee38f59e7a6f391@mail.gmail.com","subject":"Re: Commiting changes onto more than one branch","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2009-11-25T17:43:55Z","receivedAt":"2009-11-25T17:43:55Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 25 Nov 2009, Mike Jarmy wrote:\n\n> My question is this: How do I manage a checkin for a bugfix that\n> affects, say, only branches v3, v4, and v5?\n> \n> Suppose that I checkout the v3 branch, and fix the bug by editing\n> several different files. (Lets assume for now that the files in\n> question have not diverged between any of the 3 branches, even though\n> tons of other files have changed). How do I commit the bugfix into\n> all of v3, v4 and v5? Clearly, merging the branches together would be\n> bad. So I think what I should do is perform 3 different commits, but\n> I'm not quite sure how to juggle the git index (or stash or whatever)\n> to accomplish this. This may be a really obvious question, but I'm a\n> confused git newbie.\n\nBesides what other people have already suggested, you might simply elect \nto use 'git cherry-pick' on the v4 and v5 branches to copy the fix from \nthe v3 branch.\n\n> Also, even though I may need to do 3 commits, it would be nice if the\n> commits were related together in some way, since in a sense they\n> represent only one action (namely, fixing the bug). Is there a way to\n> do that, so that its clear in gitk that it was really one unified\n> thing? \n\nYou can use the -x argument with 'git cherry-pick'. This won't create a \nformal history graph but at least the commit log will record a reference \nto the original fix.\n\n\nNicolas\n"},{"id":"128327","messageId":"7vaayazb2a.fsf@alter.siamese.dyndns.org","threadId":"21750","inReplyTo":"6b4a562b0911250847x59116687iba1d1640ca6c3887@mail.gmail.com","subject":"Re: Commiting changes onto more than one branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-25T18:58:05Z","receivedAt":"2009-11-25T18:58:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Jarmy writes:\n\n> I guess I didn't explain it too well, I made it sound like v3, v4 and\n> v5 were still more-or-less the same. What I'm thinking about here is\n> a case where we have switched to git a while back, and then done a lot\n> of work on the various different branches, so that v3, v4 and v5 have\n> diverged very far from each other. In that case, we would never want\n> to merge them together.\n\nI take it to mean that even though v[345] have diverged, the area that the\nparticular change you have in mind has to touch haven't changed since they\nforked. Otherwise you wouldn't be able to apply the same change to all of\nthem in the same form and instead would be making the logically same\nchange in physically different ways per branch, and you won't be asking\nthis question.\n\n o--o--o--o--o--o--o--o v4\n /\n --o--x--x--x--x--x--x--x v3\n\nIf you implemented your change at the tip of v3 branch and merge the\nresult to v4, you will pull _all_ of 'x' into v4 that may not be desirable\nif the branches diverged a lot, of course. \n\n o--o--o--o--o--o--o--o-------M v4\n / /\n --o--x--x--x--x--x--x--x /\n \\ /\n Y---Y your change(s) == v3\n\nBut nobody tells you to do this.\n\nInstead, you can fork such a topic from the latest common.\n\n o--o--o--o--o--o--o--o v4\n /\n --o--x--x--x--x--x--x--x v3\n \\\n Y---Y\n your change(s)\n\nand merging this to v3 and v4 will have the desired effect.\n\n o--o--o--o--o--o--o--o---------M v4\n / /\n --o--x--x--x--x--x--x--x---M v3 /\n \\ / /\n Y---Y----------------.-----.\n your change(s)\n\nThe merges will incorporate this particular change alone without dragging\nanything else. When you merge it to v4, none of the unrelated 'x' will be\nmerged into it.\n\nIn general you shouldn't fork a topic from the _tip_ of the oldest branch,\nif the branches are not meant to be merged as a whole.\n\nOf course, if this becomes cumbersome, you would adopt a better branch\nmanagement to keep the numbers of 'x' that shouldn't be in later branches\nto the minimum.\n"},{"id":"128331","messageId":"6b4a562b0911251143s63f09f7bwe4b67d6871d8a1b2@mail.gmail.com","threadId":"21750","inReplyTo":"7vaayazb2a.fsf@alter.siamese.dyndns.org","subject":"Re: Commiting changes onto more than one branch","fromName":"Mike Jarmy","fromEmail":"mjarmy@gmail.com","sentAt":"2009-11-25T19:43:02Z","receivedAt":"2009-11-25T19:43:02Z","isPatch":false,"sender":{"key":"mjarmy@gmail.com","avatar":null},"body":"Junio C Hamano wrote:\n> I take it to mean that even though v[345] have diverged, the area that the\n> particular change you have in mind has to touch haven't changed since they\n> forked.\n\nCorrect. Sometimes, there might be unrelated changes to a given file\nor files, in which case conflict resolution will be done manually.\nBut generally speaking, bugfixes will tend to go on quite cleanly.\n\n> Instead, you can fork such a topic from the latest common.\n>\n>        o--o--o--o--o--o--o--o v4\n>       /\n>    --o--x--x--x--x--x--x--x v3\n>       \\\n>        Y---Y\n>            your change(s)\n>\n> and merging this to v3 and v4 will have the desired effect.\n>\n>        o--o--o--o--o--o--o--o---------M v4\n>       /                              /\n>    --o--x--x--x--x--x--x--x---M v3  /\n>       \\                      /     /\n>        Y---Y----------------.-----.\n>            your change(s)\n>\n> The merges will incorporate this particular change alone without dragging\n> anything else.  When you merge it to v4, none of the unrelated 'x' will be\n> merged into it.\n\nThat sounds a whole lot like what I need.\n\nRight now I'm thinking that the right approach is that once we have\nreleased v3, and started working on v4 heavily, we will probably not\nwant to check any commits directly into v3. Bugfixes will have their\nown branch. If there is a whole new project or whatever being done\non top of v3, it will have its own branch as well.\n\nSo once v3 is in beta or whatever and we declare a code freeze, we\ncould have a rule that all commits must be merge-commits coming from\ndedicated branches with descriptive, intelligible names. For each\ndedicated branch, some thought will have to be given as to just where\noff of v3 to branch it from (not just carelessly off the latest tip).\nMeanwhile, new development will continue on v4, with lots of commits\ngoing right into the branch (or into v4 sub-branches with occasional\nmerge-commits into v4).\n"},{"id":"128374","messageId":"alpine.LNX.2.00.0911251752330.14365@iabervon.org","threadId":"21750","inReplyTo":"6b4a562b0911251143s63f09f7bwe4b67d6871d8a1b2@mail.gmail.com","subject":"Re: Commiting changes onto more than one branch","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-11-25T23:41:29Z","receivedAt":"2009-11-25T23:41:29Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 25 Nov 2009, Mike Jarmy wrote:\n\n> Junio C Hamano wrote:\n> > I take it to mean that even though v[345] have diverged, the area that the\n> > particular change you have in mind has to touch haven't changed since they\n> > forked.\n> \n> Correct. Sometimes, there might be unrelated changes to a given file\n> or files, in which case conflict resolution will be done manually.\n> But generally speaking, bugfixes will tend to go on quite cleanly.\n> \n> > Instead, you can fork such a topic from the latest common.\n> >\n> >        o--o--o--o--o--o--o--o v4\n> >       /\n> >    --o--x--x--x--x--x--x--x v3\n> >       \\\n> >        Y---Y\n> >            your change(s)\n> >\n> > and merging this to v3 and v4 will have the desired effect.\n> >\n> >        o--o--o--o--o--o--o--o---------M v4\n> >       /                              /\n> >    --o--x--x--x--x--x--x--x---M v3  /\n> >       \\                      /     /\n> >        Y---Y----------------.-----.\n> >            your change(s)\n> >\n> > The merges will incorporate this particular change alone without dragging\n> > anything else.  When you merge it to v4, none of the unrelated 'x' will be\n> > merged into it.\n> \n> That sounds a whole lot like what I need.\n> \n> Right now I'm thinking that the right approach is that once we have\n> released v3, and started working on v4 heavily, we will probably not\n> want to check any commits directly into v3. Bugfixes will have their\n> own branch. If there is a whole new project or whatever being done\n> on top of v3, it will have its own branch as well.\n> \n> So once v3 is in beta or whatever and we declare a code freeze, we\n> could have a rule that all commits must be merge-commits coming from\n> dedicated branches with descriptive, intelligible names. For each\n> dedicated branch, some thought will have to be given as to just where\n> off of v3 to branch it from (not just carelessly off the latest tip).\n> Meanwhile, new development will continue on v4, with lots of commits\n> going right into the branch (or into v4 sub-branches with occasional\n> merge-commits into v4).\n\nIt's worth noting that you don't have to have any general visibility to \nthe dedicated branch. If you look at Junio's graph, there are only two \nbranches marked: v3 and v4. The stuff in the bottom line only appears as \nthe second parent in the merge commits. Git's data model doesn't require a \nbranch for a commit to be \"on\" like many other VCSes, so it's perfectly \nreasonable for a developer to make a temporary branch, create the fix in \nsome private repository, merge it to each applicable official branch, and \nthen discard the temporary branch. (The temporary branch is only needed at \nall so that the developer has some way to refer to the fix while merging \nit, and the name only matters in that humans will see it in the merge \ncommit message.)\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"128376","messageId":"m2pr76jh00.fsf@igel.home","threadId":"21750","inReplyTo":"alpine.LNX.2.00.0911251752330.14365@iabervon.org","subject":"Re: Commiting changes onto more than one branch","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2009-11-25T23:56:31Z","receivedAt":"2009-11-25T23:56:31Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Daniel Barkalow writes:\n\n> (The temporary branch is only needed at all so that the developer has\n> some way to refer to the fix while merging it, and the name only\n> matters in that humans will see it in the merge commit message.)\n\nIf you merge by commit-ish the branch name does not even appear in the\ncommit message.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"}]}