On Tue, Jun 11, 2013 at 12:05 PM, Josh Elser <josh.el...@gmail.com> wrote: > The person who implements the workaround in Version1 should ensure that when > Version1 is merged into Version2, the correct code is present in Version2.
I'm not sure that's a sufficient solution, because this means that the branch for Version2 may stick around with effectively no change from its last tag other than history, and you can't simply update the tag to update the history, can you? Either it sticks around for a very long time, or it goes away and eventually somebody else is going to have to resolve that potential merge conflict when fixing the next bug that comes around (which maybe applies to both). > Do you think this merits a section on the document or was this a general > question? I think it merits inclusion in the same way that the other generic scenarios I proposed should be included. > On 6/11/13 11:44 AM, Mike Drob wrote: >> >> How do we handle the following situation: >> >> There are two active development branches - versions 1 and 2. Branch 1 >> uses >> external library version 7, while Branch 2 uses external library version >> 9. It is discovered that version 7 of the external library has a bug, with >> a known workaround. In this case, the workaround should be applied to >> branch 1, but does not need to be applied to branch 2. What is the >> git-friendly way to make these changes, not merge them into the later >> branch, but still have a proper history and allow future fixes against >> branch 1 to merge cleanly? >> >> Mike -- Christopher L Tubbs II http://gravatar.com/ctubbsii