* developing a modified Linux-style workflow
@ 2010-12-12 22:24 Hans-Christoph Steiner
2010-12-13 3:31 ` David Aguilar
2010-12-13 16:15 ` Neal Kreitzinger
0 siblings, 2 replies; 7+ messages in thread
From: Hans-Christoph Steiner @ 2010-12-12 22:24 UTC (permalink / raw)
To: git
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 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: developing a modified Linux-style workflow
2010-12-13 3:31 ` David Aguilar
@ 2010-12-13 3:23 ` Hans-Christoph Steiner
0 siblings, 0 replies; 7+ messages in thread
From: Hans-Christoph Steiner @ 2010-12-13 3:23 UTC (permalink / raw)
To: David Aguilar; +Cc: git
On Dec 12, 2010, at 10:31 PM, David Aguilar wrote:
> On Sun, Dec 12, 2010 at 05:24:16PM -0500, Hans-Christoph Steiner
> wrote:
>>
>> 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.
>
> Have you considered periodically merging Pd into Pd-extended
> as an alternative to rebasing? It might even be easier to
> manage in the long-term.
The thing I really like about the lieutenant workflow is that I can
keep my patches at the top of history, and it automatically handles it
once my patch is handled upstream. It seems that merging Pd into Pd-
extended would leave me with a very complicated history.
.hc
----------------------------------------------------------------------------
'You people have such restrictive dress for women,’ she said, hobbling
away in three inch heels and panty hose to finish out another pink-
collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: developing a modified Linux-style workflow
2010-12-12 22:24 developing a modified Linux-style workflow Hans-Christoph Steiner
@ 2010-12-13 3:31 ` David Aguilar
2010-12-13 3:23 ` Hans-Christoph Steiner
2010-12-13 16:15 ` Neal Kreitzinger
1 sibling, 1 reply; 7+ messages in thread
From: David Aguilar @ 2010-12-13 3:31 UTC (permalink / raw)
To: Hans-Christoph Steiner; +Cc: git
On Sun, Dec 12, 2010 at 05:24:16PM -0500, Hans-Christoph Steiner wrote:
>
> 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.
Have you considered periodically merging Pd into Pd-extended
as an alternative to rebasing? It might even be easier to
manage in the long-term.
--
David
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: developing a modified Linux-style workflow
2010-12-12 22:24 developing a modified Linux-style workflow Hans-Christoph Steiner
2010-12-13 3:31 ` David Aguilar
@ 2010-12-13 16:15 ` Neal Kreitzinger
1 sibling, 0 replies; 7+ messages in thread
From: Neal Kreitzinger @ 2010-12-13 16:15 UTC (permalink / raw)
To: git
"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.
v/r,
Neal
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: developing a modified Linux-style workflow
[not found] <E54235A96EB484418EBD9509F37176D210049C61@htmail10.hightouchinc.com>
@ 2011-01-04 19:01 ` Hans-Christoph Steiner
2011-01-04 21:19 ` Neal Kreitzinger
0 siblings, 1 reply; 7+ messages in thread
From: Hans-Christoph Steiner @ 2011-01-04 19:01 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
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?
.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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: developing a modified Linux-style workflow
2011-01-04 19:01 ` Hans-Christoph Steiner
@ 2011-01-04 21:19 ` Neal Kreitzinger
2011-01-05 0:47 ` Neal Kreitzinger
0 siblings, 1 reply; 7+ messages in thread
From: Neal Kreitzinger @ 2011-01-04 21:19 UTC (permalink / raw)
To: git; +Cc: Neal Kreitzinger, git
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 checkout X13-Merge-X12
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...
v/r,
Neal
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: developing a modified Linux-style workflow
2011-01-04 21:19 ` Neal Kreitzinger
@ 2011-01-05 0:47 ` Neal Kreitzinger
0 siblings, 0 replies; 7+ messages in thread
From: Neal Kreitzinger @ 2011-01-05 0:47 UTC (permalink / raw)
Cc: git, Neal Kreitzinger
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@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...
see note on corrected typo above!
v/r,
Neal
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-01-05 0:48 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-12-12 22:24 developing a modified Linux-style workflow Hans-Christoph Steiner
2010-12-13 3:31 ` David Aguilar
2010-12-13 3:23 ` Hans-Christoph Steiner
2010-12-13 16:15 ` Neal Kreitzinger
[not found] <E54235A96EB484418EBD9509F37176D210049C61@htmail10.hightouchinc.com>
2011-01-04 19:01 ` Hans-Christoph Steiner
2011-01-04 21:19 ` Neal Kreitzinger
2011-01-05 0:47 ` Neal Kreitzinger
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).