On Fri, Jun 28, 2013 at 01:52:38PM +0200, Matthieu Moy wrote:
> "W. Trevor King" <wking@tremily.us> writes:
> > I want the warning that they had not made the required config choice
> > between rebase/merge needed to handle a non-ff case, not the default
> > merge (or rebase) behavior.  The warning gives them a chance to
> > realize that this was not an appropriate time for a `svn update`
> > analog, and that the project may not to want to have the branches
> > joined at all ;).
> 
> You're assuming that the config is not made, but this is supposed to
> happen once initially. Then, the user will chose either merge or rebase,
> and whatever is chosen, the result will be bad.

I'm hoping that reading the error message reminds them that these
cross-branch pulls are not recommended (for us), and that they skip
the configuration step (so they'll get the same warning after their
next subconcious pull).  Of course, there are no guarantees.  But if
they do configure their rebase/merge preference and make and push bad
merge, at least I'll have something I can suggest as a finger-breaker.

Of course, they should already be seeing their editor with a merge
commit message that they are ok-ing.  If that's not enough to make
them think twice, a warning that:

  The pull does not fast-forward; …

may fall on deaf ears (blind eyes?).  However, for folks used to only
having a single branch, this may be enough of a jolt to wake them up.

I'm not making a very strong case, and this whole line of reasoning is
getting off topic for this PR.  Unless we adapt it to:

  pull.non-ff = {merge,rebase,never}

which is, I think, even less likely to land ;).

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy