Re: VC mode and git

[Alan Mackenzie <acm@muc.de>]

Hello, Stephen.

On Tue, Mar 31, 2015 at 06:24:46PM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > That is the case in the current git version.  I think that in previous
>  > versions, git took the liberty of simply overwriting changed files in
>  > the workspace.

> git has never done that, and never will (if it does, there will
> immediately be a fork that doesn't and all sane users will switch).

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.

> git reset --hard will do that, and there may be a --force option to
> checkout that will do that.  But you have to explicitly request git to
> overwrite files that are not in the state that git last committed
> them, and as far as I know merge never does that.  (There may be
> circumstances where it will do a 3-way merge on an uncommitted file,
> but normally it will balk, and always has done so AFAICR.)

> Note that all VCSes have the equivalent of git reset --hard.

>  > Why can't git simply merge changes properly into the workspace, thus
>  > saving users the unwelcome hassle of, e.g., git stash followed by git
>  > merge followed by git stash pop?

> It does, the same way that bzr or Mercurial does.[1]  I don't see why you
> would think otherwise.

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.

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.

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".  By contrast, hg merge is documented concisely and
adequately as "merge another revision into working directory".


> Footnotes: 
> [1]  There are slight differences in algorithms, but they mostly don't
> make a difference -- you'll get the same result.

-- 
Alan Mackenzie (Nuremberg, Germany).