Patrick Steinhardt <ps@xxxxxx> writes: >> OK, the original checks "if a random garbage file, which may not >> necessarily be a ref, exists at $n_dir, we cannot create a ref at >> $n_dir/fixes, due to D/F conflict" more directly, but as long as our >> intention is to enforce the D/F restriction across different ref >> backends [*], creating a ref at $n_dir and making sure $n_dir/fixes >> cannot be created is an equivalent check that is better (because it >> can be applied for other backends). >> >> Side note: there is no fundamental need to, though, and there >> are cases where being able to have the 'seen' branch and >> 'seen/ps/ref-test-tools' branches at the same time is >> beneficial---packed-refs and ref-table backends would not >> have such an inherent limitation, but they can of course be >> castrated to match what files-backend can(not) do. > > I think initially it is beneficial to keep any such restriction and cut > back new backends to match them, even though it's more work. Note that the same thing can be said for "Can I have Main and main branches?". Loose refs on systems with case-sensitive filesystem are not penalized, though. In any case, I think we are in agreement. >> I trust that this will be corrected to use some wrapper around "git >> symbolic-ref" (or an equivalent for it as a test-tool subcommand) in >> some future patch, if not in this series? > > Yup, this is getting fixed in a subsequent patch. I had two different > options to structure this series: > ... > There were two reasons why I didn't like the first iteration: Yup. I tend to agree with the choice and criteria you made and used here.
