On 08/26/10 07:53, Erez Zilber wrote:
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?
Fix bugs in the oldest release branch to which the fix applies. Then merge the old branches into the new ones.
When this doesn't work, then you have to cherry pick. -- David Ripton dripton@xxxxxxxxxx -- 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