Re: first parent, commit graph layout, and pull merge direction

Felipe Contreras <felipe.contreras@gmail.com> writes:

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".