From: Junio C Hamano <gitster@pobox.com>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: christian.couder@gmail.com, git@vger.kernel.org, ps@pks.im
Subject: Re: [PATCH v4 3/7] update-ref: add support for 'symref-verify' command
Date: Fri, 26 Apr 2024 15:51:06 -0700 [thread overview]
Message-ID: <xmqq5xw37n6t.fsf@gitster.g> (raw)
In-Reply-To: <20240426152449.228860-4-knayak@gitlab.com> (Karthik Nayak's message of "Fri, 26 Apr 2024 17:24:45 +0200")
Karthik Nayak <karthik.188@gmail.com> writes:
> From: Karthik Nayak <karthik.188@gmail.com>
>
> In the previous commits, we added the required base for adding symref
> commands to the '--stdin' mode provided by 'git-update-ref(1)'. Using
> them, add a new 'symref-verify' command to verify symrefs.
>
> The 'symref-verify' command allows users to verify if a provided <ref>
> contains the provided <old-target> without changing the <ref>. If
> <old-target> is not provided, the command will verify that the <ref>
> doesn't exist. Since we're checking for symbolic refs, this command will
> only work with the 'no-deref' mode. This is because any dereferenced
> symbolic ref will point to an object and not a ref and the regular
> 'verify' command can be used in such situations.
All makes sense, but a naïve reader may find it helpful if you
explained why having "verify" command is a good idea in the first
place ("I can just do 'git symoblic-ref' to read the current value,
and see if it is what I expect"). Presumably the value of "verify"
is that you can have it in a transaction and fail other operations
in the same transaction if the symref moved from what you expected
it to point at?
> Add and use `ref_update_is_null_new_value`, a helper function which is
> used to check if there is a new_value in a reference update. The new
> value could either be a symref target `new_target` or a OID `new_oid`.
> We also add tests to test the command in both the regular stdin mode and
> also with the '-z' flag.
This looks out of place, primarily because the helper function is
*NOT* used in this step. Without any actual user, and with the name
that says only what it checks without hinting why a caller may want
to check the condition it checks, it is hard to guess if it is a
good idea to have such a helper.
"If a ref_update object specifies no new-oid and no new-target, it
is not about updating but just validating" is how the callers are
expected to use it, then instead of is_null_new_value that says
what it checks, something like is_verify_only that says what the
caller may want to use it for would be a more friendly name for
readers and future developers.
> @@ -297,11 +320,47 @@ static void parse_cmd_verify(struct ref_transaction *transaction,
> die("verify %s: extra input: %s", refname, next);
>
> if (ref_transaction_verify(transaction, refname, &old_oid,
> - update_flags, &err))
> + NULL, update_flags, &err))
>
> update_flags = default_flags;
> free(refname);
> strbuf_release(&err);
> }
The only damage by this patch to parse_cmd_verify() is that
ref_transaction_verify() gained another parameter NULL, but with the
default "--diff-algorithm=myers" algorithm, it is very hard to see.
The "--patience" algorithm does a much beter job on this hunk.
And the following function is entirely new.
> +static void parse_cmd_symref_verify(struct ref_transaction *transaction,
> + const char *next, const char *end)
> +{
> + struct strbuf err = STRBUF_INIT;
> + struct object_id old_oid;
> + char *refname, *old_target;
> +
> + if (!(update_flags & REF_NO_DEREF))
> + die("symref-verify: cannot operate with deref mode");
> +
> + refname = parse_refname(&next);
> + if (!refname)
> + die("symref-verify: missing <ref>");
> +
> + /*
> + * old_ref is optional, but we want to differentiate between
> + * a NULL and zero value.
> + */
> + old_target = parse_next_refname(&next);
> + if (!old_target)
> + old_oid = *null_oid();
In many existing code paths, we do not do structure assignment like
this. Instead we do
oidcpy(&old_oid, null_oid());
We can see an existing example in a common context in a hunk for
refs.c in this patch.
> + if (*next != line_termination)
> + die("symref-verify %s: extra input: %s", refname, next);
> +
> + if (ref_transaction_verify(transaction, refname,
> + old_target ? NULL : &old_oid,
> + old_target, update_flags, &err))
> + die("%s", err.buf);
Are static analyzers smart enough to notice that we will not be
using old_oid uninitialized here? Just wondering.
Anyway. This ensures ref_transaction_verify() gets either
old_target or old_oid, but never both at the same time. The caller
to ref_transaction_verify() in the previous function passed NULL for
old_target but it always had a non-NULL old_oid so that is perfectly
fine.
> + update_flags = default_flags;
> + free(refname);
> + free(old_target);
> + strbuf_release(&err);
> +}
> diff --git a/refs.c b/refs.c
> index 060a31616d..0e1013b5ab 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -1217,6 +1217,8 @@ void ref_transaction_free(struct ref_transaction *transaction)
>
> for (i = 0; i < transaction->nr; i++) {
> free(transaction->updates[i]->msg);
> + free((void *)transaction->updates[i]->old_target);
> + free((void *)transaction->updates[i]->new_target);
> free(transaction->updates[i]);
> }
> free(transaction->updates);
> @@ -1247,9 +1249,13 @@ struct ref_update *ref_transaction_add_update(
>
> update->flags = flags;
>
> - if (flags & REF_HAVE_NEW)
> + if (new_target)
> + update->new_target = xstrdup(new_target);
> + if (old_target)
> + update->old_target = xstrdup(old_target);
Presumably "update" structure, when freshly initialized, has NULL in
both of these _target members? Otherwise ref_transaction_free()
would get in trouble, so double checking.
> + if (new_oid && flags & REF_HAVE_NEW)
> oidcpy(&update->new_oid, new_oid);
> - if (flags & REF_HAVE_OLD)
> + if (old_oid && flags & REF_HAVE_OLD)
> oidcpy(&update->old_oid, old_oid);
Since we can ask to work on a symbolic ref, new_oid / old_oid can be
NULL when REF_HAVE_NEW / REF_HAVE_OLD bit is on for _target members.
Makes me wonder if the code becomes easier to follow if the flag
bits are split into four (_NEW -> _NEW_OID + _NEW_TARGET), but let's
not worry about that for now.
> @@ -1286,6 +1292,7 @@ int ref_transaction_update(struct ref_transaction *transaction,
> flags &= REF_TRANSACTION_UPDATE_ALLOWED_FLAGS;
>
> flags |= (new_oid ? REF_HAVE_NEW : 0) | (old_oid ? REF_HAVE_OLD : 0);
> + flags |= (new_target ? REF_HAVE_NEW : 0) | (old_target ? REF_HAVE_OLD : 0);
> @@ -1325,14 +1332,17 @@ int ref_transaction_delete(struct ref_transaction *transaction,
> int ref_transaction_verify(struct ref_transaction *transaction,
> const char *refname,
> const struct object_id *old_oid,
> + const char *old_target,
> unsigned int flags,
> struct strbuf *err)
> {
> - if (!old_oid)
> - BUG("verify called with old_oid set to NULL");
> + if (!old_target && !old_oid)
> + BUG("verify called with old_oid and old_target set to NULL");
Is it normal if you get _both_ set, or is it equally a BUG()?
The parse_*_verify() codepaths we saw earlier both made sure
only one of the two is non-NULL, and it is unclear what should
happen if both are non-NULL.
> + if (old_target && !(flags & REF_NO_DEREF))
> + BUG("verify cannot operate on symrefs with deref mode");
> return ref_transaction_update(transaction, refname,
> NULL, old_oid,
> - NULL, NULL,
> + NULL, old_target,
> flags, NULL, err);
> }
So this queues an ref_update object whose .new_oid and .new_target
are NULL, and .old_oid and .old_target are what the caller gave us
to check. The NULLs in .new* members hopefully do not mean "delete
this thing" ;-)
> @@ -2349,6 +2359,12 @@ static int run_transaction_hook(struct ref_transaction *transaction,
> for (i = 0; i < transaction->nr; i++) {
> struct ref_update *update = transaction->updates[i];
>
> + /*
> + * Skip reference transaction for symbolic refs.
> + */
> + if (update->new_target || update->old_target)
> + continue;
Is that a final design, or will the hooks have a chance to interfere?
> diff --git a/refs/files-backend.c b/refs/files-backend.c
> index 2420dac2aa..53197fa3af 100644
> --- a/refs/files-backend.c
> +++ b/refs/files-backend.c
> @@ -2425,6 +2425,37 @@ static const char *original_update_refname(struct ref_update *update)
> return update->refname;
> }
>
> +/*
> + * Check whether the REF_HAVE_OLD and old_target values stored in
> + * update are consistent with ref, which is the symbolic reference's
> + * current value. If everything is OK, return 0; otherwise, write an
> + * error message to err and return -1.
> + */
> +static int check_old_target(struct ref_update *update, char *ref,
> + struct strbuf *err)
> +{
> + if (!(update->flags & REF_HAVE_OLD) ||
> + !strcmp(update->old_target, ref))
> + return 0;
Earlier on the assignment side for "update" structure we saw above,
the guard was (old_target && flags & REF_HAVE_OLD), but here we
assume old_target is valid, which feels a bit asymmetric.
Yes, I can see that the caller does not call us when !old_target,
but still... Perhaps
if ((update->flags & REF_HAVE_OLD) && !update->old_target)
BUG(...);
or something? Or alternatively, perhaps !!update->old_target should
be the only thing we should check and ignore REF_HAVE_OLD bit? I am
not sure, but it smells like that the non-NULL-ness of old_target is
the only thing that matters (if it is not NULL, very early in the
control flow somebody would have set REF_HAVE_OLD bit to flags, no?).
It brings me back to my earlier question. Does REF_HAVE_OLD bit
serve a useful purpose in this code?
> + if (!strcmp(update->old_target, ""))
> + strbuf_addf(err, "cannot lock ref '%s': "
> + "reference already exists",
> + original_update_refname(update));
> + else if (!strcmp(ref, ""))
> + strbuf_addf(err, "cannot lock ref '%s': "
> + "reference is missing but expected %s",
> + original_update_refname(update),
> + update->old_target);
So... for old_target and ref, an empty string is a special value?
How? Shouldn't that be documented in the comment before the
function?
> + else
> + strbuf_addf(err, "cannot lock ref '%s': "
> + "is at %s but expected %s",
> + original_update_refname(update),
> + ref, update->old_target);
> +
> + return -1;
> +}
> +
> /*
> * Check whether the REF_HAVE_OLD and old_oid values stored in update
> * are consistent with oid, which is the reference's current value. If
> @@ -2528,6 +2559,18 @@ static int lock_ref_for_update(struct files_ref_store *refs,
> ret = TRANSACTION_GENERIC_ERROR;
> goto out;
> }
> + }
> +
> + /*
> + * For symref verification, we need to check the reference value
> + * rather than the oid. If we're dealing with regular refs or we're
> + * verifying a dereferenced symref, we then check the oid.
> + */
> + if (update->old_target) {
> + if (check_old_target(update, referent.buf, err)) {
> + ret = TRANSACTION_GENERIC_ERROR;
> + goto out;
> + }
We come here only when update->type has REF_ISSYMREF bit on (we
learned that value by calling lock_raw_ref()), and know referent.buf
has the current "target" value. That is consumed as "ref" parameter
to check_old_target() we just saw. OK.
> diff --git a/refs/reftable-backend.c b/refs/reftable-backend.c
> index 6104471199..a2474245aa 100644
> --- a/refs/reftable-backend.c
> +++ b/refs/reftable-backend.c
> @@ -938,7 +938,26 @@ static int reftable_be_transaction_prepare(struct ref_store *ref_store,
> * individual refs. But the error messages match what the files
> * backend returns, which keeps our tests happy.
> */
> - if (u->flags & REF_HAVE_OLD && !oideq(¤t_oid, &u->old_oid)) {
> + if ((u->flags & REF_HAVE_OLD) && u->old_target) {
> + if (strcmp(referent.buf, u->old_target)) {
> + if (!strcmp(u->old_target, ""))
> + strbuf_addf(err, "verifying symref target: '%s': "
> + "provided target is empty",
> + original_update_refname(u));
> + else if (!strcmp(referent.buf, ""))
> + strbuf_addf(err, "verifying symref target: '%s': "
> + "reference is missing but expected %s",
> + original_update_refname(u),
> + u->old_target);
> + else
> + strbuf_addf(err, "verifying symref target: '%s': "
> + "is at %s but expected %s",
> + original_update_refname(u),
> + referent.buf, u->old_target);
> + ret = -1;
> + goto done;
> + }
Again, the puzzling "empty string"s are handled here.
next prev parent reply other threads:[~2024-04-26 22:51 UTC|newest]
Thread overview: 192+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-30 22:46 [PATCH 0/8] update-ref: add support for update-symref option Karthik Nayak
2024-03-30 22:46 ` [PATCH 1/8] files-backend: extract out `create_symref_lock` Karthik Nayak
2024-04-02 12:20 ` Patrick Steinhardt
2024-04-03 14:52 ` Karthik Nayak
2024-03-30 22:46 ` [PATCH 2/8] reftable-backend: extract out `write_symref_with_log` Karthik Nayak
2024-04-02 12:20 ` Patrick Steinhardt
2024-03-30 22:46 ` [PATCH 3/8] reftable-backend: move `write_symref_with_log` up Karthik Nayak
2024-03-30 22:46 ` [PATCH 4/8] refs: accept symref in `ref_transaction_add_update` Karthik Nayak
2024-03-30 22:46 ` [PATCH 5/8] refs/files-backend: add support for symref updates Karthik Nayak
2024-04-02 12:20 ` Patrick Steinhardt
2024-03-30 22:46 ` [PATCH 6/8] refs/reftable-backend: " Karthik Nayak
2024-04-02 12:20 ` Patrick Steinhardt
2024-03-30 22:46 ` [PATCH 7/8] refs: add 'update-symref' command to 'update-ref' Karthik Nayak
2024-03-31 22:08 ` Junio C Hamano
2024-03-31 22:27 ` Chris Torek
2024-03-31 23:14 ` Junio C Hamano
2024-04-01 1:31 ` Junio C Hamano
2024-04-02 12:20 ` Patrick Steinhardt
2024-04-02 16:40 ` Junio C Hamano
2024-04-09 11:55 ` Patrick Steinhardt
2024-04-09 16:15 ` Karthik Nayak
2024-04-10 4:20 ` Patrick Steinhardt
2024-04-10 16:06 ` Junio C Hamano
2024-04-10 17:31 ` Patrick Steinhardt
2024-04-01 10:38 ` Karthik Nayak
2024-04-01 11:48 ` Karthik Nayak
2024-04-01 16:17 ` Junio C Hamano
2024-04-01 20:40 ` Junio C Hamano
2024-04-01 22:37 ` Karthik Nayak
2024-03-30 22:46 ` [PATCH 8/8] refs: support symrefs in 'reference-transaction' hook Karthik Nayak
2024-04-02 12:20 ` Patrick Steinhardt
2024-04-12 9:59 ` [PATCH v2 0/7] update-ref: add symref oriented commands Karthik Nayak
2024-04-12 9:59 ` [PATCH v2 1/7] refs: accept symref values in `ref_transaction[_add]_update` Karthik Nayak
2024-04-18 14:25 ` Christian Couder
2024-04-19 10:28 ` Karthik Nayak
2024-04-18 15:08 ` Phillip Wood
2024-04-19 9:40 ` Patrick Steinhardt
2024-04-19 15:47 ` Karthik Nayak
2024-05-04 15:15 ` phillip.wood123
2024-04-19 9:40 ` Patrick Steinhardt
2024-04-19 18:09 ` Karthik Nayak
2024-04-23 6:31 ` Patrick Steinhardt
2024-04-23 10:48 ` Karthik Nayak
2024-04-12 9:59 ` [PATCH v2 2/7] update-ref: add support for symref-verify Karthik Nayak
2024-04-18 14:26 ` Christian Couder
2024-04-19 21:21 ` Karthik Nayak
2024-04-19 9:40 ` Patrick Steinhardt
2024-04-19 21:53 ` Karthik Nayak
2024-04-12 9:59 ` [PATCH v2 3/7] update-ref: add support for symref-delete Karthik Nayak
2024-04-18 14:52 ` Christian Couder
2024-04-21 10:43 ` Karthik Nayak
2024-04-19 9:40 ` Patrick Steinhardt
2024-04-21 10:45 ` Karthik Nayak
2024-04-12 9:59 ` [PATCH v2 4/7] files-backend: extract out `create_symref_lock` Karthik Nayak
2024-04-12 9:59 ` [PATCH v2 5/7] update-ref: add support for symref-create Karthik Nayak
2024-04-19 9:40 ` Patrick Steinhardt
2024-04-19 15:48 ` Junio C Hamano
2024-04-21 12:50 ` Karthik Nayak
2024-04-21 15:57 ` Karthik Nayak
2024-04-23 6:39 ` Patrick Steinhardt
2024-04-23 10:52 ` Karthik Nayak
2024-04-12 9:59 ` [PATCH v2 6/7] update-ref: add support for symref-update Karthik Nayak
2024-04-19 9:40 ` Patrick Steinhardt
2024-04-21 19:00 ` Karthik Nayak
2024-04-23 6:49 ` Patrick Steinhardt
2024-04-23 11:30 ` Karthik Nayak
2024-04-12 9:59 ` [PATCH v2 7/7] refs: support symrefs in 'reference-transaction' hook Karthik Nayak
2024-04-12 18:01 ` [PATCH v2 0/7] update-ref: add symref oriented commands Junio C Hamano
2024-04-12 18:49 ` Karthik Nayak
2024-04-18 15:05 ` Christian Couder
2024-04-21 19:06 ` Karthik Nayak
2024-04-20 6:16 ` Patrick Steinhardt
2024-04-21 19:11 ` Karthik Nayak
2024-04-23 21:28 ` [PATCH v3 0/8] refs: add symref support to 'git-update-ref' Karthik Nayak
2024-04-23 21:28 ` [PATCH v3 1/8] refs: accept symref values in `ref_transaction[_add]_update` Karthik Nayak
2024-04-23 21:28 ` [PATCH v3 2/8] update-ref: support parsing ref targets in `parse_next_oid` Karthik Nayak
2024-04-23 21:28 ` [PATCH v3 3/8] files-backend: extract out `create_symref_lock` Karthik Nayak
2024-04-23 21:28 ` [PATCH v3 4/8] update-ref: support symrefs in the verify command Karthik Nayak
2024-04-23 21:28 ` [PATCH v3 5/8] update-ref: support symrefs in the delete command Karthik Nayak
2024-04-23 21:28 ` [PATCH v3 6/8] update-ref: support symrefs in the create command Karthik Nayak
2024-04-23 21:28 ` [PATCH v3 7/8] update-ref: support symrefs in the update command Karthik Nayak
2024-04-23 21:28 ` [PATCH v3 8/8] ref: support symrefs in 'reference-transaction' hook Karthik Nayak
2024-04-23 22:03 ` [PATCH v3 0/8] refs: add symref support to 'git-update-ref' Jeff King
2024-04-24 1:17 ` Junio C Hamano
2024-04-24 16:25 ` Karthik Nayak
2024-04-25 6:40 ` Patrick Steinhardt
2024-04-25 21:12 ` Karthik Nayak
2024-04-25 18:01 ` Junio C Hamano
2024-04-25 21:14 ` Karthik Nayak
2024-04-25 21:55 ` Junio C Hamano
2024-04-26 12:48 ` Karthik Nayak
2024-04-26 20:41 ` Jeff King
2024-04-25 17:09 ` Junio C Hamano
2024-04-25 21:07 ` Karthik Nayak
2024-04-26 15:24 ` [PATCH v4 0/7] add symref-* commands to 'git-update-ref --stdin' Karthik Nayak
2024-04-26 15:24 ` [PATCH v4 1/7] refs: accept symref values in `ref_transaction[_add]_update` Karthik Nayak
2024-04-26 19:31 ` Junio C Hamano
2024-04-26 21:15 ` Jeff King
2024-04-29 7:02 ` Patrick Steinhardt
2024-04-29 7:55 ` Jeff King
2024-04-29 9:29 ` phillip.wood123
2024-04-29 9:32 ` phillip.wood123
2024-04-29 16:18 ` Junio C Hamano
2024-04-30 10:33 ` Jeff King
2024-04-30 10:30 ` Jeff King
2024-04-28 19:36 ` Karthik Nayak
2024-04-29 13:38 ` Phillip Wood
2024-04-29 14:01 ` Karthik Nayak
2024-04-26 15:24 ` [PATCH v4 2/7] files-backend: extract out `create_symref_lock` Karthik Nayak
2024-04-26 21:39 ` Junio C Hamano
2024-04-28 19:57 ` Karthik Nayak
2024-04-26 15:24 ` [PATCH v4 3/7] update-ref: add support for 'symref-verify' command Karthik Nayak
2024-04-26 22:51 ` Junio C Hamano [this message]
2024-04-28 22:28 ` Karthik Nayak
2024-04-26 15:24 ` [PATCH v4 4/7] update-ref: add support for 'symref-delete' command Karthik Nayak
2024-04-26 15:24 ` [PATCH v4 5/7] update-ref: add support for 'symref-create' command Karthik Nayak
2024-04-26 15:24 ` [PATCH v4 6/7] update-ref: add support for 'symref-update' command Karthik Nayak
2024-04-26 15:24 ` [PATCH v4 7/7] ref: support symrefs in 'reference-transaction' hook Karthik Nayak
2024-04-30 10:14 ` [PATCH v4 0/7] add symref-* commands to 'git-update-ref --stdin' Karthik Nayak
2024-05-01 20:22 ` [PATCH v5 0/7] refs: add support for transactional symref updates Karthik Nayak
2024-05-01 20:22 ` [PATCH v5 1/7] refs: accept symref values in `ref_transaction_update()` Karthik Nayak
2024-05-01 20:22 ` [PATCH v5 2/7] files-backend: extract out `create_symref_lock()` Karthik Nayak
2024-05-01 22:06 ` Junio C Hamano
2024-05-02 7:47 ` Patrick Steinhardt
2024-05-02 11:05 ` Karthik Nayak
2024-05-02 16:49 ` Junio C Hamano
2024-05-01 20:22 ` [PATCH v5 3/7] refs: support symrefs in 'reference-transaction' hook Karthik Nayak
2024-05-01 23:05 ` Junio C Hamano
2024-05-02 5:32 ` Karthik Nayak
2024-05-01 20:22 ` [PATCH v5 4/7] refs: add support for transactional symref updates Karthik Nayak
2024-05-01 23:52 ` Junio C Hamano
2024-05-02 5:50 ` Karthik Nayak
2024-05-02 7:47 ` Patrick Steinhardt
2024-05-02 11:10 ` Karthik Nayak
2024-05-02 16:51 ` Junio C Hamano
2024-05-02 16:00 ` Junio C Hamano
2024-05-02 17:53 ` Junio C Hamano
2024-05-01 20:22 ` [PATCH v5 5/7] refs: use transaction in `refs_create_symref()` Karthik Nayak
2024-05-02 7:47 ` Patrick Steinhardt
2024-05-01 20:22 ` [PATCH v5 6/7] refs: rename `refs_create_symref()` to `refs_update_symref()` Karthik Nayak
2024-05-02 7:47 ` Patrick Steinhardt
2024-05-02 11:34 ` Karthik Nayak
2024-05-01 20:22 ` [PATCH v5 7/7] refs: remove `create_symref` and associated dead code Karthik Nayak
2024-05-02 7:47 ` Patrick Steinhardt
2024-05-02 16:53 ` Junio C Hamano
2024-05-02 0:20 ` [PATCH v5 0/7] refs: add support for transactional symref updates Junio C Hamano
2024-05-02 5:53 ` Karthik Nayak
2024-05-03 12:41 ` [PATCH v6 " Karthik Nayak
2024-05-03 12:41 ` [PATCH v6 1/7] refs: accept symref values in `ref_transaction_update()` Karthik Nayak
2024-05-04 15:18 ` Phillip Wood
2024-05-05 15:10 ` Karthik Nayak
2024-05-05 15:19 ` phillip.wood123
2024-05-03 12:41 ` [PATCH v6 2/7] files-backend: extract out `create_symref_lock()` Karthik Nayak
2024-05-03 12:41 ` [PATCH v6 3/7] refs: support symrefs in 'reference-transaction' hook Karthik Nayak
2024-05-03 12:41 ` [PATCH v6 4/7] refs: add support for transactional symref updates Karthik Nayak
2024-05-05 14:09 ` Phillip Wood
2024-05-05 16:09 ` Karthik Nayak
2024-05-06 9:35 ` Phillip Wood
2024-05-06 11:19 ` Karthik Nayak
2024-05-06 13:19 ` Phillip Wood
2024-05-06 9:54 ` Phillip Wood
2024-05-06 11:22 ` Karthik Nayak
2024-05-06 13:17 ` Phillip Wood
2024-05-03 12:41 ` [PATCH v6 5/7] refs: use transaction in `refs_create_symref()` Karthik Nayak
2024-05-03 12:41 ` [PATCH v6 6/7] refs: rename `refs_create_symref()` to `refs_update_symref()` Karthik Nayak
2024-05-03 12:41 ` [PATCH v6 7/7] refs: remove `create_symref` and associated dead code Karthik Nayak
2024-05-03 23:09 ` Junio C Hamano
2024-05-04 9:30 ` Karthik Nayak
2024-05-03 16:45 ` [PATCH v6 0/7] refs: add support for transactional symref updates Junio C Hamano
2024-05-06 7:36 ` Patrick Steinhardt
2024-05-07 6:00 ` [PATCH v7 0/8] " Karthik Nayak
2024-05-07 6:00 ` [PATCH v7 1/8] refs: accept symref values in `ref_transaction_update()` Karthik Nayak
2024-05-07 6:00 ` [PATCH v7 2/8] files-backend: extract out `create_symref_lock()` Karthik Nayak
2024-05-07 6:00 ` [PATCH v7 3/8] refs: support symrefs in 'reference-transaction' hook Karthik Nayak
2024-05-07 6:00 ` [PATCH v7 4/8] refs: move `original_update_refname` to 'refs.c' Karthik Nayak
2024-05-07 6:00 ` [PATCH v7 5/8] refs: add support for transactional symref updates Karthik Nayak
2024-05-07 6:00 ` [PATCH v7 6/8] refs: use transaction in `refs_create_symref()` Karthik Nayak
2024-05-07 6:00 ` [PATCH v7 7/8] refs: rename `refs_create_symref()` to `refs_update_symref()` Karthik Nayak
2024-05-07 6:00 ` [PATCH v7 8/8] refs: remove `create_symref` and associated dead code Karthik Nayak
2024-05-07 6:25 ` [PATCH v7 0/8] refs: add support for transactional symref updates Junio C Hamano
2024-05-07 6:31 ` Junio C Hamano
2024-05-07 12:58 ` [PATCH v8 " Karthik Nayak
2024-05-07 12:58 ` [PATCH v8 1/8] refs: accept symref values in `ref_transaction_update()` Karthik Nayak
2024-05-07 12:58 ` [PATCH v8 2/8] files-backend: extract out `create_symref_lock()` Karthik Nayak
2024-05-07 12:58 ` [PATCH v8 3/8] refs: support symrefs in 'reference-transaction' hook Karthik Nayak
2024-05-07 12:58 ` [PATCH v8 4/8] refs: move `original_update_refname` to 'refs.c' Karthik Nayak
2024-05-07 12:58 ` [PATCH v8 5/8] refs: add support for transactional symref updates Karthik Nayak
2024-05-07 12:58 ` [PATCH v8 6/8] refs: use transaction in `refs_create_symref()` Karthik Nayak
2024-05-07 12:58 ` [PATCH v8 7/8] refs: rename `refs_create_symref()` to `refs_update_symref()` Karthik Nayak
2024-05-07 12:58 ` [PATCH v8 8/8] refs: remove `create_symref` and associated dead code Karthik Nayak
2024-05-07 15:50 ` [PATCH v8 0/8] refs: add support for transactional symref updates phillip.wood123
2024-05-07 16:32 ` Junio C Hamano
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq5xw37n6t.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=karthik.188@gmail.com \
--cc=ps@pks.im \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).