Re: VC mode and git

[Steinar Bang <sb@dod.no>]

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

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

I agree with Stephen's assesments here.

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

If you want to work with uncommitted changes on a tracking branch, yes.

Note: you can always just try a pull first, it will stop if it needs to
merge some of the files you have changes in.

Ie. with no conflicts betwen pull and your modified files:
 git pull
 git commit
 git push
and with conflicts between pull and your modified files:
 git pull
 <oops! pull wants to merge some of your open files>
 git stash
 git pull
 git stash pop
 git commit
 git push

Or you can just do the stash anyway, even if it's needed or not:
git stash
git pull
git stash pop
git commit
git push

Or:
 git commit
 git pull --rebase
 git push
(forgive me, Eli, I said the "r" word...)

> Yuck!  A proper fix would be for merge to actually merge the new
> changes into the working directory.

Um... no.  I agree with Stephen here also.

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

Then either always do this:
Or you can just do the stash anyway, even if it's needed or not:
git stash
git pull
git stash pop
git commit
git push

Or, this:
 git commit
 git pull --rebase
 git push

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

The merge part of "pull".  "git pull" is actually:
 git fetch
 git merge origin/master

> When one mixes up committing with staging with fetching with pushing,
> inevitably there will sometimes be merge operations required all over
> the place.

Not sure what you mean here.

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

You have the following modified files in the workspace:
 ChangeLog
 a.c
 b.c
 c.c
 d.c
and then you modify a.c and c.c and in magit you will see:
 Unstaged changes:
          Modified a.c
          Modified c.c

and then you pull, and that results in d.c being succsessfully merged,
but ChangeLog failing with a conflict, and in magit it looks like this:
 Unstaged changes:
        C Modified ChangeLog
          Modified a.c
          Modified c.c
 Staged changes:
          Modified d.c

(since there was a conflict the merge wasn't completed commit, and there
are now many changes unrelated to the merge that could become part of
the merge commit)

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

Actually, that's what git tries to encourage, either by having you
commit your changes before pulling or alternatively, stashing the
changes before you pull, and then unstashing them and creating a new
commit separate to the merge commit.

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

Um... it may not be the book for you, but it's not written for beginners
in VCS.  In fact it requires quite a bit in understanding of data
structures.

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

To read it you need to read it like you read code examples and
think about and visualize what the datastructures look like.  It was
when I read this (after having used git for a year or so), that git
started making sense to me.

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

FWIW you're in good company here.  I just use them to get the exact
command line arguments when I can't remember them.