David Brown schrieb:
On Tue, Jun 03, 2008 at 08:08:09PM +0200, Pieter de Bie wrote:
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.
For my understanding: does your 'other' branch contain only a 3rd party
library that you (or the 3rd party people) did patch for your purpose
and you're not allowed to distribute that patched 3rd party lib? What
about using a git submodule for the 3rd party thing. The submodule
contains the patched library (for your development) and the customer
is then told to supply the genuine library (from the internet) and then
apply your patches to it. Would that help you? Probably I missed
some legal issues here...
-- Dirk
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
