author | Shawn O. Pearce <spearce@spearce.org> | |
Wed, 8 Nov 2006 03:00:38 +0000 (22:00 -0500) | ||
committer | Shawn O. Pearce <spearce@spearce.org> | |
Wed, 8 Nov 2006 04:48:22 +0000 (23:48 -0500) | ||
commit | ec39d83a55124660d03a744e0e7f67072a833950 | |
tree | 19768b047fde5ee3bdfb8fd909b4c375e53b89ca | tree | snapshot |
parent | 0a462d67761b8178f09e23ef85a9298d1e19a2eb | commit | diff |
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>
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 | diff | blob | history |