Aaron Schrab <aaron@xxxxxxxxxx> writes: > At 17:24 -0700 08 Apr 2013, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: >>> +test_expect_success 'clone using repo with gitfile as a reference' ' >>> + git clone --separate-git-dir=L A M && >>> + git clone --reference=M A N && >> >>What should happen if I pass --reference=M/.git? > > That isn't supported and I wouldn't expect it to work. The > --reference option is documented as taking the location of a > repository as the argument and I wouldn't consider a .git file to be a > repository. I also can't think of a reason that it would be very > useful since it should be simple to just refer to the directory > containing the .git file. But if others disagree, I could be > convinced to add support for that. If M/.git weren't a gitfile that points elsewhere, that request ought to work, no? A gitfile is the moral equilvalent of a symbolic link, meant to help people on platforms and filesystems that lack symbolic links, so in that sense, not supporting the case goes against the whole reason why we have added support for gitfile in the first place, I think. -- 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