* [PATCH 3/3] zsh-development-guide: add a missing 'to'
@ 2013-02-05 17:44 Wieland Hoffmann
2013-02-07 21:34 ` Mikael Magnusson
0 siblings, 1 reply; 5+ messages in thread
From: Wieland Hoffmann @ 2013-02-05 17:44 UTC (permalink / raw)
To: zsh-workers
---
Etc/zsh-development-guide | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Etc/zsh-development-guide b/Etc/zsh-development-guide
index e7d7385..e4ac1ba 100644
--- a/Etc/zsh-development-guide
+++ b/Etc/zsh-development-guide
@@ -67,7 +67,7 @@ Git Workflow
* Do not merge your private feature branches onto the master branch: a
linear history without merge commits is simpler to follow (and to
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.
* It is often useful to regularly check in changes while prototyping a
solution on a private branch. When finished, it is better to deliver a
--
1.8.1.2
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 3/3] zsh-development-guide: add a missing 'to'
2013-02-05 17:44 [PATCH 3/3] zsh-development-guide: add a missing 'to' Wieland Hoffmann
@ 2013-02-07 21:34 ` Mikael Magnusson
2013-02-07 22:47 ` Lawrence Velázquez
2013-02-08 2:25 ` Phil Pennock
0 siblings, 2 replies; 5+ messages in thread
From: Mikael Magnusson @ 2013-02-07 21:34 UTC (permalink / raw)
To: Wieland Hoffmann; +Cc: zsh-workers
This isn't true afaik... Did whoever wrote it mean git merge --squash?
On 05/02/2013, Wieland Hoffmann <themineo@gmail.com> wrote:
> ---
> Etc/zsh-development-guide | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Etc/zsh-development-guide b/Etc/zsh-development-guide
> index e7d7385..e4ac1ba 100644
> --- a/Etc/zsh-development-guide
> +++ b/Etc/zsh-development-guide
> @@ -67,7 +67,7 @@ Git Workflow
> * Do not merge your private feature branches onto the master branch: a
> linear history without merge commits is simpler to follow (and to
> 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.
>
> * It is often useful to regularly check in changes while prototyping a
> solution on a private branch. When finished, it is better to deliver a
> --
> 1.8.1.2
>
>
--
Mikael Magnusson
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 3/3] zsh-development-guide: add a missing 'to'
2013-02-07 21:34 ` Mikael Magnusson
@ 2013-02-07 22:47 ` Lawrence Velázquez
2013-02-08 2:25 ` Phil Pennock
1 sibling, 0 replies; 5+ messages in thread
From: Lawrence Velázquez @ 2013-02-07 22:47 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Wieland Hoffmann, zsh-workers
On Feb 7, 2013, at 4:34 PM, Mikael Magnusson <mikachu@gmail.com> wrote:
> This isn't true afaik... Did whoever wrote it mean git merge --squash?
It's certainly true as written, but perhaps "git merge --squash" can be added as a third suggestion.
vq
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 3/3] zsh-development-guide: add a missing 'to'
2013-02-07 21:34 ` Mikael Magnusson
2013-02-07 22:47 ` Lawrence Velázquez
@ 2013-02-08 2:25 ` Phil Pennock
2013-02-08 3:30 ` Lawrence Velázquez
1 sibling, 1 reply; 5+ messages in thread
From: Phil Pennock @ 2013-02-08 2:25 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 3/3] zsh-development-guide: add a missing 'to'
2013-02-08 2:25 ` Phil Pennock
@ 2013-02-08 3:30 ` Lawrence Velázquez
0 siblings, 0 replies; 5+ messages in thread
From: Lawrence Velázquez @ 2013-02-08 3:30 UTC (permalink / raw)
To: Phil Pennock; +Cc: zsh-workers
On Feb 7, 2013, at 9:25 PM, Phil Pennock <zsh-workers+phil.pennock@spodhuis.org> wrote:
> 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.
Huh. I guess that's what I get for not actually reading it. :P
vq
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-02-08 3:37 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-05 17:44 [PATCH 3/3] zsh-development-guide: add a missing 'to' Wieland Hoffmann
2013-02-07 21:34 ` Mikael Magnusson
2013-02-07 22:47 ` Lawrence Velázquez
2013-02-08 2:25 ` Phil Pennock
2013-02-08 3:30 ` Lawrence Velázquez
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).