----- Original Message ----- > On 10/13/2014 06:40 PM, Alan Conway wrote: > > > > > > ----- 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. > > What I did was merge in git, then I did git svn rebase before git svn > dcommit. So I didn't really rebase the changes that were already public > on my branch. I took approach 2. > > I didn't quite expect or intend what actually happened, but on > reflection I'm not sure what else I would have expected in svn. I > probably should have just squashed everything down to a single diff > before committing back to svn(?). I think thats pretty much what it > would have been if I had done the merge through svn. >
In that case you did what I would have done - I would have expected git-svn to convert a git merge commit into an svn merge commit. Rather sad that it didn't. You can do a git merge --squash to create a merge commit without a merge arrow, so it has the same effect as the merge but throws away the merge information. I would have hoped that by now we would be able to get the merge reflected in SVN though. Sigh.
