Re: git-svn rebase "problems"

From: Peter Harris <git@peter.is-a-geek.org>
Date: Dec 2, 2008, 15:21 UTC
Message-ID: <eaa105840812020721t299009bcv15e2805cc040854@mail.gmail.com>
In-Reply-To: <73fd69b50812020656u3fd17015n267f694236982e5@mail.gmail.com>

On Tue, Dec 2, 2008 at 9:56 AM, Joe Fiorini wrote:

> Are there any other details I can provide to get an answer on this?

Maybe an actual script that reproduces the problem you're seeing?

Show 7 quoted lines

> On Sun, Nov 30, 2008 at 10:17 PM, Joe Fiorini wrote:
>>
>> So I'm using git-svn. My team tends to commit to the svn server fairly
>> often. It has happened more than once that, because git svn rebase
>> applies each svn commit sequentially, some of the commits will
>> conflict with each other - whether or not I have ever touched the
>> file.

That sounds like you're "git pull"ing from each other, yes? I can't imagine any other way you'd get conflicts on files you have never touched.

>> Is there anything I could do to get around this without having to
>> merge code I'm unfamiliar with?

If the problem is that git-svn doesn't recognize git-svn commits that have come from others via git-pull, you might be able to get away with "rm -rf .git/svn" to force git-svn to rebuild its index. Git 1.6.1rc or newer doesn't need this workaround, since it has incremental index updating.

If the problem is that others' branches are conflicting with svn checkins, switch back to your own branch so you're only rebasing your own code, ask the person who wrote the other code to fix the conflicts, and re-pull. This assumes a work-flow where you only ever make commits on top of an un-merged state (which you pretty much have to adopt anyway in a rebase-heavy environment such as one based on git-svn).

Peter Harris