Jeff King <peff@xxxxxxxx> writes: > It looks like you re-create this situation in a backend-agnostic way by > having two simultaneous updates that conflict on the lock (but don't > care how that lock is implemented). > > That works, but I think we could keep it simple. This test doesn't care > about the exact error condition we create. The point was just to die in > create_symref() and make sure the exit code was propagated. As you mentioned, the original intent was to recreate the same error condition in a reference backend agnostic manner. Since the test doesn't care about the exact error condition being used, I agree that creating a d/f conflict instead is a much simpler and better approach. In the next patch version I've updated the test in t1401 to use git-symbolic-ref(1) to produce a d/f error. Thanks, Justin On Thu, Jan 11, 2024 at 1:13 AM Jeff King <peff@xxxxxxxx> wrote: > > On Wed, Jan 10, 2024 at 06:52:29PM +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. > > Refactor the test to use git-update-ref(1) to lock refs instead so that > > the test does not need to be aware of how the ref backend locks refs. > > It looks like you re-create this situation in a backend-agnostic way by > having two simultaneous updates that conflict on the lock (but don't > care how that lock is implemented). > > That works, but I think we could keep it simple. This test doesn't care > about the exact error condition we create. The point was just to die in > create_symref() and make sure the exit code was propagated. So something > like this would work: > > $ git symbolic-ref refs/heads refs/heads/foo > error: unable to write symref for refs/heads: Is a directory > > (note that you get a different error message if the refs are packed, > since there we can notice the d/f conflict manually). > > There may be other ways to stimulate a failure. I thought "symbolic-ref > HEAD refs/heads/.invalid" might work, but sadly the refname format check > happens earlier. > > I think it is worth avoiding the fifo magic if we can. It's complicated, > and it means that not all platforms run the test. > > -Peff
