----- Original Message ----- > I rebased the branch on which I have been developing some examples. I > did this using got svn (quite possibly incorrectly) resulting in a > commit to branch per original commit. Sorry for the noise. > > I'll post some information about progress on the examples and supporting > toolkit over on the user list shortly. >
Small bit of my change management experience for whatever it is worth. There are two approaches to handling a development branch against a moving upstream branch (trunk, master whatever): 1. rebase your dev branch on the upstream: this creates a nice linear history and keeps your work together in a chunk of commits. 2. merge out periodically from upstream to dev branch: creates a "ladder" between your dev branch and the upstream. Attempting to rebase work *once it has been put in a repo that other people see* is a Very Bad Idea. So if you want to work in public (which is a good idea for long-duration work that you want to share with others) then you are stuck with 2. 2 is not so bad, there are change management tools (e.g. clearcase) where it is the only option, and it works just fine. Basically the deal is this: rebasing is an attempt to re-write history so it looks like you started your work at the tip of the upstream branch. This is a *lie*. If this is private history in your personal git repo that nobody has ever seen then that's fine, people lie to themselves all the time. If it is public history in an upstream GIT or SVN repo that other people pull from then its not fine. In a pure git environment this will really mess up anyone who has pulled the old history. I'm not sure exactly what git-svn will attempt to do but it sound like it creates an entirely new copy of the history, which defeats the purpose of re-basing and is even messier than merge-out. Merging out is a bit unsightly but it has these nice properties: - it does not attempt to modify existing commits or change the meaning of existing references. - it clearly shows the merge history between the branches involved. So 1. is a good way to hide your private mess and confusion from the world. HOWEVER once you have pushed your commits to a branch on a public repo they are public property. You can update a public branch by merging out and adding new commits, but you can't erase the old ones and pretend that you started from the tip of latest trunk with squeaky clean code. Everyone already knows you didn't. Cheers, Alan.
