Junio C Hamano <gitster@xxxxxxxxx> writes: > Jeff King <peff@xxxxxxxx> writes: > >> On Wed, Jan 10, 2024 at 06:52:30PM +0000, Justin Tobler via GitGitGadget wrote: >> >>> From: Justin Tobler <jltobler@xxxxxxxxx> >>> >>> Some tests set up reference locks by directly creating the lockfile. >>> While this works for the files reference backend, reftable reference >>> locks operate differently and are incompatible with this approach. >>> Generalize reference locking by preparing a reference transaction. >> >> As with the first patch, I think we could use d/f conflicts to get the >> same effect. Perhaps something like this: > > Thanks for a great alternative. I agree that avoiding fifo indeed > is a better way to go. For this patch, in the next version, I have also followed Peff's suggestion to create d/f conflicts to trigger an error condition instead of using fifos. Thanks to everyone for the feedback! Justin On Thu, Jan 11, 2024 at 12:48 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Jeff King <peff@xxxxxxxx> writes: > > > On Wed, Jan 10, 2024 at 06:52:30PM +0000, Justin Tobler via GitGitGadget wrote: > > > >> From: Justin Tobler <jltobler@xxxxxxxxx> > >> > >> Some tests set up reference locks by directly creating the lockfile. > >> While this works for the files reference backend, reftable reference > >> locks operate differently and are incompatible with this approach. > >> Generalize reference locking by preparing a reference transaction. > > > > As with the first patch, I think we could use d/f conflicts to get the > > same effect. Perhaps something like this: > > Thanks for a great alternative. I agree that avoiding fifo indeed > is a better way to go.
