Re: [git-users] Re: Problem with moving everything into a subdirectory; merge conflicts

2013-01-07 Thread Philip Oakley

From: "Carsten Fuchs" 
Sent: Monday, January 07, 2013 9:21 AM

Hi Philip,

Am 2013-01-06 18:21, schrieb Philip Oakley:
Your issue [my mistake] is that the (gits's) merge process is a three 
way merge, so you
have the two commits F and N to merge, but git will also locate the 
merge-base at M
(which has the old directory structure), and compares the diffs 
between them [M-F] and
[M-N] (AFAIKI), so you will get these hundreds (thousands) of renames 
on that basis, and

a great difficulty in (git) trying to decide what to do.


Thank you very much for that explanation, it helps me a lot with 
understanding this!


So I'm thinking that it would be useful to have a merge commit, if 
possible, immediately
before the two flag day change commits, and then adjust the level of 
rename detection
(--rename-threshold) on the subsequent merge. (can't remember the 
default threshold)


I had this (a helper merge commit), indeed not strictly immediately 
before the flag day change commit, but close enough so that I should 
have recognized if the affected files from the few intermediate 
commits (between the last merge commit and D) were involved in or 
responsible for the conflicts.


However, it rather looked as if a main source of trouble were a large 
number of index.html "sentinel" files: As they all have the exact same 
contents, it seemed that the rename detection started to associate 
files at completely different, unrelated paths with each other.


They do sound like they would give some hassle to rename detection!



Also you could simply try an Ours/Theirs strategy (as appropriate) 
which would stop git
trying to do more than it needs to, given that you will already have 
carefully made the
two tree 'compatible' ;-) which will establish a new merge base for 
future merges.


Ah!!  :-)

I really should have thought of trying this myself. Using
git merge -s ours master
worked quickly and without any problems, and created the new merge 
commit G just as expected.


However, I'm unsure if this is the proper solution:
Of course, logically I expected that commits F and G have the same 
tree (as G's only purpose is to serve as a new merge basis), even if G 
was created with the default merge strategy. The "ours" strategy does 
exactly that (refer to same tree in G) quasi on the direct route, per 
definition.


But I wonder if this argument is enough?


There are two separate issues, one is to create a merge-base (any base) 
with the new layout (i.e. structure effects), and the second is to 
ensure you have the right (good-enough) basis (i.e. content) in your 
merge.


Between the two you will then have easy rename detection and easy 
content merging.


Normally structure variations are small, so the normal rename detection 
heuristic is OK, but in your case that promise wasn't kept.


That is, do I understand correctly that if I had used the default 
merge strategy, and somehow solved all the conflicts (so that none of 
the files had been changed from F), the result would have technically 
been exactly the same?


Obviously/hopefully your solution to any conflicts would have ended up 
being an "ours" choice anyway... Given that you already had a recent 
merge before the restructuring I would expect that it would be exactl;y 
the same!




Best regards,
Carsten


--




Re: [git-users] Re: Problem with moving everything into a subdirectory; merge conflicts

2013-01-06 Thread Philip Oakley

Aha, I think I see it now...

Your issue [my mistake] is that the (gits's) merge process is a three 
way merge, so you have the two commits F and N to merge, but git will 
also locate the merge-base at M (which has the old directory structure), 
and compares the diffs between them [M-F] and [M-N] (AFAIKI), so you 
will get these hundreds (thousands) of renames on that basis, and a 
great difficulty in (git) trying to decide what to do.


So I'm thinking that it would be useful to have a merge commit, if 
possible, immediately before the two flag day change commits, and then 
adjust the level of rename detection (--rename-threshold) on the 
subsequent merge. (can't remember the default threshold)


Also you could simply try an Ours/Theirs strategy (as appropriate) which 
would stop git trying to do more than it needs to, given that you will 
already have carefully made the two tree 'compatible' ;-) which will 
establish a new merge base for future merges.


Philip

- Original Message - 
From: "Carsten Fuchs" 

To: 
Sent: Sunday, January 06, 2013 3:05 PM
Subject: [git-users] Re: Problem with moving everything into a 
subdirectory; merge conflicts





Hi Philip,

Am 2013-01-06 14:59, schrieb Philip Oakley:
Surley (?) the simplest method, given your limited number of branches, 
is to capture and
repeat the moves as a script once for each branch, so that each branch 
has a flag day

commit. Then the development merging should proceed just fine.

At least then the file rename machinery has much less to worry about 
for any (real)
conflicts that may happen. It will normally show the file renames just 
in case..


Thanks for your reply! Repeating the move commands for each branch and a 
flag day commit
for each is what I tried already: see the second attempt in my original 
mail, commits F

and N, which I tried to merge into G.

I just tried this again in order to capture the full error messages it 
provides:


Being on branch "develop" at commit F, running "git merge master" yields 
two types of

error messages:

CONFLICT (rename/delete): www/wiki/inc/lang/en/lang.php deleted in 
HEAD and renamed in master. Version master of 
www/wiki/inc/lang/en/lang.php left in tree.


I believe this is for all those that I have modified in "develop". 
However (as all I did
was moving things into www/ ), I don't seem to understand what this 
message means, much

less how to fix it.

CONFLICT (rename/rename): Rename 
"xmlrpc/includes/index.html"->"www/plugins/system/legacy/index.html" 
in branch "HEAD" rename 
"xmlrpc/includes/index.html"->"www/xmlrpc/includes/index.html" in 
"master"


And this occurs apparently for *every* other file (even though the 
mentioned file is
100% identical, same SHA-1, in both branches). In this case, I 
understand even less what

the problem is and how to fix it.

After about 2000 of these messages, the merge aborts with:


warning: inexact rename detection was skipped due to too many files.
warning: you may want to set your merge.renamelimit variable to at 
least 8288 and retry the command.

Automatic merge failed; fix conflicts and then commit the result.


So I did this:

git config merge.renameLimit 3
git merge --abort
git merge master

but while the messages are slightly different now, the result is 
essentially the same,

still hundreds of messages like:

CONFLICT (rename/rename): Rename 
"xmlrpc/includes/index.html"->"www/plugins/system/legacy/index.html" 
in branch "HEAD" rename 
"xmlrpc/includes/index.html"->"www/xmlrpc/includes/index.html" in 
"master"
CONFLICT (rename/delete): www/forum/images/smilies/icon_question.gif 
deleted in HEAD and renamed in master. Version master of 
www/forum/images/smilies/icon_question.gif left in tree.

# [...], then after the last:
Automatic merge failed; fix conflicts and then commit the result.


So the question still stands...

Best regards,
Carsten




- Original Message - From: "Carsten Fuchs"

To: 
Sent: Sunday, January 06, 2013 12:43 PM
Subject: [git-users] Problem with moving everything into a 
subdirectory; merge conflicts


[...]
So I deleted E again (reset "develop" back to D), repeated the above 
move-and-commit
commands at D in order to mimic things in the "develop" branch, 
obtaining F, and *then*

tried to merge "master" into "develop" to obtain G:


o---o---o---...---o---o---D ---F ---G   <-- develop
   /   / / /
  o---o---o---o---...---M ---N ---ยด <-- master


To my surprise, this caused conflicts for quasi every of the affected 
11000 files as
well. Unfortunately I didn't keep a copy of the exact messages, but 
essentially the
reported conflict was that the file has been renamed on one side, and 
has been renamed

on the other side as well.


What can we do?

Best regards,
Carsten




--
   Cafu - the open-source Game and Graphics Engine
for multiplayer, cross-platform, real-time 3D Action
  Learn more at http://www.cafu.de

--




-
No virus found in th