Re: developing a modified Linux-style workflow

> 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@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?
>>
>
> 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...