Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > branches have always been pointers to the top-of-commit Obviously I expected them to be pointers on trees. A kind of automatical starting commit in a newly created branch would at least warn if one has begun changing files and wants to checkout back. (Is this a feature worth of discussion?) > the git behavior explicitly _encourages_ you to not have to decide > before-the-fact to create a branch Thanks for the explanation which help me to understand why git works like it does. I'm able to follow your examples, but what I had it mind when I started the topic and my example was: Assume a project is released (i.e. no more open bugs we know about) - I know we're drifting towards fantasy now. ;-) On the one hand, I want to add single new features (such as other developers do) which will be written, tested and committed. I want to push/pull frequently to be up to date all the time. (master branch) On the other hand, I want to completely rewrite the core of the program. (test or rewrite branch) What is the git way to do this in a the right (and clever) manner? In a branch, I learned, I have to commit or stash before I return to master for push/pull to follow the project. If I forget, I'm screwed, because files have changed due to the rewrite (in that branch), I won't get a warning until my first commit (in that branch) and commits (in master) will conflict. Ingo -- 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