{"thread":{"id":"8625","subject":"merge into branch currently not active / checked out","startedAt":"2007-06-17T07:22:25Z","lastAt":"2007-06-20T07:54:46Z","messageCount":5,"participants":["Thomas Glanzmann","Junio C Hamano","Alex Riesen","Karl Hasselström"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"45208","messageId":"20070617072225.GF23473@cip.informatik.uni-erlangen.de","threadId":"8625","inReplyTo":null,"subject":"merge into branch currently not active / checked out","fromName":"Thomas Glanzmann","fromEmail":"thomas@glanzmann.de","sentAt":"2007-06-17T07:22:25Z","receivedAt":"2007-06-17T07:22:25Z","isPatch":false,"sender":{"key":"thomas@glanzmann.de","avatar":null},"body":"Hello,\nis it possible to merge into a branch currently not active/checked out?\nI have the following scenario:\n\n - One branch per feature (cstatus, headers, mutt-collapse-flags, small-fixes)\n - One upstream branch (master)\n - One branch that has every feature branch (tg)\n\n(faui00u) [~/work/mutt/mutt] git branch\n cstatus\n headers\n master\n mutt-collapse-flags\n small-fixes\n* tg\n\nI want to merge master in every of the feature branches. Is that possible or\njust bullshit because I don't have a working tree to handle conflicts?\n\n Thomas\n"},{"id":"45216","messageId":"7vmyyzylpl.fsf@assigned-by-dhcp.pobox.com","threadId":"8625","inReplyTo":"20070617072225.GF23473@cip.informatik.uni-erlangen.de","subject":"Re: merge into branch currently not active / checked out","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-17T09:27:50Z","receivedAt":"2007-06-17T09:27:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Glanzmann writes:\n\n> Hello,\n> is it possible to merge into a branch currently not active/checked out?\n> I have the following scenario:\n>\n> - One branch per feature (cstatus, headers, mutt-collapse-flags, small-fixes)\n> - One upstream branch (master)\n> - One branch that has every feature branch (tg)\n>\n> (faui00u) [~/work/mutt/mutt] git branch\n> cstatus\n> headers\n> master\n> mutt-collapse-flags\n> small-fixes\n> * tg\n>\n> I want to merge master in every of the feature branches. Is that possible or\n> just bullshit because I don't have a working tree to handle conflicts?\n\nExactly. Merge would want to have working tree, so merging into\nthe current branch is not just the default but the only mode of\noperation.\n\nIn general, I would recommend against merging 'master' to topic\nbranches, if you can avoid it.\n\nThere are two reasons you would ever want to merge 'master' to\nthem.\n\n (1) You notice that 'master' has new stuff. It does not\n necessarily conflict with the changes you made to your\n topic branches, and it often doesn't, if the project is\n well modularized. Still, you want to make sure that your\n topic branches are compatible with it. IOW to see if the\n changes in the master did not break your topic.\n\n (2) You notice that 'master' actually have new change that\n actively interact with what you set out to do in some of\n your toipcs.\n\nIf you plan to eventually ask somebody who integrates the\n'master' to pull from you, and keep the resulting development\nhistory clean, (1) is _NOT_ a good reason to merge 'master' into\nyour topics. Because after your topic finally is finished, when\n'master' pulls it, it will see many \"senseless\" merges from\nitself.\n\nSuch \"an integration testing\" is better done, instead, by\nforking a 'test' (perhaps throw-away) branch from 'master', and\nmerging all your topics into it.\n\nOn the other hand, (2) is a valid reason to resolve conflict\n(both textual and semantic) early before you eventually present\nyour work for inclusion to 'master'.\n\nAlso, if you do not publish your work-in-progress topics, you\nmight want to consider rebasing on top of 'master', instead of\n'merging'. Rebase can take the topic branch name and switch\nyour current branch for you when you give it, like so:\n\n\t$ git rebase master topic1\n $ git rebase master topic2\n ...\n"},{"id":"45217","messageId":"20070617094521.GA2763@steel.home","threadId":"8625","inReplyTo":"20070617072225.GF23473@cip.informatik.uni-erlangen.de","subject":"Re: merge into branch currently not active / checked out","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-06-17T09:45:21Z","receivedAt":"2007-06-17T09:45:21Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Thomas Glanzmann, Sun, Jun 17, 2007 09:22:25 +0200:\n> Hello,\n> is it possible to merge into a branch currently not active/checked out?\n\nnot in current implementation of merge algorithms and conflict\nhandling.\n\n> I want to merge master in every of the feature branches. Is that possible or\n> just bullshit because I don't have a working tree to handle conflicts?\n\nYou are _very_ welcome to improve this :) It's not very often need, so\npeople just do without it (i.e. clone the repo, do a merge there and\npull back).\n"},{"id":"45218","messageId":"20070617101635.GK23473@cip.informatik.uni-erlangen.de","threadId":"8625","inReplyTo":"7vmyyzylpl.fsf@assigned-by-dhcp.pobox.com","subject":"Re: merge into branch currently not active / checked out","fromName":"Thomas Glanzmann","fromEmail":"thomas@glanzmann.de","sentAt":"2007-06-17T10:16:35Z","receivedAt":"2007-06-17T10:16:35Z","isPatch":false,"sender":{"key":"thomas@glanzmann.de","avatar":null},"body":"Hi Junio,\n\n> If you plan to eventually ask somebody who integrates the 'master' to\n> pull from you, and keep the resulting development history clean, (1)\n> is _NOT_ a good reason to merge 'master' into your topics. Because\n> after your topic finally is finished, when 'master' pulls it, it will\n> see many \"senseless\" merges from itself.\n\nthe problem is. Getting a patch into mutt takes several years. At least\nit took for the hcache. So what I do is keep my patches up2date on top\nof there HEAD. So I prefer topic branches. And my patches throw _once_\nin 4 years a conflict that was not automatically resolved. I used\nbitkeeper before, now I use git.\n\n> Such \"an integration testing\" is better done, instead, by forking a\n> 'test' (perhaps throw-away) branch from 'master', and merging all your\n> topics into it.\n\nI dislike it myself.\n\n> Also, if you do not publish your work-in-progress topics, you\n> might want to consider rebasing on top of 'master', instead of\n> 'merging'. Rebase can take the topic branch name and switch\n> your current branch for you when you give it, like so:\n\nI don't push my work other than in patches that is, so I am going to\ngive it a try. I always wanted to try rebase, but I never actually did\ntry it.\n\nThanks,\n Thomas\n"},{"id":"45417","messageId":"20070620075446.GA30186@diana.vm.bytemark.co.uk","threadId":"8625","inReplyTo":"20070617101635.GK23473@cip.informatik.uni-erlangen.de","subject":"Re: merge into branch currently not active / checked out","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-06-20T07:54:46Z","receivedAt":"2007-06-20T07:54:46Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-06-17 12:16:35 +0200, Thomas Glanzmann wrote:\n\n> the problem is. Getting a patch into mutt takes several years. At\n> least it took for the hcache. So what I do is keep my patches\n> up2date on top of there HEAD. So I prefer topic branches. And my\n> patches throw _once_ in 4 years a conflict that was not\n> automatically resolved. I used bitkeeper before, now I use git.\n\nFor this use case, I'd say rebasing is the right thing to do --\notherwise you accumulate a 4-year-long history of uninteresting\nmerges, as Junio warned.\n\nThere are two cases where rebasing is worse than a \"real\" branch\nthat's merged instead of rebased:\n\n 1. Other people base their work on yours, and need to be able to\n pull. They want a stable foundation to build on, one that doesn't\n move.\n\n 2. Your work is large enough that it's too much work to rebase it.\n (This also implies that when you merge, you get interesting\n conflicts, since for the case of autoresolved conflicts, rebasing\n isn't that much more expensive than merging.)\n\nSince you describe your work as \"a patch\", I'm guessing neither excuse\napplies to you. :-)\n\n> I don't push my work other than in patches that is, so I am going to\n> give it a try. I always wanted to try rebase, but I never actually\n> did try it.\n\n\n You could also try StGIT. Rebasing a patch series on top of a git\n branch is what it does.\n\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"}]}