git-gui: Don't let the user pull into an uncommitted working directory.
authorShawn O. Pearce <spearce@spearce.org>
Wed, 8 Nov 2006 03:00:38 +0000 (22:00 -0500)
committerShawn O. Pearce <spearce@spearce.org>
Wed, 8 Nov 2006 04:48:22 +0000 (23:48 -0500)
commitec39d83a55124660d03a744e0e7f67072a833950
tree19768b047fde5ee3bdfb8fd909b4c375e53b89ca
parent0a462d67761b8178f09e23ef85a9298d1e19a2eb
git-gui: Don't let the user pull into an uncommitted working directory.

If there are modified files present in the working directory then we
should not let the user perform a pull as it may fail due to the modified
files being uncommitted but needing to be merged at the file level.

Yes there are many cases where a merge will complete successfully even
though there are modified or untracked files sitting in the working
directory.  But users generally shouldn't be attempting merges like that,
and if they are they probably are advanced enough to just use the command
line and bypass this little safety check.

We also no longer run a rescan after a successful pull has completed.
Usually this is unnecessary as a successful pull won't leave modified
files laying around.  Instead we just update our HEAD and PARENT values
with the new commit, if there is one.

Unfortunately this does let the user get into an insane state as there
are bugs in core Git's git-pull and git-merge programs where the exit
status is sent back as a 0 rather than non-0 when a failure is detected.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui