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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
