question concerning branches

[ib@wupperonline.de (Ingo Brueckl)]

Linus Torvalds <torvalds@linux-foundation.org> 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