On Thu, May 1, 2008 at 12:48 PM, Jeff King <peff@xxxxxxxx> wrote: > I don't see it. I think the steps are exactly the same as in your > example. Consider: > > 1. You have some files in src/ > 2. All of the files from src/ get moved away > 3. You merge in somebody else's work which adds a file in src/, but > their work is based on a commit which predates 2. > > The question is: if they had seen 2., would they have put the file into > src/, or into the new location? I think the answer depends on the > semantics of the file. If it is semantically an addition to the source > code that got moved, then yes. If it is a _replacement_ for the > source code that got moved, then no. I promised I would shut up, and I apparently didn't. Sorry :) I think this case isn't so hard. Basically, a merge involves three commits; the merge-base, my branch, and your branch. In your example above, we compare the merge-base to the new version; in that case, the new file is in an *existing* directory which definitely corresponds to src/ in #1, because the the new version has never even heard about src/ being deleted. Thus, the file must be intended to be part of the original src/, wherever it may now be. In contrast, if the merge-base already had src/ being renamed, and someone put something into src/, we'd know that they're putting it into a fundamentally different directory than the moved src/. Exactly how you track the "identity" of a directory without breaking things down by individual commit sounds a little complicated, but it feels to me like it should be possible. I suspect this is a generalization of the earlier discussion (a few months ago) that I read in the archive about git's handling of empty directories. Right now git does weird things with directory creation/deletion because directories are not first-class citizens. Anyway, as with the empty directory stuff, if I occasionally have to mkdir/rmdir a couple things and rename a few files after doing a merge, I'm not going to cry too much. It sure beats explicitly tracking renames and then having an oops-I-forgot-to-explicitly-track rename throw a monkey wrench into my merges, which svn has saddled me with lots of times. Have fun, Avery -- 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
