On Fri, Aug 27, 2010 at 2:03 AM, Jon Seymour <jon.seymour@xxxxxxxxx> wrote: > On Thu, Aug 26, 2010 at 9:53 PM, Erez Zilber <erezzi.list@xxxxxxxxx> wrote: >> Hi, >> >> My repository has several branches. Each branch is for a separate code >> release. Let's assume that I have a branch for V1.0 (branch_1) and a >> branch for V2.0 (branch_2). >> >> Some commits are relevant only for branch_1, some are relevant only >> for branch_2 and some are relevant for both. For the commits that are >> relevant for both branches, I thought about the following solutions: >> 1. Put these common commits in branch_1 and merge branch_1 into >> branch_2. This is bad because it will also merge commits that are >> relevant only for branch_1. >> 2. Cherry-pick the common commits from branch_1 to branch_2. This is >> also bad because the commit ID changes, and in case of conflicts, git >> is unable to tell that these 2 commits are actually the same commit. >> This makes it very difficult to track the changes between branches. >> >> Since there are several other developers and sub-maintainers in this >> project which are rebased on both these branches, I don't want to >> change the git history of my branches because when I do that, >> sub-maintainers and developers lose the reference to their base. >> >> I'm looking for a better solution. Is there any best-practice solution? >> > > As Josh pointed out in another post, the key to sharing commits across > branches is to ensure that the commits that you intend to share > between branches should always be based on a commit that both branches > have in common. That way, when you eventually merge the commit into > the branch the only history it drags in is the history associated with > the patch itself. > > This requires a slight shift in mind set - don't automatically assume > the right thing to do is develop a patch is on the tip of branch_1. If > the branch_1 does contain other stuff that you are not intending to > merge into branch_2, this is probably the wrong thing to do. > > What I tend to do (as described here > http://permalink.gmane.org/gmane.comp.version-control.git/153168), is > to > develop my fixes on the tip of private integration branch (which I > never share), then rebase them onto a suitable base common to all > potential delivery targets later. This works for me, because there > isn't typically much divergence in the files I touch between branches. > It might not work so well in cases where there is significant > divergence. > > jon. > Thanks for the answers. Erez -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html