Re: VC mode and git

[Steinar Bang <sb@dod.no>]

>>>>> Alan Mackenzie <acm@muc.de>:

> I lost some changes in my working directory after doing something like
> git pull.  I can't remember the details any more.  I was able to
> reconstruct the changes without too much difficulty.

I've have *never* had git overwrite my changes except using "git reset
--hard" or any of the "--force" arguments.

> Partly due to the following bug report which is near the start of the
> git-merge man page:  "Warning: Running git merge with non-trivial
> uncommitted changes is discouraged: while possible, it may leave you in a
> state that is hard to back out of in the case of a conflict.".  I can't
> imagine why the git maintainers don't fix this.

Their fix is to ask you to commit (or stash) before you pull (which is
fetch followed by merge).

If the commits stops because if something, you will have a workspace
with some staged files, some unstaged files holding conflicted files,
and some unstaged files holding your uncommitted changes (potentially
there could be staged files unrelated to the merge as well, but anyone
knowing how to stage files have probably committed before the pull...).

In short: it can be difficult to know what changes belongs to the merge
and what were local uncommitted changes prior to the merge.  One
heuristic could be that the unconflicted uncommitted changes don't
belong to the merge, but it if was that simple I suspect that this would
already be the case.

> With git pull, if there are changes in the working directory, the merge
> (i.e. merge from remote/master into master) part of the operation is
> aborted before it starts, giving a message describing its refusal.  It
> does this even when there are no conflicts to deal with.

> Mercurial will complete hg pull regardless of any changes in its working
> directory; in the case of conflicts it may leave several heads which
> require merging.

FWIW git completes the fetch before doing the merge, so all the upstream
changes are present and can be manually merged.

> Part of the problem is that the git-merge man page doesn't say that it
> messes with the working tree (or, more precisely, it vaguely alludes to
> it in the small print several hundred pages down).  In fact, it doesn't
> say up front _what_ it is merging, or where the merged result goes - it
> merely says "Join two or more development histories together", leaving it
> as an exercise for the reader to figure out exactly what is meant by a
> "development history".

This chapter of "Pro Git", is quite good:
 http://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell