Dmitry Pavlenko wrote: > I've checked that the latest trunk version skips the directory in this case > (much better than making it a file). So I'm not sure if it is possible to > turn > it into directory addition at all. > > Anyway I've created a test for the case. I'm not 100% sure in the expected > output/disk/status of the test but from the first glance it looks ok.
You know what? I think 'patch' should not infer that the item being patched is a directory just because it has no 'file mode' line. I take back what I wrote about the 'file mode' line being 'the right information to use'. Only when it is present, then it is the right information to use. We don't currently have a way to tell 'patch' whether to expect a git-format or Subversion-format or old-fashioned patch. It is supposed to guess based on the input. In this case, the input does not have enough information to say it is meant to be creating a directory. The patch format needs to be augmented to explicitly indicate operations on directories. When a patch does not include a 'mode' line, then as you said a patch command could use heuristics to determine it is a directory in some cases, if child paths appear in the patch. However, I don't want us to spend effort on heuristics, I want us to spend the effort on making an exact (explicit) format. I think the testable bug at this stage is that 'svn diff --git' for a directory modification writes a patch that looks the same as for a file modification. You could write a test for that, but we already know that support for directories in patches (both git-format and svn format) is an enhancement that has not been designed yet. So I suggest we close this issue. Does that make sense? -- - Julian
