On Tue, Jul 7, 2020 at 5:20 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > >> The reason why I asked what this patch thinks the definition of > >> pseudoref is is because of this thing. Shouldn't this line be fixed > >> not to depend on the files backend? Likewise for $(cat .git/PSEUDOREF) > >> in the remaining two hunks. > > > > This patch doesn't introduce reftable yet, so both definitions are > > equivalent for the sake of this patch. > > But at the end of the tunnel, we do want to see people stop > expecting that .git/PSEUDOREF file is what PSEUDOREF ref is, no? I > think that is what "pseudo refs are not just files directly under > $GIT_DIR, but managed by the backend" means, and that in turn is a > valid justification for other changes introduced in this patch. > Expecting the effect of modifying pseudo refs _after_ the code is > changed that such modifications are properly done through the ref > API to appear on the filesystem feels like it goes against the > reason why we are making this change, compared to checking to see if > the pseudoref really got updated as desired via the ref API, at > least to me. I can fix this specific instance here (which is what I think you want), for this commit to practice what it preaches. At the same time there are probably about 100 or so other places where the tests check the file system directly for ref(log) existence, so it would never be totally consistent. The only way to systematically find the offending places is to introduce a new ref backend and then fix all the tests, and I think that goes outside the scope of this small series. -- Han-Wen Nienhuys - Google Munich I work 80%. Don't expect answers from me on Fridays. -- Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
