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

[Alan Mackenzie <acm@muc.de>]

Hello, Alex.

On Wed, Oct 28, 2015 at 08:10:14PM +0000, Alex Bennée wrote:

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

> > Hello, Emacs.

> > I want to start using git branches, so as to be able to work on several
> > distinct things at the same time.

> > My question is, how does git handle working files (which haven't been
> > committed) when changing from one branch to another.  I've spent the
> > usual two hours searching the fine manuals without turning up a clear
> > explanation.

> > One thing that worries me is that the same command "git checkout" is
> > used to change branches and to revert changes to a file.  So it seems
> > plausible that each time I swap to a different branch I'm in danger of
> > irrevocably losing existing changes to source files.

> > So, what happens to to changes in the working directory when changing
> > branches?
> > 1. git refuses to change branches because there are uncommitted
> > changes.

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

> > 2. git changes branches, discarding all uncommitted changes.

This has indeed happened.

So it would seem a good idea, before switching branches, to make a
complete backup of ones changes with git diff > foo.diff.

> You can force it to reset everything (which you don't want)

> > 3. git changes branches, leaving the changes from the previous branch in
> > the working directory.

> > What I really want to happen is
> > 4. git maintains uncommitted changes separately in each branch.

> > I suspect 4. is not the way git works.  So, how do I best simulate 4.?
> > I would like to be able to move freely between git branches without
> > suffering stupid restrictions like having to worry about preserving
> > changes in the working directory.  Is there some variant of "git stash"
> > which might do what I want?

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

Or, maybe I would be better just keeping several distinct copies of the
repository, all cloned off of a master master, and using git push to
propagate changes from a sub-master to it.  That would mean me having to
be more selective with my backups, but it might be the best solution.

> -- 
> Alex Bennée

-- 
Alan Mackenzie (Nuremberg, Germany).