From: Motiejus Jakštys <desired.mta@gmail.com>
Date: Fri, 29 Apr 2011 17:16:29 GMT
Subject: Re: What Features Do I loose With git-svn?
Message-ID: <20110429171629.GA3394@jakstys.lt>
In-Reply-To: <1304096029355-6317576.post@n2.nabble.com>

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