On Dec 13, 2010, at 11:16 AM, Neal Kreitzinger wrote:
"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.
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.
--
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