Re: question concerning branches

On Wed, 19 Aug 2009, Ingo Brueckl wrote:

Jakub Narebski [off-list ref] writes:

quoted

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