Re: Git branches - confusing behavior

[Dima Kagan <dima.kagan@gmail.com>]

Björn Steinbrink wrote:
 > 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).
> 
> Björn

My proposed change shouldn't necessarily break the described workflow. Git can keep the current behavior for new branches, but automatically 'stash' the changes when checking-out an existing branch. At least having an optional parameter for "auto-stashing" will be nice.

What do you think of that?