Re: developing a modified Linux-style workflow

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Hans-Christoph Steiner" <hans@xxxxxxxx> wrote in message 
news:7EAE16CF-A9A8-47A6-9294-3646CCDB0E9C@xxxxxxxxxxx
>
> Hey all,
>
> (and my second post on this list...)
>
> I've gotten pretty good at git, and its helping me already with  managing 
> the very odd workflows I have with the software I work a lot  on called Pd 
> (http://puredata.info).  My role in Pd development is  like a Linux 
> lieutenant.
>
> I also the main dev for an app called Pd-extended, which is based on  Pd. 
> Now I'm stuck trying to figure out how to use git to match my  current 
> workflow for Pd-extended, which is a kind of long-lived  branch, almost 
> like a friendly fork.  So its kind of close to the  Linux workflow with me 
> as a lieutenant, but not quite.
>
> What makes it tricky is that I make releases directly from my repo  that 
> are widely used.  So my repo is both lieutenant and dictator at  the same 
> time.  So that's where I am stumped.  I want to be able to  rebase and 
> push to a public repo, but that would be stupid.  So there  has got to be 
> another way.
>
> .hc
>
I don't think pushing to a public repo is stupid.  You could create a bare 
repo with a Pd branch and Pd-extended branch that contain the production 
versions of Pd and Pd-extended.  The main reason our shop chose git is 
because it allows us to easily have multiple concurrent versions of 
production by having a branch for each of our custom versions.  These 
versions eventually get merged together into a major release, but in the 
meantime they are longlived branches representing the productional 
customized system for each major customer.

*If* you end up merging Pd and Pd-extended at some point, then you could 
have another branch for that, e.g. master or Pd-master or whatever.  BTW, 
you do not have to use master as the representative of your final merged 
work so don't think that is the way you HAVE to do it.  It's just the 
default, and a common practice for systems with a single version of 
production.  Master can become vestigial or secondary, if you choose to 
create a new branch called Pd-master, etc. to represent your eventual merges 
of Pd and Pd-extended.


v/r,
Neal 



--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]