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. -- Robin Burchell -- 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
