From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8819 invoked by alias); 14 Dec 2012 09:23:55 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 30885 Received: (qmail 29544 invoked from network); 14 Dec 2012 09:23:43 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_PASS autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at bewatermyfriend.org does not designate permitted sender hosts) From: Frank Terbeck To: zsh-workers@zsh.org Subject: Re: Access to CVS In-Reply-To: <20121213191327.GA22923@redoubt.spodhuis.org> (Phil Pennock's message of "Thu, 13 Dec 2012 14:13:27 -0500") References: <20121205195013.64ef36c0@pws-pc.ntlworld.com> <20121207000521.GD20703@pug.qqx.org> <20121207094935.0d9bce83@pwslap01u.europe.root.pri> <4810.1355267148@thecus.kiddle.eu> <87a9tjwuec.fsf@ft.bewatermyfriend.org> <8272.1355333127@thecus.kiddle.eu> <121212105719.ZM28299@torch.brasslantern.com> <12941.1355403532@thecus.kiddle.eu> <20121213161311.27ca1cfc@pwslap01u.europe.root.pri> <121213082008.ZM29521@torch.brasslantern.com> <20121213191327.GA22923@redoubt.spodhuis.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Date: Fri, 14 Dec 2012 10:22:41 +0100 Message-ID: <87ehitugwu.fsf@ft.bewatermyfriend.org> MIME-Version: 1.0 Content-Type: text/plain X-Df-Sender: [pbs]NDMwNDQ0 Phil Pennock wrote: [...] > IF you want to make the code available on the server you cloned from as > a branch, and accept that this involves a non-linear history (eg, a > major feature change where it's worth keeping a more accurate history) > then: And if you just want do have a local branch, to do your work in and still want to enforce linear history, you can use the same workflow as Phil described. You just need to "replay" your changes on top of "master". "git rebase" does that. > % git push origin feature_foo > [ do mailing-list stuff here ] > > Switch back to master: > % git checkout master > and get the most recent changes: > % git pull Switch back to the feature branch: % git checkout feature_foo Rebase the feature branch on top of new changes that were just pulled: % git rebase master This does the following (ASCII graphs from git's manual): Commit situation before the rebase: A---B---C topic / ... D---E---F---G master And after: A'--B'--C' topic / ... D---E---F---G master This essentially replays the commits from the topic (or feature) branch on top of master. That creates commits with different SHA1 sums, hence the apostrophes with the rebased branch. > then bring in your changes: > % git merge feature_foo That merge is a fast-forward then, because it just involves putting the pointer of the master branch to the tip of the topic branch; because its linear history again - no real merges involved at all. > % git commit > % git push [...] > git help tutorial > git help tutorial-2 > git help gitcore-tutorial Those are actually pretty helpful indeed. Regards, Frank -- In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away. -- RFC 1925