Re: VC mode and git

[Stephen J. Turnbull]

Alan Mackenzie writes:

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

The only other possibilities I can think of is that for some reason
you nuked them yourself and forgot about it (perhaps you never saved
them), or that you "lost" them on a different branch, and they're
still in your repo, you just don't know where to find them.

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

You may think that's a fix, but the git developers will call it a bug,
because it's irreversible -- there's no way for git to get back to the
pre-merge state, ensuring that your uncommitted changes are preserved.

And they're in good company: Mercurial won't allow you to do that *at
all* AFAICT (and the restriction is *not* documented in that man page
you think is so concise and adequate), and Bazaar requires that you
use "bzr merge --force".  I really don't understand how you can
criticize git alone for this.

 > Not me.  In my normal workflow, I commit at the last minute, then
 > push.

Risk-lover!  No wonder you lose changes.

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

I think that "git pull --rebase" was made in heaven for you.

 > Is it really too much to expect that git merge should merge these
 > new fetched changes into my working directory?

If you have uncommitted changes, yes, it's too much to expect.  See
above.