On Fri, Apr 02, 2010 at 02:49:25AM -0400, Avery Pennarun wrote: > On Fri, Apr 2, 2010 at 2:10 AM, Peter Baumann <waste.manager@xxxxxx> wrote: > > On Fri, Apr 02, 2010 at 12:48:44AM -0400, Avery Pennarun wrote: > >> # configure your git-svn so that all its branches are under remotes/svn/* > >> git fetch origin > >> git svn fetch --fetch-all > >> for each branch in remotes/svn/* > >> git checkout remotes/svn/$branch # detaches HEAD > >> git merge --no-ff origin/$branch > >> git svn dcommit # replaces merge commit > >> git checkout origin/$branch > >> git merge remotes/svn/$branch > >> git push origin HEAD:$branch > >> git push origin refs/remotes/svn/*:refs/heads/svn/* > > > > If I understand you correctly, this will commit only the the merge to svn > > and won't show all the commits the developer made (because of the --no-ff). > > From a SVN standpoint isn't it the same as doing the following? > > > > git checkout remotes/svn/$branch # to deatch the HEAD > > git merge --squash origin/$branch > > git svn dcommit > > > > I asked because in my workflow I can't to afford lossing the single commits. > > No, not quite the same. > > When git-svn replaces your merge commit with a new commit (as part of > the 'git svn dcommit' step) the new commit *stays* a merge commit in > git. That means it has two parents: the svn parent commit, and the > commit that you merged from in the first place. > > So what happens is that svn will see only a single commit, but your > git history remains intact and git push/pulling will continue working > as you expect. > Ah. Ok. So I actually was true, meaning "from a SVN standpoint", I just expressed myself not clearly. > If you really need svn to see every individual commit, then you're out > of luck. The only way to do it is to rebase every time you want to > commit to svn. git-svn then replaces every single one of your commits > (essentially another rebase, so it can add the git-svn: tags to the > commit message) which makes push/pulling between git repos impossible. > > So those are your two choices. Personally, I like my way as a > transition plan, because the git repo keeps the precise history > (including forks and merges), while the svn keeps *working* for the > stragglers who want to keep using it. > Thx for your explanation, Peter -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html