Taylor Blau <me@xxxxxxxxxxxx> writes: > On Mon, Jan 31, 2022 at 05:50:19PM +0000, Han-Wen Nienhuys via GitGitGadget wrote: >> From: Han-Wen Nienhuys <hanwen@xxxxxxxxxx> >> >> The reftable backend doesn't support mere existence of reflogs. > > Perhaps I'm missing something obvious, but this and the previous patch > seem to be conflicting each other. > > My understanding of the previous change is that you wanted a reflog > entry when the REFFILES prerequisite isn't met. But this patch says what > matches my understanding is that reftable and reflogs do not play > together. > > If reflogs do not interact with the reftable backend, then what does > this patch do? One difference between the files and the reftable backend is that with the files backend, you can say "I am not adding any entry yet, but remember that reflog is enabled for this ref, while all other refs reflog is not enabled", and the way to do so is to touch the "$GIT_DIR/logs/refs/heads/frotz" file---this enables reflog for the "frotz" branch, even if core.logAllRefUpdates is not set. Because there is no generic reflog API that says "enable log for this ref", a test that checks this feature with files backend would do "touch .git/refs/heads/frotz". I didn't look at "this patch", but it is understandable if such a test needs to be skipped via REFFILES prerequisite, because the reftable backend lacks this feature.
