[SciPy-dev] Git-svn sub-optimality

[Pauli Virtanen]

Sun, 08 Mar 2009 17:31:24 +0900, David Cournapeau wrote:

> Pauli Virtanen wrote:
>> Hi David (& other prospective git-svn users),
>>
>> I just ran into a speedbump with git-svn and using the Git mirror:
>>
>>     http://projects.scipy.org/numpy/wiki/GitMirror#Abigfatwordofwarning
>>
>> In short: apparently git-svn does not automatically track SVN commits
>> appearing elsewhere than locally via `git-svn fetch/rebase`. So if you
>> want to `dcommit` after `git fetch`ing from the mirror or from someone
>> else, the database of git-svn needs to be rebuilt:
>>
>>     rm -rf .git/svn
>>     git svn rebase -l
>>
>> Otherwise, the `dcommit` will shove bogus changesets to SVN. (Ouch!)
>>   
>>   
> Hm, do you have an example of that ? It never happened to me. My typical
> usage is when I start working on numpy is:
> 
> git svn fetch --all
> git co master && git svn rebase -l
> git co -b line_of_work
> 
> When I use dcommit, it first rebase my changes on top of svn last
> revision if the last svn revision differs from the on I have locally.

It doesn't occur if you stick to the usual git-svn workflow of getting 
SVN commits via `git svn fetch/rebase` only. An example where it occurs is

    git fetch mirror      # fetch branch from mirror or from someone else
    git rebase svn/trunk  # rebase on it
    git svn dcommit -n    # now try to dcommit

Now git-svn thinks the current branch still corresponds to the old 
version, and uses that as the base for `dcommit`. However, doing `git svn 
rebase` does not fix the situation, since `git-svn` also thinks that the 
current branch is based on the latest commit, and is so up-to-date.

I'll also note that if you do merges and then `dcommit` the result, this 
makes the tree generated by `git-svn` diverge from the one in the mirror 
(since in the mirror the merge commit has only one parent, but in the 
private tree it has two -- `git-svn fetch` doesn't track merges).

-- 
Pauli Virtanen