Re: developing a modified Linux-style workflow

From: Hans-Christoph Steiner <hans@at.or.at>
Date: Jan 4, 2011, 19:01 UTC
Message-ID: <344D6422-8F2B-4545-A680-06F434C17F5B@at.or.at>
In-Reply-To: <E54235A96EB484418EBD9509F37176D210049C61@htmail10.hightouchinc.com>

On Dec 13, 2010, at 11:16 AM, Neal Kreitzinger wrote:

Show 61 quoted lines

> "Hans-Christoph Steiner" <hans@at.or.at> wrote in message
> news:7EAE16CF-A9A8-47A6-9294-3646CCDB0E9C@at.or.at...
>>
>> 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.

For me the biggest feature that I am looking for is the automatic merging of commits, and second, having a branch that puts my collection of patches/commits ahead of the Pd master so that its easy to manage the patches. I don't think I see how I could do that with this multiple branches idea. Is that possible?

.hc

----------------------------------------------------------------------------

I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.