Re: git merge and cherry-pick and duplicated commits?

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 14, 2009, 20:16 UTC
Message-ID: <7v4p011w3r.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <2729632a0901141033p47b4d8dah46f5bac27307d306@mail.gmail.com>

skillzero@gmail.com writes:

Show 5 quoted lines

> Related to this, is there a way to easily find the common merge base
> given a bunch of a branches? When I want to fix a bug, I want to say
> "Given branches A, B, C, D, and E, where should I fork my bug fix
> branch from so that I can merge this branch into all those branches
> without getting duplicate commits?".

You do not necessarily have to fork from, nor merge into, any of them.

If you fixed a bug, you would hopefully know where the bug was injected at into your history. You may have bisected it down to one commit $BAD. You can fork your fix on top of that $BAD commit:

	$ git checkout -b fix-bug-foo $BAD

All of the branches that share the commit have the bug, so your fix could be merged to all of them if you really wanted to, and you should do so if these A...E branches are meant to be consumed on their own.

But if the branches A...E you are about are for developing independent topics, and if their theme won't get affected by the bug, it is much better not to merge the fix in. You will have the merge for the fix in your integration branch anyway. It is preferable not to contaminate an independent topic branch whose purpose is to cook its own theme with an unrelated bugfix, even if it is brought in as a merge.