Re: VC mode and git

[Alan Mackenzie]

Hello, Stephen.

On Wed, Apr 01, 2015 at 02:38:34AM +0900, Stephen J. Turnbull wrote:
> 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.

Maybe you're right.  I can't remember any more.

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

Irreversable?  Any patch operation without conflicts is reversable, and
if there are conflicts, a backup of the original should have been made by
the patch program.

Anyhow, there are lots of irreversable things that happen in a VCS
repository.  The act of having committed, or merged, or whatever cannot,
with some exceptions, be reversed.

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

It is documented in the hg page.  It says (under merge): "The current
working directory is updated with all changes made in the requested
revision since the last common predecessor revision.".  If this doesn't
work when a file in the W.D. has been changed, that looks like a bug,
whether in the code or the documentation.

> .... and Bazaar requires that you use "bzr merge --force".  I really
> don't understand how you can criticize git alone for this.

Because it's only git that's ever given me problems in this respect.  I
don't recall ever having problems with bzr update when I had uncommitted
changes.  I use hg in such a way that mergeing is rarely, if ever,
needed.

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

> Risk-lover!  No wonder you lose changes.

I do not love risk.  The risk of getting my repository in an inextricable
tangle, like Richard has done, far outweighs any supposed risks of
just-in-time committing.

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

I think I've used this at one time or another.

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

-- 
Alan Mackenzie (Nuremberg, Germany).