Re: developing a modified Linux-style workflow

Previous thread: debugging git clone via git-daemon "cannot handle daemon internally" by John Griessen on Tuesday, January 4, 2011 - 9:50 am. (1 message)

Next thread: [PATCH v2] t/t9001-send-email.sh: fix '&&' chain in some tests by Antonio Ospite on Tuesday, January 4, 2011 - 1:56 pm. (1 message)
From: Hans-Christoph Steiner
Date: Tuesday, January 4, 2011 - 12:01 pm

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.


--

From: Neal Kreitzinger
Date: Tuesday, January 4, 2011 - 2:19 pm

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 ...
Previous thread: debugging git clone via git-daemon "cannot handle daemon internally" by John Griessen on Tuesday, January 4, 2011 - 9:50 am. (1 message)

Next thread: [PATCH v2] t/t9001-send-email.sh: fix '&&' chain in some tests by Antonio Ospite on Tuesday, January 4, 2011 - 1:56 pm. (1 message)