From: Patrick Steinhardt <ps@pks.im>
To: Jeff King <peff@peff.net>
Cc: Justin Tobler via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Justin Tobler <jltobler@gmail.com>
Subject: Re: [PATCH 1/2] t1401: generalize reference locking
Date: Thu, 11 Jan 2024 12:08:44 +0100 [thread overview]
Message-ID: <ZZ_MPK2huH2j6CGd@tanuki> (raw)
In-Reply-To: <20240111071329.GC48154@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 2054 bytes --]
On Thu, Jan 11, 2024 at 02:13:29AM -0500, Jeff King wrote:
> 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).
If all we care for is the exit code then this would work for the
reftable backend, too:
```
$ git init --ref-format=reftable repo
Initialized empty Git repository in /tmp/repo/.git/
$ cd repo/
$ git commit --allow-empty --message message
[main (root-commit) c2512d3] x
$ git symbolic-ref refs/heads refs/heads/foo
$ echo $?
1
```
A bit unfortunate that there is no proper error message in that case,
but that is a different topic.
Patrick
> 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
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-01-11 11:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-10 18:52 [PATCH 0/2] Generalize reference locking in tests Justin Tobler via GitGitGadget
2024-01-10 18:52 ` [PATCH 1/2] t1401: generalize reference locking Justin Tobler via GitGitGadget
2024-01-11 7:13 ` Jeff King
2024-01-11 11:08 ` Patrick Steinhardt [this message]
2024-01-12 7:01 ` Jeff King
2024-01-12 7:45 ` Patrick Steinhardt
2024-01-12 8:03 ` Jeff King
2024-01-11 20:19 ` Justin Tobler
2024-01-10 18:52 ` [PATCH 2/2] t5541: " Justin Tobler via GitGitGadget
2024-01-11 7:28 ` Jeff King
2024-01-11 18:47 ` Junio C Hamano
2024-01-11 20:20 ` Justin Tobler
2024-01-11 0:36 ` [PATCH 0/2] Generalize reference locking in tests Junio C Hamano
2024-01-11 20:20 ` Justin Tobler
2024-01-11 20:24 ` [PATCH v2 " Justin Tobler via GitGitGadget
2024-01-11 20:24 ` [PATCH v2 1/2] t1401: remove lockfile creation Justin Tobler via GitGitGadget
2024-01-11 20:24 ` [PATCH v2 2/2] t5541: " Justin Tobler via GitGitGadget
2024-01-12 7:03 ` Jeff King
2024-01-12 17:58 ` Junio C Hamano
2024-01-13 22:25 ` Justin Tobler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZZ_MPK2huH2j6CGd@tanuki \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=jltobler@gmail.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.