On Aug 26, 2010, at 4:53 AM, Erez Zilber wrote:
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?
Off the top of my head, store each patch in its own branch, based off
of a commit common to both branch_1 and branch_2. Then merge patch
branches into release branches as appropriate. You might consider
also doing this for patches unique to a release, not just the common
ones.
Josh
--
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