On Tue, 5 Dec 2006, Junio C Hamano wrote: > For new people, we recommend to: > > * make sure you were on a right branch (I think you are. You > are on your 'master' branch and may not even have any other > branches, which is fine.) > > * make sure all your changes are committed. > > before initiating a "git pull". And after a conflicted "git > pull", if you choose to punt, > > $ git reset --hard > > would take you back to the state before you started the pull. If there are uncommitted changes, and there are conflicts, shouldn't it leave you in the state before the pull, especially if the uncommitted changes conflict with the merge? Git has determined that it can't present all of the conflicts to the user, so the user can't possibly resolve all of the conflicts, except by discarding new work or pushing it into the merge inappropriately. I think that a lot of new users will pull with uncommitted changes, and they'd benefit from just being told that you're supposed to commit first and then merge. It should definitely roll back perfectly to the state before the pull if it wasn't able to present all the conflicts, since even somebody who knows what's going on is going to have to roll back here. Possibly there should even be an option (defaulting to true) which completely blocks "pull" with uncommitted changes. Even if the in-index merge works (and the working directory is entirely unneeded), it's pretty likely that the user would do better to be in the habit of doing it in the other order anyway. -Daniel *This .sig left intentionally blank* - 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