Re: VC mode and git

[Alan Mackenzie <acm@muc.de>]

Hello, Steinar.

On Tue, Mar 31, 2015 at 02:42:14PM +0200, Steinar Bang wrote:
> >>>>> 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.

I've never used git reset or a git --force argument.  I did lose some
changes, however.

> > 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).

That's a fix?  So every time I want to do a pull I have to stash, pull,
unstash.  Yuck!  A proper fix would be for merge to actually merge the
new changes into the working directory.

> 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...).

Not me.  In my normal workflow, I commit at the last minute, then push.
Just before committing, I get the latest changes from savannah, do any
necessary merging, then commit and push as quickly as possible.  This is
to minimise the hassle which invariably occurs when other people's
commits get mixed up with my own.  Is it really too much to expect that
git merge should merge these new fetched changes into my working
directory?

> In short: it can be difficult to know what changes belongs to the merge
> and what were local uncommitted changes prior to the merge.

I don't know what you mean by "the" merge.  When one mixes up committing
with staging with fetching with pushing, inevitably there will sometimes
be merge operations required all over the place.

> One heuristic could be that the unconflicted uncommitted changes don't
> belong to the merge, ...

Sorry, this is ceasing to make sense to me.  I can't visualise what
you're trying to say.  When there are uncommitted changes and some merge
takes place at a place where these changes are, the changes can't avoid
being part of that 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.

I think I'm OK with the fetch part.  It's the merge part I have
difficulties with.

> > 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

It may be quite good, but it's information density is very low.  It's
written for beginners in VCS.  Every time I read, yet again, that VCSs
have the concept of a branch and what it's used for, my eyes glaze over,
and I start subconsciously skimming the text in the hope of coming across
something solid and useful.

The information density in the git-merge man page is low in a different
way: being so vague and imprecise it makes little sense on its own,
because you've got to keep searching externally for information needed to
get meaning out of it.

-- 
Alan Mackenzie (Nuremberg, Germany).