From: "Carsten Fuchs" <carsten.fu...@cafu.de>
Sent: Monday, January 07, 2013 9:21 AM
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
So I'm thinking that it would be useful to have a merge commit, if
before the two flag day change commits, and then adjust the level of
(--rename-threshold) on the subsequent merge. (can't remember the
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
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
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
Between the two you will then have easy rename detection and easy
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