Parallel refactoring and git merge nightmare

Hello! :)

We are working in parallel on the refactoring of a small project. The team uses SVN and I decided to give GIT a chance to demonstrate it's merging capabilities I've read so much good about :).

However
 - I must be doing something VERY wrong - every time I try to merge from
 the remote svn (git svn fetch and git merge remotebranch) into my 
branch, I get hundreds of conflicts, mostly because of moved folders.

I
 tried it from the console (latest git), from Idea (11.1.1), from git 
extensions, from gitk, from tortoisegit and they all offer me a 
one-by-one resolution of the conflicts, that should have been resolved 
automatically (in Idea and tortoisegit I can select "theirs" to all the 
conflicts, but they still give errors at the end).

I think the 
problem arises because git doesn't track
 moves, therefore I constantly get conflicts of type "local modified, 
remote deleted" (or even both deleted) when in fact it was only modified
 and moved, it could have been merged without conflicts (-> apply my 
changes and move the file to the new location).

Even if I move 
the files manually (eg. from totalcommander) to their final locations (I
 have to copy each modified remote file to the new location ... still 
faster than going through the hundreds of conflicts in git mergetool 
manually, one-by-one), and added the files to the index, I have to hunt 
down the duplicated files, and the ones containing the 
"<<<<<" conflict markers (which often contain the two 
whole files ... not just their differences, even though they are clearly
 very similar), delete the merge file leftovers (theirs, base, local 
etc), copy the files over manually, that could not be merged etc. This 
is madness, I am merging manually!!!

I don't want conflict
 markers in my files, it's dangerous. Don't spam my files with garbage 
(and commit them later, because it was left unnoticed in the whole 
manual merge), use temporary files or whatever.

It would also be nice if conflicts could be ignored, if the match a certain regexp (eg. moving the same .java file in parallel might change the package or import statements, which will result in conflicts ... I don't care, use whichever, Idea will correct it anyway, I don't want to go through hundreds of files because of this). Some hooks could be activated on merge conflicts also.

What am I doing wrong, this manual or 
one-by-one merge is absurd :(? I want git to work because of all the bad
 experience I've had with TFS and SVN, but I just can't comprehend this.

Thank you for your patience, Pap Lőrinc

2012/4/11 Pap Lôrinc <paplorinc@yahoo.com>:

Probably a lot.

2012/4/11 Pap Lôrinc <paplorinc@yahoo.com>:

Google is your friend

https://wiki.kuali.org/display/KULRICE/git-svn+how+to

http://flavio.castelli.name/howto_use_git_with_svn

http://viget.com/extend/effectively-using-git-with-subversion

http://java.dzone.com/articles/how-start-using-git-svn-based

I have no idea why you guys think I'm an idiot. I have read every link I could find (most of the Pro Git book and watched several hours of git video tutorials). The problem is not with GIT-SVN, it's with the GIT merge, more specifically with a simultaneous modify and move, which conflicts probably because it is detected as a modify and delete. Could someone please be a little more friendly, I need advice on how to solve hundreds of git merge conflicts (eg. parallel move and modify, which should have been merged automatically).

Thanks, Lőrinc

2012/4/12 Pap Lôrinc <paplorinc@yahoo.com>:

Could you perhaps show us what commands you have tried, and what the conflicts look like?

Regards,

Andrew Ardill

On Thu, Apr 12, 2012 at 3:23 PM, Pap Lôrinc <paplorinc@yahoo.com> wrote:

Hi Pap,

I think I understand the issue you are facing. I assume that your collaborators are following the practice of one-commit-per-factor-operation. My experience with this has been that synchronizing work best if changes are "bubbled up". I did this by progressively rebasing my branch against each upstream commit. I hope this helps a little.

-- David Barr

Thank you all for the answers! :)

I have already set the rename limit to 0, and upon committing and fetching the renames are calculated and found.

The commands are (I use tortoise git now, but tried the console and other GUIs, as I said in my first post) "git svn fetch" and "git merge remoteBranch". I figured now, that this was the problem, I should have used rebase instead of merge (I still don't understand why merge doesn't work, but rebase and conflict resolution with a GUI (where I can resolve more files at once) seems acceptable). Thanks David! :)

Lőrinc

On Thu, Apr 12, 2012 at 9:52 AM, Pap Lôrinc <paplorinc@yahoo.com> wrote:

As an addition I would recommend to be a little more strict about how refactoring is committed: I.e. split up the repackaging and actual code refactoring - as a rule we are committing renames separately from other changes or with minimal changes (like package change for java classes) Then i would use the rebase if there is some parallel work as suggested above

Hope that helps, Eugene

On Wed, Apr 11, 2012 at 09:13:23AM -0700, Pap Lôrinc wrote:

Git does rename detection at the time of merge, and will apply changes to the destination file. I'm not sure why this isn't working for you. Some theories:

  1. Git may give up on finding renames if it is very computationally
     expensive. It will print a warning in that case, but you may miss
     it in the output. You might try:

        git config merge.renamelimit 0

     to turn off the limiting.

  2. Do your files actually look like renames? Git's inexact rename
     detection looks at the file content, and correlates removed and
     added files that have a high percentage of similar content. If most
     of the file ended up changed, then the pair is not considered a
     rename.

-Peff