Re: [PATCH 1/2] t1401: generalize reference locking

From: Justin Tobler <jltobler@gmail.com>
Date: Jan 11, 2024, 20:19 UTC
Message-ID: <CAGAWz+6MEbxeWyPk5aw7jfEve0tYjvfPRXpDCqsw6pe-nGFPjA@mail.gmail.com>
In-Reply-To: <20240111071329.GC48154@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 7 quoted lines

> 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@peff.net> wrote:

Show 34 quoted lines

>
> On Wed, Jan 10, 2024 at 06:52:29PM +0000, Justin Tobler via GitGitGadget wrote:
>
> > From: Justin Tobler <jltobler@gmail.com>
> >
> > 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