On Tue, Nov 18 2008, Nicolas Duboc wrote:

>> On Mon, Nov 17, 2008 at 03:56:06PM -0800, Russ Allbery wrote:
>>> Manoj Srivastava <[EMAIL PROTECTED]> writes:

>> >         Well, I have seen this happen.
>> >  a) update the upstream branch (merge from remote/upstream, or
>> >     git_load_dirs).
>> >  b) Merge upstream branch into topic branches; resolve conflicts.
>> >  c) Merge topic branches into the integration branch (master, for
>> >     me). rerere applies any conflict resolution changes. Do any other
>> >     integration changes, and commit.

>> Rather than using rerere, I create a temporary merge branch based off
>> upstream and merge each topic branch into it in sequence, and then merge
>> the temporary merge branch into the integration branch, which seems to
>> accomplish the same thing (not having to re-handle the merge conflicts
>> when merging the first topic branch).

        The problem I see with temoprary merge branches is that it would
 seem that any conflicts between topic branches would have to be
 resolved every single time we have a new upstream; I would find that an
 unacceptable burden.

>   Yes, it seems to be the simplest and safest way to do (I don't feel
> confortable using rerere), as I would like to automate that step.
>   And, if you don't need a long-living build branch, this integration
> branch can actually be the 'build' branch. I think one such integration
> branch per upstream version would be required and sufficient.

        I have a permanent (master) branch that is the integration
 branch, and encapsulates all the integration changes required. This
 allows me not to have to redo all integration work every time there is
 a new upstream version;and this is the only thing that keeps the whole
 process sane for me.

Happiness is the greatest good.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

vcs-pkg-discuss mailing list

Reply via email to