Re: Git branches - confusing behavior

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: May 11, 2008, 13:27 UTC
Message-ID: <20080511132752.GA22778@atjola.homenet>
In-Reply-To: <4826EEDF.4010404@gmail.com>

On 2008.05.11 16:04:31 +0300, Dima Kagan wrote:

Show 15 quoted lines

> Björn Steinbrink wrote:
> > On 2008.05.11 15:33:21 +0300, Dima Kagan wrote:
> >>>> Basically I see that the same file I edited on the 'test_branch'
> >>>> branch appears to be modified on the 'master' branch as well. This
> >>>> behavior is unwanted, of course.
> >>>>
> >>>> Can someone please tell me, what am doing wrong? Or is this git's
> >>>> normal behavior?
> >> I just realized that this behavior is even more confusing.  If I
> >> commit the file on 'test_branch' and only then 'git checkout master'
> >> the changes are not visible on 'master' until I merge. So why should
> >> 'master' be affected by uncommitted changes on some branch???
> > 
> > Uncommitted changes are not on any branch, they are in your working tree
> >

[example removed]

Show 7 quoted lines

> > 
> > 
> > The uncommitted changes survived the branch change and are still in the
> > working tree, in svn just like in git.
> 
> Yes, I am aware of that, except one rarely works in one directory on
> multiple svn branches, because the branches are not private.

I always did that, the working copy _is_ private even in svn, so messing with that was not a problem there either.

> Git's branches can be private, so perhaps this behavior should be
> different from SVN?

No. Uncommitted changes are, well, uncommitted. They don't belong to any branch yet. A branch is not some structure that contains history in itself. A branch just points to a commit, and the commits, with their parent-child relations, form the actual history. The index and working tree are not part of a branch.

Changing that would even break a workflow that is rather common for me. I start working on something that is either just experimental or assumed to be a very small change. Then I realize that the change is worth keeping and/or too big and deserves its own branch. At that point, I can just do "git checkout -b new_branch", and pretend that I started working on that branch right from the start. With your proposed change, I would need some extra command to transfer the work in progress from the old branch to the new branch.

If I ever want to switch to another branch and not keep the changes in my working tree and index, I stash them away or create a temporary commit, which I later amend. That's a use-case that comes up rather seldom though (for me at least).

> BTW, Is there a way to do 'svn checkout -b new_branch' into a new directory?

There's a script (new-working-tree or so) in contrib/ that can create a second working tree for a given repo, but I usually prefer to just clone my repo locally. In the second repo, I can then switch branches as much as I like ;-)

Björn