git rebase -- a suggestion

Hi,

This is my first mail to this list, so I hope I'm not breaking any form of ettiquette, etc. If I do step on any toes, feel free to bop me on the head with a rubber mallet, or steer me in the right direction.

That over, I have a suggestion for `git rebase', from the perspective of a newcomer.

I've been using git instead of svn (and various other VCS) now for about a month, and am finding it quite a refreshing change.

I have also recently started a collaborative project exclusively with git (well, pulling changes from a git-svn repo I don't control) which has been a valuable ..learning experience.

With this in mind, I'd like to mention exactly what I did.

Upstream had issued a new commit, so I, not knowing the possible dangers used git-svn rebase to pull in the new changes to our tree.

This "appeared" to work fine, but alarm bells were already going off in my head before I typed the command (I didn't know at the time I could merge svn trees like I could normal git branches) as I knew that rebase rewrote history, and I saw it do this to about 300 commits.

It promptly made merging absolute hell with the other few members of my team, as it would.

Granted - this is a mistake on my part, and probably a common newbie one, but something that came to mind when thinking about it later: would it perhaps be an idea to have a way to mark a tree 'public', and disallow rebase *unless* --force was passed, or it was a public tree?

(Then again, the alternative might be more 'intelligent' for new users: start off with branches defaulting to private, and marking them public, disallowing use of rebase, etc).

Thoughts, feedback, etc are welcome.