On Tue, 5 Dec 2006, Junio C Hamano wrote:

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html