Re: GIT pull

From: Michael Witten <mfwitten@gmail.com>
Date: Apr 12, 2012, 15:07 UTC
Message-ID: <CAMOZ1Bs+vvoNJ5jiKEkc-VBBR0Bj_ik9bu6TfKd-0r70Ss0mPg@mail.gmail.com>
In-Reply-To: <vpqiph5m1pd.fsf@bauges.imag.fr>

On Thu, Apr 12, 2012 at 15:03, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

Show 16 quoted lines

> cvalusek <clintv2@gmail.com> 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).

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