Re: Git question: when using branches, how does git treat working files when changing branches?

[Alan Mackenzie]

Hello, Óscar.

On Wed, Oct 28, 2015 at 11:59:03PM +0100, Óscar Fuentes wrote:
> Alan Mackenzie <address@hidden> writes:

> Joining the emacs-devel git hot line...

> >> By default git will complain if changing branches would revert
> >> uncommitted changes.

> > OK, I started with a test repository, with some changes in (which I saved
> > in a diff file).  After listing the available branches, and chosing one
> > at random, I did
> >     $ git checkout /origin/master
> > , and got some message or other about a detached head.  Without doing
> > anything else I then switched back with
> >     $ git checkout master.

> > git status now reports that the working directory is "clean".  So one of
> > these two operations has discarded my changes.

> This is hard to believe, so I tried your steps:

> address@hidden:~/dev/emacs/emacs$ git checkout /origin/master
> fatal: Could not switch to '/origin/': No such file or directory

> As you can see, your first command fails to complete. I requested this
> on a previous question of yours about git and I request it again: please
> post the *exact* commands and its output. Otherwise, claims like what
> you made above are dubious, at best.

As you probably could guess, "/origin/master" was a typo, and the actual
text was "origin/master".  It's getting quite late.

Having a look at my series of commands after the first git checkout, I
in fact did a git stash list.  I don't think that list was empty when I
typed that command.  It isn't empty now.  In other words, that first git
checkout stashed my changes, it didn't discard them.  It may have told
me, it might not have.

> [snip]

> >> Well I usually do a stash/rebase/stash-pop cycle in magit. However you
> >> may want to look at the rebase.autostash option (since Git 2.6)

> > The problem is that, according to David K, there's only one stash stack,
> > so it would be very inconvenient having to keep track of which entries in
> > this stack belong to which branches.

> David Kastrup also suggested to commit your changes before switching
> branches, I wonder why you ignored his advice.

It wouldn't work well for me.  The word "commit" has a meaning,
something like "hand over on a permanent basis".  When you make a
"commitment", you are pledging your honour that you will stand behind
what you have committed.  What "commit" _doesn't_ mean is "temporarily
store because there's nowhere better".  Of course there are ways of
undoing a commit if it was done by mistake.  But routinely to commit to
something with the intention of repudiating it later is an abuse.  It is
the sort of thing politicians do.

Committed software and work in progress are two different categories of
code.  To confuse them must lead to trouble.

If I were were to commit unfinished changes just for lack of somewhere
proper to store them, inevitably some of these changes would find
themselves becoming permanent, embarassingly so.  Having continually to
remember to cancel a commit each time I change branches would be an
extra level of stress, of which there is already enough with git.

> Over the years I used several VC systems (CVS and subversion, among
> others) and git is, by far, the one that makes things easier when you
> don't want to lose your changes, committed or not.

git hid my changes, for what reason I don't know.

Right at the moment, 00:41 (which isn't a good time to make judgements),
I don't think I'm going to be using these branches, they're just to
awkward for the way I work.  Instead I'll use several distinct
repositories, minimising the potential for confusion and loss.  I'll
need a more intelligent backup strategy than I've got at the moment, but
I can manage that.

> Finally, I wholeheartedly recommend to give Magit a try.

Sometime, maybe.  Trouble is, it's all more stuff to learn, and it might
not work well for me.

> [snip]

-- 
Alan Mackenzie (Nuremberg, Germany).