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