From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28369 invoked by alias); 8 Feb 2013 02:43:20 -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: 31035 Received: (qmail 29292 invoked from network); 8 Feb 2013 02:43:07 -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=-3.3 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL, DKIM_SIGNED,RCVD_IN_DNSWL_MED,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at spodhuis.org does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201210; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=kyNBrojS5ILO9WYvzWhKsRLxNa3t6lfbYtkcmzGHYLA=; b=XW0XbeMfMVgHNgwiCmIrm1ix+E8uVSxkOitwUf17kyt1mBZ0jWznLQho8h7TrtkWDNxvf+kzZHIYX+ZCS5I9ftuoEujIA99kfjH0QB0NhqhjuuNjnirDW9OMnmIq32lydCQEBoeuFgFj4P/lv95RasGmMD+iE+0NMCd494Z+3UA=; Date: Thu, 7 Feb 2013 21:25:18 -0500 From: Phil Pennock To: zsh-workers@zsh.org Subject: Re: [PATCH 3/3] zsh-development-guide: add a missing 'to' Message-ID: <20130208022518.GA7036@redoubt.spodhuis.org> Mail-Followup-To: zsh-workers@zsh.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5FB5B5E9-F8EF-450E-802C-84CDCA6D81F0@macports.org> On 2013-02-07 at 22:34 +0100, Mikael Magnusson wrote: > This isn't true afaik... Did whoever wrote it mean git merge --squash? CVS revision 1.26 by opk, and no, he didn't, and he's right in what he wrote. > > bisect). Both "git cherry-pick" and "git merge --ff-only" can be used > > - bring changes over to another branch without a merge commit. > > + to bring changes over to another branch without a merge commit. If you cherry-pick and don't pull them over in order, to a branch at the same point in history as the point of the branch, then new commits will be created, but there won't be a merge commit. So: * This approach avoids merge commits, with bifurcated history; myself, I'd avoid _trivial_ merge commits, but not otherwise. Oliver's documented an approach which is easier for those new to Git to deal with, when trying to find what has gone wrong. That's fair enough. * merge with --ff-only: will just move around definitions about what the tip of the current branch refers to, but won't have to create new tree or blob objects. If you've gotten your feature branch "just right" to express what you want, have rebased to handle changes to the mainline already, then this "--ff-only" is just a safety-net to protect against a concurrent change. * git cherry-pick: in most cases, will create new commits and lose the original history, but avoids merge commits and keeps a linear history and keep the separation of changes as being in multiple independent changes * merge with --squash: takes all the changes from the branch and turns them into one big change, applied without indicating a branch as history. There's no correct simple answer about which to use, which makes this intimidating to those new to git. If you're not using feature branches, none of these matter, at all; just use the simple steps under "Micro Git Tutorial" which makes it *very* simple and easy. If you are using feature branches for development, then instead of being stuck using one model chosen by some older VCS systems, you get to choose how the code integrates back from the feature development branch and what you want to be visible, and the above cover some of the choices for getting a result matching your desires. Really, all the debates are about "what is the one true way to choose to present to the world how you made your change, once it becomes visible in mainline", and there are many answers and many opinions and you're not forced into one approach; this means people end up arguing over stuff that really doesn't matter, and they intimidate folks who just want to get on and make simple changes and don't _want_ to have to learn the internal architecture of a VCS before they make their first changes on an existing project. Sure, the affected people here are smart and will learn the internal architecture as time goes by and they find approaches they're comfortable with, but they shouldn't be pressured into doing so until they're comfortable with the basics and want to explore to get comfortable. On 2013-02-07 at 17:47 -0500, Lawrence Velázquez wrote: > It's certainly true as written, but perhaps "git merge --squash" can > be added as a third suggestion. It's in the very next paragraph. -Phil