On Fri, Apr 29, 2011 at 09:53:49AM -0700, ryanzec wrote: > I want to use git for a project I am working on however because the project > is going to possibility have a lot of binary content in size and number of > files (game project), it is probably going to be hard to convince my team to > make the switch since I have no real solution besides just use git for the > code and svn for the binary data. I am hoping git-svn will do the trick for > me. The question is are they any features I loose (like cherry picking) or > anything that I have to look out for (does updating from svn cause merging > issues just like working all in SVN does). Right now the only things I know > to look out for is: > > <ul> > <li>Instead of git pull/push I have to use the git-svn equivalents</li> > <li>If I have changes that are not in the index and I need to pull the > latest code form SVN, I have to stash first, update from svn, and then apply > the stash back.</li> > </ul> This list does not support HTML. Thankfully. :) > > Any other things I have to look out for? I am mainly concerned that using > git-svn will re-introduce the merge issues of SVN the git is great at doing.-- I never tried merging of "SVN" branches. What I used to do is check-out my local branch from tip of master (svn upstream), work on it. Before "merging" changes upstream I rebased on top of upstream again, got a fast-forward, and pushed to SVN. If you used git-svn, why would you "merge"? As it does not support "reverting" (at least I'm unaware of it), it's quite unnecessary IMHO (put your merge commits upstream). Motiejus -- 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