[git] Should I commit to SVN or Git?
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? I've skimmed thru the Git transition project wiki and it doesn't seem to have anything on dates for SVN deprecation etc. Thank you, Joaquín M López Muñoz Telefónica Digital ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx
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).
I've skimmed thru the Git transition project wiki and it doesn't seem to have anything on dates for SVN deprecation etc.
We should fix that. -- Daniel
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. -- Dave Abrahams
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:-) --Beman
On 20 February 2013 14:35, Beman Dawes wrote:
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:-)
You can still work on master, then before the dcommit do: git rebase -i Change all but the first "pick" to "squash" and you'll ge a single commit combining all the small commits, then dcommit that.
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
participants (5)
-
Beman Dawes -
Daniel Pfeifer -
Dave Abrahams -
Joaquín Mª López Muñoz -
Jonathan Wakely