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


Reply via email to