Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> [git] Documentation and Plan of Action

Copy link to this message
Re: [git] Documentation and Plan of Action
On Tue, Jun 11, 2013 at 12:05 PM, Josh Elser <[EMAIL PROTECTED]> 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