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

["Óscar Fuentes" <ofv@wanadoo.es>]

Alan Mackenzie <acm@muc.de> 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:

oscar@qcore:~/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.

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

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.

Finally, I wholeheartedly recommend to give Magit a try.

[snip]