From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neal Kreitzinger Subject: Re: developing a modified Linux-style workflow Date: Tue, 04 Jan 2011 15:19:24 -0600 Message-ID: <4D238EDC.9000503@gmail.com> References: <344D6422-8F2B-4545-A680-06F434C17F5B@at.or.at> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Neal Kreitzinger , git@vger.kernel.org To: git@vger.kernel.org X-From: git-owner@vger.kernel.org Tue Jan 04 22:20:16 2011 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PaEIh-0000bA-GI for gcvg-git-2@lo.gmane.org; Tue, 04 Jan 2011 22:20:16 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751474Ab1ADVUF (ORCPT ); Tue, 4 Jan 2011 16:20:05 -0500 Received: from lo.gmane.org ([80.91.229.12]:41625 "EHLO lo.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750994Ab1ADVUE (ORCPT ); Tue, 4 Jan 2011 16:20:04 -0500 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PaEIV-0000S6-4D for git@vger.kernel.org; Tue, 04 Jan 2011 22:20:03 +0100 Received: from 67.63.162.200 ([67.63.162.200]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 Jan 2011 22:20:03 +0100 Received: from nkreitzinger by 67.63.162.200 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 Jan 2011 22:20:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 67.63.162.200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 In-Reply-To: <344D6422-8F2B-4545-A680-06F434C17F5B@at.or.at> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: 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" 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