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

[David Kastrup]

Alan Mackenzie <address@hidden> 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.
> 2. git changes branches, discarding all uncommitted changes.
> 3. git changes branches, leaving the changes from the previous branch in
> the working directory.

Either 1 or 3, depending on whether the difference between the two
branches overlaps with the uncommitted changes or not.  When Git can
just keep the uncommitted changes without conflict, it does that.  This
comes in rather handy when you start doing some work, then figure out
that you really should have started a new branch.  You can then just
checkout/create the new branch and ultimately commit there.

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

Nope.  There is only one index and one work directory.  Just commit
them.  You can also do "git stash" for saving index/work directory on a
stack and use "git stash pop" for getting them back out again later when
you switch back to your branch, but stashes are not tied to a particular
branch either.

It's usually just easier to do

git commit -m "wip" -a

and have a commit with message "wip" (work in progress) on the branch
where it belongs.  You can fix that commit up later with

git commit --amend

in order to both fix the commit message as well as adding more changes
to it.

-- 
David Kastrup