I am reading the CAVEATS of git-svn. via this SO question.
What I understand is that:
If you are mirroring svn trunk, branches etc on git repo, don't merge or rebase anything locally on those branches. Specifically master
points to the trunk
.
My point is that, this would make git-svn
crippled. What's the point of git, if I can't branch from master and then merge that changed branch back into the master? Perhaps I am missing some caveat in the caveat that says it is ok to merge certain branches that have the same parent without any rebases.
Can anyone point to me exactly what needs to be avoided and what is allowed. I'd want the local branches, if necessary, those need to be mirrored and merged and most importantly git should do the merges than the svn.
If I am using git branches to mirror svn branches and I cannot merge git branches, whats really the point of git-svn anyway?
You can merge git branches, that is the ones which aren't directly mirrored from SVN.
I would to have my own set of Git branches, made from the "git-svn" branches, and rebased regularly on top of said "git-svn" branches.
That way, I do all the merges I need locally in the Git repo, then I cherry-pick what I need in order to update the "git-svn" branches, that I can safely dcommit
without worrying about the first parent mentioned in the CAVEAT section of git-svn
git-svn is crippled by definition. You can't do anything Subversion doesn't grok, like merges.
HOWEVER, you can bend around Subversion's rules temporarily with rebasing. I've shown an example of this in a blog-post/screencast:
http://blog.tfnico.com/2010/10/gitsvn-4-collaborate-with-other-git.html
(Lots of more tips on working with git-svn here.)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With