Re: [PATCH 3/3] zsh-development-guide: add a missing 'to'

[Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx>]

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