Jeff King <peff@xxxxxxxx> writes:
> Here's a 2-patch series to replace the old 3/3 (they go on top of the
> first two cleanups from the previous iteration).
Hrm. As this is probably useful for older maintenance track, I would have
preferred not to see the first one that touches sequencer.c that did not
exist in the 1.7.7.x maintenance track, as the change is purely "cosmetic"
and does not have anything to do with fixing the over-agressive merge.
> [1/2]: teach diffcore-rename to optionally ignore empty content
> [2/2]: merge-recursive: don't detect renames of empty files
>
> Thinking on this more, it is actually a more generic problem than just
> empty files. It is really a problem of having generic placeholder files
> with the same content. So a fully general solution would be something
> like a gitattribute for "don't do renames on this". However, in
> practice, these placeholder files are empty (since any non-empty file is
> likely to actually have different content). So I think just dropping the
> empty files as rename candidates is a pretty good heuristic, and it's
> nice and simple.
I thought that our recommendation for keeping an otherwise empty
directories around was to have .gitignore file with two entries in it,
namely:
.*
*
So these files will be everywhere and without being empty, no?
But I tend to prefer the simplicity of limiting this to empty files
anyway.
> After responding to Jonathan, I'm on the fence about whether diff should
> follow the same heuristic. I left the diff behavior unchanged, but a 3/2
> that turns it off by default would be a trivial one-liner.
I am also torn, but somewhat in favor of avoiding random permutations of
empty files.
I can think of only one situation somebody _could_ argue that detecting
empty-to-empty rename is halfway sensible: when there is only one empty
file that was removed, and one new empty file that was added. Even in
such a case, the user could have done "rm this; >that", and depending on
the nature of these two files, "mv this that" may not have made _any_
sense even if they are both empty, and that is why I said "halfway"
sensible.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html