{"thread":{"id":"24868","subject":"How to handle a git repository with multiple branches","startedAt":"2010-08-26T11:53:49Z","lastAt":"2010-08-31T07:21:01Z","messageCount":5,"participants":["Erez Zilber","Joshua Juran","David Ripton","Jon Seymour"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"149061","messageId":"AANLkTimW-SQi1eprxTPXxF85SBO4d5MU13=dsboNNrzd@mail.gmail.com","threadId":"24868","inReplyTo":null,"subject":"How to handle a git repository with multiple branches","fromName":"Erez Zilber","fromEmail":"erezzi.list@gmail.com","sentAt":"2010-08-26T11:53:49Z","receivedAt":"2010-08-26T11:53:49Z","isPatch":false,"sender":{"key":"erezzi.list@gmail.com","avatar":null},"body":"Hi,\n\nMy repository has several branches. Each branch is for a separate code\nrelease. Let's assume that I have a branch for V1.0 (branch_1) and a\nbranch for V2.0 (branch_2).\n\nSome commits are relevant only for branch_1, some are relevant only\nfor branch_2 and some are relevant for both. For the commits that are\nrelevant for both branches, I thought about the following solutions:\n1. Put these common commits in branch_1 and merge branch_1 into\nbranch_2. This is bad because it will also merge commits that are\nrelevant only for branch_1.\n2. Cherry-pick the common commits from branch_1 to branch_2. This is\nalso bad because the commit ID changes, and in case of conflicts, git\nis unable to tell that these 2 commits are actually the same commit.\nThis makes it very difficult to track the changes between branches.\n\nSince there are several other developers and sub-maintainers in this\nproject which are rebased on both these branches, I don't want to\nchange the git history of my branches because when I do that,\nsub-maintainers and developers lose the reference to their base.\n\nI'm looking for a better solution. Is there any best-practice solution?\n\nThanks,\nErez\n"},{"id":"149062","messageId":"D36A67AE-3477-4D8D-A424-6413D8C4E70C@gmail.com","threadId":"24868","inReplyTo":"AANLkTimW-SQi1eprxTPXxF85SBO4d5MU13=dsboNNrzd@mail.gmail.com","subject":"Re: How to handle a git repository with multiple branches","fromName":"Joshua Juran","fromEmail":"jjuran@gmail.com","sentAt":"2010-08-26T13:09:13Z","receivedAt":"2010-08-26T13:09:13Z","isPatch":false,"sender":{"key":"jjuran@gmail.com","avatar":null},"body":"On Aug 26, 2010, at 4:53 AM, Erez Zilber wrote:\n\n> My repository has several branches. Each branch is for a separate code\n> release. Let's assume that I have a branch for V1.0 (branch_1) and a\n> branch for V2.0 (branch_2).\n>\n> Some commits are relevant only for branch_1, some are relevant only\n> for branch_2 and some are relevant for both. For the commits that are\n> relevant for both branches, I thought about the following solutions:\n> 1. Put these common commits in branch_1 and merge branch_1 into\n> branch_2. This is bad because it will also merge commits that are\n> relevant only for branch_1.\n> 2. Cherry-pick the common commits from branch_1 to branch_2. This is\n> also bad because the commit ID changes, and in case of conflicts, git\n> is unable to tell that these 2 commits are actually the same commit.\n> This makes it very difficult to track the changes between branches.\n>\n> Since there are several other developers and sub-maintainers in this\n> project which are rebased on both these branches, I don't want to\n> change the git history of my branches because when I do that,\n> sub-maintainers and developers lose the reference to their base.\n>\n> I'm looking for a better solution. Is there any best-practice  \n> solution?\n\nOff the top of my head, store each patch in its own branch, based off  \nof a commit common to both branch_1 and branch_2.  Then merge patch  \nbranches into release branches as appropriate.  You might consider  \nalso doing this for patches unique to a release, not just the common  \nones.\n\nJosh\n"},{"id":"149087","messageId":"4C76D9F6.7070306@ripton.net","threadId":"24868","inReplyTo":"AANLkTimW-SQi1eprxTPXxF85SBO4d5MU13=dsboNNrzd@mail.gmail.com","subject":"Re: How to handle a git repository with multiple branches","fromName":"David Ripton","fromEmail":"dripton@ripton.net","sentAt":"2010-08-26T21:17:42Z","receivedAt":"2010-08-26T21:17:42Z","isPatch":false,"sender":{"key":"dripton@ripton.net","avatar":"https://avatars.githubusercontent.com/u/153528?v=4"},"body":"On 08/26/10 07:53, Erez Zilber wrote:\n\n> Some commits are relevant only for branch_1, some are relevant only\n> for branch_2 and some are relevant for both. For the commits that are\n> relevant for both branches, I thought about the following solutions:\n> 1. Put these common commits in branch_1 and merge branch_1 into\n> branch_2. This is bad because it will also merge commits that are\n> relevant only for branch_1.\n> 2. Cherry-pick the common commits from branch_1 to branch_2. This is\n> also bad because the commit ID changes, and in case of conflicts, git\n> is unable to tell that these 2 commits are actually the same commit.\n> This makes it very difficult to track the changes between branches.\n>\n> Since there are several other developers and sub-maintainers in this\n> project which are rebased on both these branches, I don't want to\n> change the git history of my branches because when I do that,\n> sub-maintainers and developers lose the reference to their base.\n>\n> I'm looking for a better solution. Is there any best-practice solution?\n\nFix bugs in the oldest release branch to which the fix applies.  Then \nmerge the old branches into the new ones.\n\nWhen this doesn't work, then you have to cherry pick.\n\n-- \nDavid Ripton    dripton@ripton.net\n"},{"id":"149092","messageId":"AANLkTi=fn1YmK8WW-wfx2Eba8x8RQv3gZ56PU=T7=fLW@mail.gmail.com","threadId":"24868","inReplyTo":"AANLkTimW-SQi1eprxTPXxF85SBO4d5MU13=dsboNNrzd@mail.gmail.com","subject":"Re: How to handle a git repository with multiple branches","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-08-26T23:03:01Z","receivedAt":"2010-08-26T23:03:01Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, Aug 26, 2010 at 9:53 PM, Erez Zilber <erezzi.list@gmail.com> wrote:\n> Hi,\n>\n> My repository has several branches. Each branch is for a separate code\n> release. Let's assume that I have a branch for V1.0 (branch_1) and a\n> branch for V2.0 (branch_2).\n>\n> Some commits are relevant only for branch_1, some are relevant only\n> for branch_2 and some are relevant for both. For the commits that are\n> relevant for both branches, I thought about the following solutions:\n> 1. Put these common commits in branch_1 and merge branch_1 into\n> branch_2. This is bad because it will also merge commits that are\n> relevant only for branch_1.\n> 2. Cherry-pick the common commits from branch_1 to branch_2. This is\n> also bad because the commit ID changes, and in case of conflicts, git\n> is unable to tell that these 2 commits are actually the same commit.\n> This makes it very difficult to track the changes between branches.\n>\n> Since there are several other developers and sub-maintainers in this\n> project which are rebased on both these branches, I don't want to\n> change the git history of my branches because when I do that,\n> sub-maintainers and developers lose the reference to their base.\n>\n> I'm looking for a better solution. Is there any best-practice solution?\n>\n\nAs Josh pointed out in another post, the key to sharing commits across\nbranches is to ensure that the commits that you intend to share\nbetween branches should always be based on a commit that both branches\nhave in common. That way, when you eventually merge the commit into\nthe branch the only history it drags in is the history associated with\nthe patch itself.\n\nThis requires a slight shift in mind set - don't automatically assume\nthe right thing to do is develop a patch is on the tip of branch_1. If\nthe branch_1 does contain other stuff that you are not intending to\nmerge into branch_2, this is probably the wrong thing to do.\n\nWhat I tend to do (as described here\nhttp://permalink.gmane.org/gmane.comp.version-control.git/153168), is\nto\ndevelop my fixes on  the tip of private integration branch (which I\nnever share), then rebase them onto a suitable base common to all\npotential delivery targets later. This works for me, because there\nisn't typically much divergence in the files I touch between branches.\n It might not work so well in cases where there is significant\ndivergence.\n\njon.\n\n> Thanks,\n> Erez\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"},{"id":"149398","messageId":"AANLkTi=eVuRenSOut2stYfdUpFRPbiOaUynrg6DPxQ9t@mail.gmail.com","threadId":"24868","inReplyTo":"AANLkTi=fn1YmK8WW-wfx2Eba8x8RQv3gZ56PU=T7=fLW@mail.gmail.com","subject":"Re: How to handle a git repository with multiple branches","fromName":"Erez Zilber","fromEmail":"erezzi.list@gmail.com","sentAt":"2010-08-31T07:21:01Z","receivedAt":"2010-08-31T07:21:01Z","isPatch":false,"sender":{"key":"erezzi.list@gmail.com","avatar":null},"body":"On Fri, Aug 27, 2010 at 2:03 AM, Jon Seymour <jon.seymour@gmail.com> wrote:\n> On Thu, Aug 26, 2010 at 9:53 PM, Erez Zilber <erezzi.list@gmail.com> wrote:\n>> Hi,\n>>\n>> My repository has several branches. Each branch is for a separate code\n>> release. Let's assume that I have a branch for V1.0 (branch_1) and a\n>> branch for V2.0 (branch_2).\n>>\n>> Some commits are relevant only for branch_1, some are relevant only\n>> for branch_2 and some are relevant for both. For the commits that are\n>> relevant for both branches, I thought about the following solutions:\n>> 1. Put these common commits in branch_1 and merge branch_1 into\n>> branch_2. This is bad because it will also merge commits that are\n>> relevant only for branch_1.\n>> 2. Cherry-pick the common commits from branch_1 to branch_2. This is\n>> also bad because the commit ID changes, and in case of conflicts, git\n>> is unable to tell that these 2 commits are actually the same commit.\n>> This makes it very difficult to track the changes between branches.\n>>\n>> Since there are several other developers and sub-maintainers in this\n>> project which are rebased on both these branches, I don't want to\n>> change the git history of my branches because when I do that,\n>> sub-maintainers and developers lose the reference to their base.\n>>\n>> I'm looking for a better solution. Is there any best-practice solution?\n>>\n>\n> As Josh pointed out in another post, the key to sharing commits across\n> branches is to ensure that the commits that you intend to share\n> between branches should always be based on a commit that both branches\n> have in common. That way, when you eventually merge the commit into\n> the branch the only history it drags in is the history associated with\n> the patch itself.\n>\n> This requires a slight shift in mind set - don't automatically assume\n> the right thing to do is develop a patch is on the tip of branch_1. If\n> the branch_1 does contain other stuff that you are not intending to\n> merge into branch_2, this is probably the wrong thing to do.\n>\n> What I tend to do (as described here\n> http://permalink.gmane.org/gmane.comp.version-control.git/153168), is\n> to\n> develop my fixes on  the tip of private integration branch (which I\n> never share), then rebase them onto a suitable base common to all\n> potential delivery targets later. This works for me, because there\n> isn't typically much divergence in the files I touch between branches.\n>  It might not work so well in cases where there is significant\n> divergence.\n>\n> jon.\n>\n\nThanks for the answers.\n\nErez\n"}]}