On Fri, May 6, 2016 at 10:13 AM, SZEDER Gábor <szeder@xxxxxxxxxx> wrote: > Quoting Mike Rappazzo <rappazzo@xxxxxxxxx>: >> I'll try to reword this to make it indicate that the value isn't >> always incorrect. > > Not sure I understand your intention about rewording, in particular that > "isn't always incorrect" part. Just to make sure there is no > misunderstanding let's have a look at the two broken cases: > > $ git -C t/ rev-parse --git-common-dir > t/.git > > Obviously wrong. > This is what you correctly described in the commit message as > "incorrectly returns a path which starts 'sub/path/.git'. > > $ git -C t/ rev-parse --git-path objects > .git/objects > > Wrong as well. It would be correct if we were at the top of the working > tree, but we are not. It must be relative to the directory where '-C t/' > brought us. > Your description in the commit message implies that '--git-path <path>' > is wrong in the same way as '--git-common-dir' is, i.e. in this case > would also return the relative path starting with the subdirectory. > That is apparently not the case. > > My point in the previous email was that both are wrong when executed in > a subdir of the working tree, but they are wrong in different ways. And > they are always wrong when executed from a subdir of the working tree. This explanation argues strongly in favor of placing each fix in a separate patch[1] so that each commit message can be tailored to precisely match the problem being fixed. Bundling the corresponding tests with the fix would be a bonus; no need for a lead-in patch introducing the tests en masse, and no need for test_expect_failure. [1]: http://article.gmane.org/gmane.comp.version-control.git/293001/ -- 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