Re: More Beginning Git Questions
- From
Matthieu Moy <matthieu.moy@grenoble-inp.fr>
- Date
- Sep 23, 2011, 16:11 UTC
- Message-ID
- <vpq62kjw854.fsf@bauges.imag.fr>
- In-Reply-To
- <4E7C9AAD.7060209@gmail.com>
Jon Forrest <nobozo@gmail.com> writes:
> "If Bob’s work conflicts with what Alice did since their histories forked," > > Does this include both changes that Alice has checked in to > her repository and uncommitted changes in her working tree?
Git will not allow you to do a "git pull" if your uncommited changes touch the same files as the pull. So, you basically can't have conflicts about uncommited changes with "git pull".
That's by design: solving conflicts can be hard, and you want the "last commit" safety net while doing it. If you mess up your conflict resolution, you can still "git reset --merge" and try again.
Show 5 quoted lines
> "Alice will use her working tree and the index to resolve conflicts," > > How does Alice use her working tree and index? Does this mean > she makes changes to her working tree so that the conflicts > no longer exist?
Yes.
> How does the index play a part in this?
Once the conflict is fixed in the working tree, you run "git add" to mark the conflict as resolved.
And before this, the index contains half-merged versions of your file, and "git diff" can show you the difference between them and your worktree. See the user manual :
http://schacon.github.com/git/user-manual.html#resolving-a-merge
(BTW, that's not the official place for Git documentation, but since kernel.org is down now ...)
> "and existing local changes will interfere with the conflict > resolution process"
Probably this should have been "would have interfered" (and therefore are forbidden by Git, as the following sentence says):
> "(git will still perform the fetch but will refuse to merge > --- Alice will have to get rid of her local changes in > some way and pull again when this happens)."
-- Matthieu Moy http://www-verimag.imag.fr/~moy/