From: Karthik Nayak <karthik.188@gmail.com>
To: Junio C Hamano <gitster@pobox.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: Sun, 28 Apr 2024 15:28:41 -0700 [thread overview]
Message-ID: <CAOLa=ZT4yVEuZXmiTVB2tf0qaTPCPn=0TcJRc89knZQWZBbFTg@mail.gmail.com> (raw)
In-Reply-To: <xmqq5xw37n6t.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 14893 bytes --]
Junio C Hamano <gitster@pobox.com> writes:
> 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?
>
I would say none of the commits drive this point, and I would go ahead
and add something on these lines to each of them. I think it would add
good value to readers.
>> 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.
>
I think over the revision, its usage from this commit was removed. It
makes sense to move it to a commit where its used, I'll do that.
> "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.
This is true for the old-oid and old-target. That is, when they are set
to null, we're validating.
With the new-oid and new-target, if they're null, it usually signifies
deletion. We could rename it to 'is_delete_only', but that would also
need checking the 'REF_HAVE_NEW' flag. So we could ideally change it to
```
int ref_update_is_delete_only(struct ref_update *update) {
return (update->flags & REF_HAVE_NEW) && !update->new_target &&
is_null_oid(&update->new_oid);
}
```
I'm okay with making this change.
>> @@ -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.
>
Yeah, makes sense to switch this. Will do.
>> + 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.
Yup, at least the clang LSP server seems to detect and not bug me about
it.
> 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.
>
This is a good point. My understanding was that FLEX_ALLOC_MEM should
set everything to 0.
>> + 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.
>
The intersection of this is quite low currently, so I'm not really sure
if there's added benefit. I did start that way before, but perhaps with
the iterations in the last few version, maybe it makes the code simpler.
>> @@ -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.
>
It is a bug and this is caught in `ref_transaction_add_update`.
Introduced in the first patch of the series.
>> + 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" ;-)
>
So the 'new_oid' being set to zero should be the delete this thing
queue.
>> @@ -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?
>
The last patch adds hook support.
>> 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(...);
>
I will add something like this.
> 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?
>
I checked and it doesn't, it can be removed from usage in this code.
Will cleanup this part.
>> + 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.
For here and above, this too is dead code and no longer needed,
old_target being empty string is left over code from before we decided
to use zero_oid for deleting. I'll remove it. Thanks.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]
next prev parent reply other threads:[~2024-04-28 22:28 UTC|newest]
Thread overview: 194+ 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
2024-04-28 22:28 ` Karthik Nayak [this message]
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
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='CAOLa=ZT4yVEuZXmiTVB2tf0qaTPCPn=0TcJRc89knZQWZBbFTg@mail.gmail.com' \
--to=karthik.188@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.