{"thread":{"id":"6623","subject":"Question: next, master and pu branches","startedAt":"2007-02-02T05:42:08Z","lastAt":"2007-02-02T06:57:35Z","messageCount":6,"participants":["Alexander Litvinov","Shawn O. Pearce","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"33336","messageId":"200702021142.08975.litvinov2004@gmail.com","threadId":"6623","inReplyTo":null,"subject":"Question: next, master and pu branches","fromName":"Alexander Litvinov","fromEmail":"litvinov2004@gmail.com","sentAt":"2007-02-02T05:42:08Z","receivedAt":"2007-02-02T05:42:08Z","isPatch":false,"sender":{"key":"litvinov2004@gmail.com","avatar":null},"body":"Hello,\n\nCan somebody explain the meaning of next and pu branches and some documenation \nabout using topic branches.\n\nMy development model use two branches now: stable release and develment \nbranch. All changes in the stable release branch are bug-fix only changes. \nAll (or most) of them must go to development release. Now I do this using \ncherry-pick but it is not easy to track what was merged especialy when merge \npruduce confic resloved by hands. Stable branch live long life, much more \nthan 100 commits. \n\nIt seems topic branches can help me here, but reading Documentation under git \nsources teach to make topic branch from the branch point and then merge it to \nboth branches. This can work while stable branch has short life and was not \nheavily rewritten. \n\nIf there any technique that can help me ?\n"},{"id":"33337","messageId":"20070202060030.GA20442@spearce.org","threadId":"6623","inReplyTo":"200702021142.08975.litvinov2004@gmail.com","subject":"Re: Question: next, master and pu branches","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-02T06:00:30Z","receivedAt":"2007-02-02T06:00:30Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Alexander Litvinov wrote:\n> Can somebody explain the meaning of next and pu branches\n\nWithin git.git:\n\n maint: Current stable release. Receives bug fixes for the\n current release.\n\n master: Stable development tip. The tip of this branch will be\n used to create the next stable release.\n\n next: Topics which are pretty stable and are likely to be merged\n into master soon are merged here first, to make them visible to\n a wider community and get more testing.\n\n pu: aka \"Proposed Updates\". Junio publishes a number of branches\n here and continously rebases this branch. Topics here may make\n it into next (and then later master), or may not and just be\n dropped forever.\n\n>and some documenation \n> about using topic branches.\n\nWhat about Documentation/howto/using-topic-branches.txt ?\n \n> My development model use two branches now: stable release and develment \n> branch. All changes in the stable release branch are bug-fix only changes. \n> All (or most) of them must go to development release. Now I do this using \n> cherry-pick but it is not easy to track what was merged especialy when merge \n> pruduce confic resloved by hands. Stable branch live long life, much more \n> than 100 commits. \n> \n> It seems topic branches can help me here, but reading Documentation under git \n> sources teach to make topic branch from the branch point and then merge it to \n> both branches. This can work while stable branch has short life and was not \n> heavily rewritten. \n> \n> If there any technique that can help me ?\n\nThe easiest way to do this is to create a new topic branch from\nthe merge base of the two branches (see git-merge-base's docs for\ndetails). Make the fix on this branch, test it, then merge it into\nyour development branch.\n\nIf additional changes are needed, go back to the topic branch,\nfix it there, then remerge the topic to your development branch.\n\nWhen the topic is finally ready, merge it to your stable branch.\n\nThis is what the documentation suggests, because it works, and\nworks well. This is how Junio manages `next` (which is the same\nas your development branch) and `master` (which is about the same\nas your stable branch).\n\nYou can let git-rerere help you to manage conflicts which might\nreoccur during merges. If you create the .git/rr-cache directory\nthen git-commit and git-merge will automatically use git-rerere to\nhelp you.\n\n\nIf you are cherry-picking stuff back and forth this gets really hard,\nas you point out. The tools don't help you very well here, as there\nisn't enough data to figure out what is where. You can try using\ngit-cherry to tell you which commits are in both branches, but it\nhas limited usefulness if the commits are making different changes.\n\n-- \nShawn.\n"},{"id":"33339","messageId":"7v8xfhksg0.fsf@assigned-by-dhcp.cox.net","threadId":"6623","inReplyTo":"200702021142.08975.litvinov2004@gmail.com","subject":"Re: Question: next, master and pu branches","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-02T06:02:39Z","receivedAt":"2007-02-02T06:02:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alexander Litvinov writes:\n\n> Can somebody explain the meaning of next and pu branches and\n> some documenation about using topic branches.\n>\n> My development model use two branches now: stable release and develment \n> branch. All changes in the stable release branch are bug-fix only changes. \n> All (or most) of them must go to development release. Now I do this using \n> cherry-pick but it is not easy to track what was merged especialy when merge \n> pruduce confic resloved by hands. Stable branch live long life, much more \n> than 100 commits. \n\nI think what you are looking for is how my 'maint' and 'master'\nbranches are maintained; 'maint' corresponds to your \"stable\nrelease\" while 'master' corresponds to your \"develment branch\".\n\nWhen a stable release is cut, 'maint' is forked from there.\n\nTruly obvious corrections will be applied on top of the tip of\n'maint' directly, while if there are any doubt about a proposed\nchange I might fork a topic off of the tip of 'maint' and cook\nthe fix for a while until I finally merge it to 'maint'. This\nway, 'maint' will be \"bugfix only since the last release\".\n\nThe tip of 'maint' will be merged into 'master', from time to\ntime, to make sure that all fixes will be in 'master'.\n\nWhen it is time for a new release to be cut, I'd make sure that\nthe tip of 'maint' is merged into 'master' (it usually is) and\nthen the tip of the 'master' is tagged to be released. After a\nrelease is made, I could have two maintenance branches (one that\ncontinues on top of the old codebase, another that fixes the new\nrelease). A fix that can apply to both codebases will be\napplied to the maintenance branch for the old release and then\nits tip can be pulled into the maintenance branch for the new\nrelease and then its tip can further be merged into the\ndevelopment branch.\n\nAt some point, the codebases for the older release and the\ncurrent release become diverged enough that merging could become\ninpractical (the same bug may need different fix if the\ninfrastracture has become different); you would need to bite the\nbullet and fix it twice (i.e. differently).\n"},{"id":"33345","messageId":"200702021252.14076.litvinov2004@gmail.com","threadId":"6623","inReplyTo":"7v8xfhksg0.fsf@assigned-by-dhcp.cox.net","subject":"Re: Question: next, master and pu branches","fromName":"Alexander Litvinov","fromEmail":"litvinov2004@gmail.com","sentAt":"2007-02-02T06:52:13Z","receivedAt":"2007-02-02T06:52:13Z","isPatch":false,"sender":{"key":"litvinov2004@gmail.com","avatar":null},"body":"> I think what you are looking for is how my 'maint' and 'master'\n> branches are maintained; 'maint' corresponds to your \"stable\n> release\" while 'master' corresponds to your \"develment branch\".\n>\n> When a stable release is cut, 'maint' is forked from there.\n>\n> Truly obvious corrections will be applied on top of the tip of\n> 'maint' directly, while if there are any doubt about a proposed\n> change I might fork a topic off of the tip of 'maint' and cook\n> the fix for a while until I finally merge it to 'maint'. This\n> way, 'maint' will be \"bugfix only since the last release\".\n>\n> The tip of 'maint' will be merged into 'master', from time to\n> time, to make sure that all fixes will be in 'master'.\n>\n> When it is time for a new release to be cut, I'd make sure that\n> the tip of 'maint' is merged into 'master' (it usually is) and\n> then the tip of the 'master' is tagged to be released. After a\n> release is made, I could have two maintenance branches (one that\n> continues on top of the old codebase, another that fixes the new\n> release). A fix that can apply to both codebases will be\n> applied to the maintenance branch for the old release and then\n> its tip can be pulled into the maintenance branch for the new\n> release and then its tip can further be merged into the\n> development branch.\n>\n> At some point, the codebases for the older release and the\n> current release become diverged enough that merging could become\n> inpractical (the same bug may need different fix if the\n> infrastracture has become different); you would need to bite the\n> bullet and fix it twice (i.e. differently).\n\nThanks for detailed description. As a cunclusion I would like to say: all bug \nfixes are made in the stable branch and then stable branch will be merged to \ndevelopment branch. That is easy !\n"},{"id":"33346","messageId":"200702021254.44992.litvinov2004@gmail.com","threadId":"6623","inReplyTo":"20070202060030.GA20442@spearce.org","subject":"Re: Question: next, master and pu branches","fromName":"Alexander Litvinov","fromEmail":"litvinov2004@gmail.com","sentAt":"2007-02-02T06:54:44Z","receivedAt":"2007-02-02T06:54:44Z","isPatch":false,"sender":{"key":"litvinov2004@gmail.com","avatar":null},"body":"> You can let git-rerere help you to manage conflicts which might\n> reoccur during merges. If you create the .git/rr-cache directory\n> then git-commit and git-merge will automatically use git-rerere to\n> help you.\n\nYes git-rerere is a black magic tool, but it works :-)\nByt he way, why git-pull (or possible git-merge) does not commit the merge \nresult after conflict was fixed by git-rerere ?\n"},{"id":"33347","messageId":"20070202065735.GA20832@spearce.org","threadId":"6623","inReplyTo":"200702021254.44992.litvinov2004@gmail.com","subject":"Re: Question: next, master and pu branches","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-02T06:57:35Z","receivedAt":"2007-02-02T06:57:35Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Alexander Litvinov wrote:\n> > You can let git-rerere help you to manage conflicts which might\n> > reoccur during merges. If you create the .git/rr-cache directory\n> > then git-commit and git-merge will automatically use git-rerere to\n> > help you.\n> \n> Yes git-rerere is a black magic tool, but it works :-)\n> Byt he way, why git-pull (or possible git-merge) does not commit the merge \n> result after conflict was fixed by git-rerere ?\n\nNo, it doesn't. That way you can review the result of the merge\nfirst and verify its indeed correct.\n\n-- \nShawn.\n"}]}