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: 195+ 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
2024-05-12 17:17 ` Karthik Nayak
2024-05-13 17:15 ` Junio C Hamano
[not found] <https://lore.kernel.org/r/20240530120940.456817-1-knayak@gitlab.com>
2024-06-05 10:29 ` [PATCH v4 3/7] update-ref: add support for 'symref-verify' command Karthik Nayak
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=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.
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.