on Wed Feb 20 2013, Beman Dawes <bdawes-AT-acm.org> wrote:
On Thu, Feb 14, 2013 at 9:55 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Thu Feb 14 2013, Daniel Pfeifer <daniel-AT-pfeifer-mail.de> wrote:
2013/2/14 Joaquín Mª López Muñoz <joaquin@tid.es>:
Hi,
I'd like to commit some changes to one of my libs for delivery with Boost 1.54. Should I use SVN as always or begin now using Git for the commit?
You should commit to SVN. The Svn2Git conversion is still incomplete (Tags are not converted yet).
Note: if you want to use Git for some reason, you can always use git-svn to dcommit to the Boost SVN repository. You won't get a modularized view of the code that way, but you will be using Git.
Thanks for mentioning git-svn! I've started to use it so that I can easily work on multiple private branches at the same time, pushing to a GitHub repo as off-site backup.
The one issue I ran into is a single "git svn dcommit" doing separate svn commits for each of my local git commits, resulting in 18 svn commits and totally incomprehensible history. The point of what should have been a single svn commit ("reimplement path::codecvt() and path::imbue() portably for more robust behavior") got totally lost.
AFASICT, the fix is to work only on branches, use "git merge --no-commit --squash" to merge back to master, do a master commit with a meaningful message, then do the "git svn dcommit".
If anyone has a better approach, please let me know:-)
I don't know git-svn really well, but if it would let you dcommit to an SVN branch and then create an SVN merge commit containing the results of the git merge, you'd be able to preserve the historical record without wiping out coherence. -- Dave Abrahams