Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
> ... but I don't see why something small like that
> wouldn't make sense:
>
> The pull was not fast-forward, please either merge or rebase.
OK, I think I got what John was getting at and this single liner
message is a good summary of it.
Instead of telling them "you cannot push this thing without losing
history from the location you are pushing to; you need to become up
to date with respect to them before pushing" upon seeing a non ff
push failure, we can tell them "you cannot update your history to
what the place you get new changes from has without losing your
history; you need to integrate the two".
Initially I said limiting "git pull" to "--ff-only" by default did
not make sense, but when we view it that way, I now see how such a
default makes sense.
In another subthread, John Szakmeister mentioned that the "please
'git pull' first" message that a "push" gives when it stops due to
non-ff nudges the users in a wrong direction, because they often
take that 'git pull' too literally (e.g. 'pull --rebase' may be
necessary in their project, not 'git pull<ENTER>').
The original message deliberately avoided mentioning 'git pull' for
that exact reason, but in mid 2010 we made it worse. The log of
that change says that it attempted to
... remains fuzzy to include "git pull", "git pull --rebase" and
others, but directs the user to the simplest solution in the
vast majority of cases.
but this thread shows that it did not work; the simplest solution
was a wrong one. The message also may need to be rethought to
complement this direction being proposed for "pull".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html