cvalusek [off-list ref] writes:
If a user has local modifications not on the index and does a pull, I have
seen git attempt to start applying the merge to master and abort. The whole
checkout is then left in a terrible state that is nearly
unrecoverable.
What do you mean by "terrible state"? What does "git status" say?
In the past, I thought GIT would run some sort of check to identify
these problems before it attempts the merge.
Git does check uncommited changes before merging. It allows the merge if
the changes touch different files (i.e. if the merge is guaranteed not
to touch the same files as the one for which you have uncommited
changes).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
On Thu, Apr 12, 2012 at 15:03, Matthieu Moy
[off-list ref] wrote:
cvalusek [off-list ref] writes:
quoted
If a user has local modifications not on the index and does a pull, I have
seen git attempt to start applying the merge to master and abort. The whole
checkout is then left in a terrible state that is nearly
unrecoverable.
What do you mean by "terrible state"? What does "git status" say?
quoted
In the past, I thought GIT would run some sort of check to identify
these problems before it attempts the merge.
Git does check uncommited changes before merging. It allows the merge if
the changes touch different files (i.e. if the merge is guaranteed not
to touch the same files as the one for which you have uncommited
changes).
Also, if there *are* conflicts, then you should get an error that
looks like the following:
error: Your local changes to the following files would be
overwritten by merge:
some-file.txt
Please, commit your changes or stash them before you can merge.
Aborting
Sincerely,
Michael Witten