threads / discuss / 16530

git-svn rebase "problems"

Subject: git-svn rebase "problems"

## tl;dr

4 messages between Dec 1, 2008 and Dec 2, 2008.

replies: 3people: 3as markdown or json

Joe Fiorini· Dec 1, 2008, 03:17 UTC · lore

I'm having some problems with git svn rebase. I'm pretty sure this is just the way git works, not a problem per se. But it's causing trouble for me and my team. My team is currently on Subversion. I'm trying to convince some people that git is a good way to go.

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. Obviously, this is a big problem because if I've never touched the file, then I probably won't know exactly how to resolve the merge (the merge markers haven't been solely reliable).

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

Thanks all! Joe Fiorini -- joe fiorini http://www.faithfulgeek.org // freelancing & knowledge sharing

Joe Fiorini· Dec 2, 2008, 14:56 UTC · re: Joe Fiorini · lore

Re: git-svn rebase "problems"

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

Thanks! Joe

On Sun, Nov 30, 2008 at 10:17 PM, Joe Fiorini <joe@faithfulgeek.org> wrote:

Show 24 quoted lines

> I'm having some problems with git svn rebase. I'm pretty sure this is
> just the way git works, not a problem per se. But it's causing trouble
> for me and my team.
> My team is currently on Subversion. I'm trying to convince some people
> that git is a good way to go.
>
> 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. Obviously, this is a big problem because if I've never touched
> the file, then I probably won't know exactly how to resolve the merge
> (the merge markers haven't been solely reliable).
>
> Is there anything I could do to get around this without having to
> merge code I'm unfamiliar with?
>
> Thanks all!
> Joe Fiorini
> --
> joe fiorini
> http://www.faithfulgeek.org
> // freelancing & knowledge sharing
>

-- 
joe fiorini
http://www.faithfulgeek.org
// freelancing & knowledge sharing

Peter Harris· Dec 2, 2008, 15:21 UTC · re: Joe Fiorini · lore

Re: git-svn rebase "problems"

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

Michael J Gruber· Dec 2, 2008, 15:32 UTC · re: Joe Fiorini · lore

Re: git-svn rebase "problems"

Joe Fiorini venit, vidit, dixit 02.12.2008 15:56:

Show 16 quoted lines

> Are there any other details I can provide to get an answer on this?
> 
> Thanks!
> Joe
> 
> On Sun, Nov 30, 2008 at 10:17 PM, Joe Fiorini <joe@faithfulgeek.org> wrote:
>> I'm having some problems with git svn rebase. I'm pretty sure this is
>> just the way git works, not a problem per se. But it's causing trouble
>> for me and my team.
>> My team is currently on Subversion. I'm trying to convince some people
>> that git is a good way to go.
>>
>> 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

git svn rebase fetches all svn commits and then rebases your current branch onto FETCH_HEAD (the last svn commit). In doing so, it applies the commits you have on your branch (since merge base) one by one. What do you mean by "applies each svn commit sequentially"?

>> file. Obviously, this is a big problem because if I've never touched
>> the file, then I probably won't know exactly how to resolve the merge
>> (the merge markers haven't been solely reliable).

If you develop on a local branch and get conflicts with others' commits someone has to resolve them, whether you use git or svn. But I'm surprised there are conflicts in files you didn't touch. Can you share more details on the files or the workflow/repo?

Michael