Jeff King <peff@xxxxxxxx> writes: > But could we instead pull this check to just before the write-out time? > That is, to let any horrible thing happen in-core, as long as what we > write out to the index and the filesystem is sane? The check in-core is somewhat tricky, because we would need to (1) catch a patch that creates a symlink and also a file as if that new symlink is a directory and (2) allow a patch that removes a symlink and also a file in a new directory at the location removed symlink used to occupy. For (1) we need to see if there is a patch in the entire input that creates a symbolic link and reject the input. For (2) we need to see if there is a patch that removes the symbolic link. (1) cannot be caught with the approach based on fn_table[], which is inherently meant to help incremental application, that is oblivious to a path that will materialize after applying a later patch in the input. Let me think about it a bit more. The fix probably needs to abandon depending on fn_table[] stuff, if we want to do in the "sanity check the input and compute the final state all in-core" route. -- 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