On 13 October 2014 18:52, Gordon Sim <[email protected]> wrote: > 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. >
git-svn acts somewhat like regular git until you get to the point of doing the svn dcommit, so thats why you ended up with all the individual commits when you merged using git and then did a dcommit to push to svn. Squashing the changes into a single commit against the JIRA (or NO-JIRA) you are working on at the time is what I would do in these cases, which you can either ask git to do duing the merge or do it explicitly afterwards.
