On Wed, 19 Aug 2009, Ingo Brueckl wrote:
> Jakub Narebski <jnareb@xxxxxxxxx> writes:
>
> > You finish old work (or stash it away), _then_ you begin new work.
>
> Ok, this helps me a little bit to understand.
>
> The branches aren't designed to split my work, but rather something to
> collect the different parts of my work.
Hmm. Yes. That's one way of looking at it.
At the same time, thinking about it another way may explain the git
choices in this area. There's two issues:
- if we _don't_ carry the edits around across branch switches, then what
would we do?
Basically, since you haven't committed things, it's kind of floating
around. You switch to another branch, what should we do? There are
really only two choices: either we'd need to 'stash' the state with the
branch we switch away from (which is apparently what you expected), or
we need to just move the changes to the new branch (which is what git
does, or complains if it cannot).
Now, 'stashing' the changes is actually very much against the whole git
philosophy. Git was built up around the index and the database, and
branches have always been pointers to the top-of-commit, so there
literally isn't any way to stash things that makes sense. Sure, later
on we ended up having the 'stash' command, but that's totally separate
from branches, and is an independently useful thing.
- One of the big reasons to act like git does is that the way at least
_I_ work is to actually create a new branch with the explicit intention
of committing work I have already done!
IOW, your example was
git branch test
git checkout test
# edit foo.bar
git checkout master
and you were surprised that the edit followed you back to the "master"
branch, but what is actualyl a much more natural way of working is
# edit foo.bar
# realize that this was actually the start of a new feature
git branch new-feature
git checkout new-feature
# maybe continue to edit foo.bar until it's all good
git commit -a
ie the git behavior explicitly _encourages_ you to not have to decide
before-the-fact to create a branch - it may be that only after you've
done the changes do you realize that "oops, these changes were _way_
more intrusive than I originally anticipated, and I don't want to
commit them on the master branch, I want to commit them on an
experimental topic branch instead"
So there are two different reasons why git works the way it does: a pure
implementation reason ("working any other way would not fit the git
model") and a practical workflow reason ("you are _expected_ to move dirty
state around with your branches, because one common case is to create a
branch _for_ that dirty state").
Linus
--
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