On 1/4/2011 3:19 PM, Neal Kreitzinger wrote:
On 1/4/2011 1:01 PM, Hans-Christoph Steiner wrote:
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?
I have _no_ experience using patches (in git or otherwise) to manage
change control, ie. git-am, git-format-patch, etc., as of yet...
That being said, FWIW, here is a suggestion based on the following
assumptions:
a. It sounds like Pd and Pd-extended only get merged once-in-a-while
(infrequently).
b. Pd is the main version in use, and Pd-extended is a future version or
a not-yet-widely-used version.
c. Pd-extended is based on Pd, but since the inception of Pd-extended
both Pd and Pd-extended have advanced (diverged).
Assuming that is the case, this is similar to what our shop does. We
have a production system X12 and a new system X13 that is based on X12.
Periodically, bugfixes and enhancements from X12 need to be merged into
X13. Here's how we do it:
1. Identify the range of commits in X12 that are not yet in X13 (new X12
commits since the last X12-X13 merge):
$ git log
sha1-of-last-X12-commit-alreadyMERGED-into-X13..sha1-of-newest-X12-commit-you-want-MERGED-into-X13
--format="%h%d %s"
>/somepath/whereIkeepstuff/X12-X13-MRG.01-REBASE-TO-DO.lst
2. Identify any commits in the X12 commits that you do not want merged
into X13.
3. Create a throw-away-integration-branch which is a copy of X12:
$ git checkout X12
$ git branch X12-Squash
4. Create a throw-away-integration-branch which is a copy of X13:
$ git checkout X13
$ git branch X13-Merge-X12 <-------corrected typo here
5. Squash the X12 merge series into a single commit:
$ git checkout X12-Squash
$ git reset --hard sha1-of-newest-X12-commit-you-want-MERGED-into-X13
(in case its not the head commit of the branch)
$ git rebase -i sha1-of-last-X12-commit-alreadyMERGED-into-X13
(interactive rebase to squash the X12 "new commits" series)
#comment out any commits that you don't want in X13, if applicable.
put an "s" next to all the other commits to squash them.
6. Cherry pick the X12 squashed commit onto X13:
$ git checkout X13-Merge-X12
$ git cherry-pick --edit X12-Squash
resolve any conflicts
review what got merged automatically and make sure its right (git
doesn't know about conflicts in logic)
7. Merge results into real X13:
$ git checkout X13
$ git merge --ff-only X13-Merge-X12
8. Create a test copy of the bare repo of X13:
$ cp -rvp X13.git QA-X13.git
9. Push to QA copy of X13 repo: (make sure your push results are ok)
$ git push QA-X13-remotename HEAD
review in gitk, etc. to verify it is correct
10. Push to real X13 repo:
$ git push X13-remotename HEAD
review results
notify others of update.
Note: you can have X12 and X13 in separate bare repos if you want, or as
branches in a single bare repo. If X12 and X13 are in separate bare
repos, then you can use an 'integration manager' repo to remote to them
and pull their changes into integration branches. That's actually how
our shop currently does it because the X13 people do not maintain X12.
The steps above are for a single bare repo in order to save on the
number of steps in the example.
Hope this helps. If my assumptions are incorrect then we might have
other merge techniques that may be applicable...
see note on corrected typo above!
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