David Aguilar wrote:
> On Sun, Apr 20, 2014 at 05:41:05PM -0500, Felipe Contreras wrote:
> > = Reject non-fast-forward pulls by default =
> > Many new-comers end up making merges by mistake when they pull because
> > they don't understand what is a non-fast-forward and what they should
> > actually be doing. Most people, even Linus Torvalds, agreed that by
> > default `git pull` should fail and guide the user, instead of silently
> > making a merge which might not be what the user wants (even though he
> > doesn't know it), and messing up the project's history, which affects
> > other people.
> > The patches were sent, the issues were addressed, people agreed, and
> > yet nothing happened.
> We can currently set pull.ff = only to get this behavior.
It is not the same behavior as my patch series, you get:
fatal: Not possible to fast-forward, aborting.
With that message we certainly cannot make it the default. In my patch series
The pull was not fast-forward, please either merge or rebase.
If unsure, run 'git pull --merge'.
> I would like it if this were the default (but I am biased).
I don't know if you followed the discussion, but virtually everyone (including
Linus) agreed this should be the default.
> > = Use "stage" instead of "index" =
> I'm probably biased about this one too, but I should probably speak up.
> git-cola has used "Staged", "Modified", "Untracked", etc. since
> the beginning of time. Sorry 'bout that, but it seemed like the
> simplest word to use.
> I often hear users talking about "staging" files.
> I'm probably in an echo chamber, but I never really had to
> explain "the staging area" since the concept is pretty natural
> when interacting with the GUI.
Again, virtually everyone (except Junio) agrees.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html