threads / discuss / 27223

What Features Do I loose With git-svn?

Subject: What Features Do I loose With git-svn?

## tl;dr

3 messages between Apr 29, 2011 and Apr 30, 2011.

replies: 2people: 3as markdown or json

ryanzec· Apr 29, 2011, 16:53 UTC · lore

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>

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.-- View this message in context: http://git.661346.n2.nabble.com/What-Features-Do-I-loose-With-git-svn-tp6317576p6317576.html Sent from the git mailing list archive at Nabble.com.

Motiejus Jakštys· Apr 29, 2011, 17:16 UTC · re: ryanzec · lore

Re: What Features Do I loose With git-svn?

On Fri, Apr 29, 2011 at 09:53:49AM -0700, ryanzec wrote:

Show 16 quoted lines

> 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

Thomas Ferris Nicolaisen· Apr 30, 2011, 23:08 UTC · re: ryanzec · lore

Re: What Features Do I loose With git-svn?

On Fri, Apr 29, 2011 at 6:53 PM, ryanzec <basire@gmail.com> wrote:

Show 8 quoted lines

> 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).

Subversion does not grok the semantics of a merge. That means that if you merge in a branch and do an svn dcommit, the svn log will only contain the commit message of the merge-commit, and have no trace of the commits that took place out in the branch.

The tidiest way around this is generally to keep history linear, and avoid merging by doing rebasing instead.

Have a look at the screencast here, it should explain it pretty well: http://blog.tfnico.com/2010/10/gitsvn-4-collaborate-with-other-git.html

You can still cherry pick. Actually, cherry-picking has served me very well for doing traditional SVN "merges" (copying a commit from one branch to the other, instead of that clunky svn merge -c R url . stuff).