{"thread":{"id":"27223","subject":"What Features Do I loose With git-svn?","startedAt":"2011-04-29T16:53:49Z","lastAt":"2011-04-30T23:08:36Z","messageCount":3,"participants":["ryanzec","Motiejus Jakštys","Thomas Ferris Nicolaisen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"166755","messageId":"1304096029355-6317576.post@n2.nabble.com","threadId":"27223","inReplyTo":null,"subject":"What Features Do I loose With git-svn?","fromName":"ryanzec","fromEmail":"basire@gmail.com","sentAt":"2011-04-29T16:53:49Z","receivedAt":"2011-04-29T16:53:49Z","isPatch":false,"sender":{"key":"basire@gmail.com","avatar":null},"body":"I want to use git for a project I am working on however because the project\nis going to possibility have a lot of binary content in size and number of\nfiles (game project), it is probably going to be hard to convince my team to\nmake the switch since I have no real solution besides just use git for the\ncode and svn for the binary data.  I am hoping git-svn will do the trick for\nme.  The question is are they any features I loose (like cherry picking) or\nanything that I have to look out for (does updating from svn cause merging\nissues just like working all in SVN does).  Right now the only things I know\nto look out for is:\n\n<ul>\n<li>Instead of git pull/push I have to use the git-svn equivalents</li>\n<li>If I have changes that are not in the index and I need to pull the\nlatest code form SVN, I have to stash first, update from svn, and then apply\nthe stash back.</li>\n</ul>\n\nAny other things I have to look out for?  I am mainly concerned that using\ngit-svn will re-introduce the merge issues of SVN the git is great at doing.--\nView this message in context: http://git.661346.n2.nabble.com/What-Features-Do-I-loose-With-git-svn-tp6317576p6317576.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"166757","messageId":"20110429171629.GA3394@jakstys.lt","threadId":"27223","inReplyTo":"1304096029355-6317576.post@n2.nabble.com","subject":"Re: What Features Do I loose With git-svn?","fromName":"Motiejus Jakštys","fromEmail":"desired.mta@gmail.com","sentAt":"2011-04-29T17:16:29Z","receivedAt":"2011-04-29T17:16:29Z","isPatch":false,"sender":{"key":"desired.mta@gmail.com","avatar":"https://gravatar.com/avatar/5d7d88e7b672acebe3472e92baccb5f933fbd282b6131e22e32d96e5818b5b38?d=mp&s=160"},"body":"On Fri, Apr 29, 2011 at 09:53:49AM -0700, ryanzec wrote:\n> I want to use git for a project I am working on however because the project\n> is going to possibility have a lot of binary content in size and number of\n> files (game project), it is probably going to be hard to convince my team to\n> make the switch since I have no real solution besides just use git for the\n> code and svn for the binary data.  I am hoping git-svn will do the trick for\n> me.  The question is are they any features I loose (like cherry picking) or\n> anything that I have to look out for (does updating from svn cause merging\n> issues just like working all in SVN does).  Right now the only things I know\n> to look out for is:\n> \n> <ul>\n> <li>Instead of git pull/push I have to use the git-svn equivalents</li>\n> <li>If I have changes that are not in the index and I need to pull the\n> latest code form SVN, I have to stash first, update from svn, and then apply\n> the stash back.</li>\n> </ul>\nThis list does not support HTML. Thankfully. :)\n\n> \n> Any other things I have to look out for?  I am mainly concerned that using\n> git-svn will re-introduce the merge issues of SVN the git is great at doing.--\nI never tried merging of \"SVN\" branches. What I used to do is check-out\nmy local branch from tip of master (svn upstream), work on it. Before\n\"merging\" changes upstream I rebased on top of upstream again, got a\nfast-forward, and pushed to SVN.\n\nIf you used git-svn, why would you \"merge\"? As it does not support\n\"reverting\" (at least I'm unaware of it), it's quite unnecessary IMHO\n(put your merge commits upstream).\n\nMotiejus\n"},{"id":"166804","messageId":"BANLkTinEgDSFsOj2uY-2WdridoD1ZhQQKw@mail.gmail.com","threadId":"27223","inReplyTo":"1304096029355-6317576.post@n2.nabble.com","subject":"Re: What Features Do I loose With git-svn?","fromName":"Thomas Ferris Nicolaisen","fromEmail":"tfnico@gmail.com","sentAt":"2011-04-30T23:08:36Z","receivedAt":"2011-04-30T23:08:36Z","isPatch":false,"sender":{"key":"tfnico@gmail.com","avatar":"https://gravatar.com/avatar/628cf28a25ca4c596c7284562100f70f0ef908bcbfadd4da1eb3d48c23658d01?d=mp&s=160"},"body":"On Fri, Apr 29, 2011 at 6:53 PM, ryanzec <basire@gmail.com> wrote:\n> I want to use git for a project I am working on however because the project\n> is going to possibility have a lot of binary content in size and number of\n> files (game project), it is probably going to be hard to convince my team to\n> make the switch since I have no real solution besides just use git for the\n> code and svn for the binary data.  I am hoping git-svn will do the trick for\n> me.  The question is are they any features I loose (like cherry picking) or\n> anything that I have to look out for (does updating from svn cause merging\n> issues just like working all in SVN does).\n\nSubversion does not grok the semantics of a merge. That means that if\nyou merge in a branch and do an svn dcommit, the svn log will only\ncontain the commit message of the merge-commit, and have no trace of\nthe commits that took place out in the branch.\n\nThe tidiest way around this is generally to keep history linear, and\navoid merging by doing rebasing instead.\n\nHave a look at the screencast here, it should explain it pretty well:\nhttp://blog.tfnico.com/2010/10/gitsvn-4-collaborate-with-other-git.html\n\nYou can still cherry pick. Actually, cherry-picking has served me very\nwell for doing traditional SVN \"merges\" (copying a commit from one\nbranch to the other, instead of that clunky svn merge -c R url .\nstuff).\n"}]}