Re: Maintaining two branches.

From: David Brown <git@davidb.org>
Date: Jun 3, 2008, 18:17 UTC
Message-ID: <20080603181731.GB11735@old.davidb.org>
In-Reply-To: <08056802-BBBC-4F1D-A1A6-2F8C381CDA2B@ai.rug.nl>

On Tue, Jun 03, 2008 at 08:08:09PM +0200, Pieter de Bie wrote:

Show 10 quoted lines

> You might do the same workflow that Git has with stable / master / next
>
> If there is a new upstream release, merge it into external. If you have 
> patches you want to show to the outside, apply those patches to external. 
> Then you can merge external into local. The trick is to never merge local 
> into external.
>
> By going only one way (upstream --> external --> local), you'll never have 
> to worry about having to separate the different patches. Your history will 
> be displayed much nicer too.

I guess I didn't explain our dilema very well. We _have_ to separate the different patches, for legal reasons. Perhaps 'external' isn't a good name for the branch, maybe it should be 'other'. Basically, the 'upstream' branch is the real upstream tree. The 'external' or 'other' branch contains patches from outside our company. We are forbidden from redistributing these changes, and will be having our customers get them from the same source that we do. Then our 'local' branch is where we do our development.

But, we can only build the system when the 'external/other' branch is combined with 'local'. It's just that the history has to be easily separable so that we can generate the patches that are on the 'local' branch along with the descriptions of the external branch so the customers can get the same changes.

Thanks, David