All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Kristoffer Haugsbakk <code@khaugsbakk.name>, git@vger.kernel.org
Subject: Re: [PATCH 0/3] tag: keep the message file in case ref transaction fails
Date: Wed, 17 May 2023 09:00:10 -0700	[thread overview]
Message-ID: <xmqqo7mjq779.fsf@gitster.g> (raw)
In-Reply-To: <20230517093214.GA527234@coredump.intra.peff.net> (Jeff King's message of "Wed, 17 May 2023 05:32:14 -0400")

Jeff King <peff@peff.net> writes:

> That said, I'm willing to believe that most users wouldn't figure this
> out on their own, and saving TAG_EDITMSG might be more friendly. But one
> other alternative might be to mention the hash of that tag object, and
> possibly give advice on recovering it.

Hmph, then the advice message would suggest "update-ref"?

Ah, no.  Because the message may be reused to create a tag with
different tagname, which is very likely because one reason for the
refusal to update the ref could be that the name was already taken,
and that would create a mismatch between tagname and refname.

OK, so ...

> It's too bad we do not have "git tag -c" to match "git commit -c", which
> would allow us to say something like:
>
>       A tag object was created, but we failed to update the ref.
>       After correcting any errors, you can recover the original tag
>       message with:
>
>         git tag -c $oid [other options]
>
> (where we'd replace $oid with the hash of the created tag object). The
> best alternatives I could come up with were:
>
>       # this is kind of obscure advice to give somebody, plus
>       # it makes a weird tag if you originally tried to tag "foo/bar"
>       # but then later switch to some other name. The "tag" field
>       # in the object won't match the ref.
>       git update-ref $ref $oid

... I agree that this is not a very good advice to give, and ...

>       # this saves just the message but is horribly complicated
>       git cat-file tag $oid | sed '1,/^$/d' |
>       git tag -F -

... this is a reasonable thing to have in a more user-friendly
feature, like your -c above.

> I dunno. There is a certain elegance to telling the user about what
> progress we _did_ make, but if there isn't an easy way to turn that into
> a retry of their command, it may not be all that useful.

Yeah, I am OK with "leaving TAG_EDITMSG behind" and a future "tag
-c/-C $another" to coexist.

  reply	other threads:[~2023-05-17 16:01 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-14 13:17 [PATCH 0/3] tag: keep the message file in case ref transaction fails Kristoffer Haugsbakk
2023-05-14 13:17 ` [PATCH 1/3] t/t7004-tag: add regression test for existing behavior Kristoffer Haugsbakk
2023-05-15  6:59   ` Junio C Hamano
2023-05-14 13:17 ` [PATCH 2/3] t/t7004-tag: add failing tag message file test Kristoffer Haugsbakk
2023-05-15  7:00   ` Junio C Hamano
2023-05-15 19:56     ` Kristoffer Haugsbakk
2023-05-15  7:02   ` Junio C Hamano
2023-05-14 13:18 ` [PATCH 3/3] tag: keep the message file in case ref transaction fails Kristoffer Haugsbakk
2023-05-15  6:59   ` Junio C Hamano
2023-05-15 20:29 ` [PATCH v2 0/3] " Kristoffer Haugsbakk
2023-05-15 20:29   ` [PATCH v2 1/3] doc: tag: document `TAG_EDITMSG` Kristoffer Haugsbakk
2023-05-15 21:59     ` Junio C Hamano
2023-05-15 20:29   ` [PATCH v2 2/3] t/t7004-tag: add regression test for successful tag creation Kristoffer Haugsbakk
2023-05-15 20:29   ` [PATCH v2 3/3] tag: keep the message file in case ref transaction fails Kristoffer Haugsbakk
2023-05-15 21:50   ` [PATCH v2 0/3] " Junio C Hamano
2023-05-16 17:55 ` [PATCH v3 " Kristoffer Haugsbakk
2023-05-16 17:55   ` [PATCH v3 1/3] doc: tag: document `TAG_EDITMSG` Kristoffer Haugsbakk
2023-05-16 17:55   ` [PATCH v3 2/3] t/t7004-tag: add regression test for successful tag creation Kristoffer Haugsbakk
2023-05-16 17:55   ` [PATCH v3 3/3] tag: keep the message file in case ref transaction fails Kristoffer Haugsbakk
2023-05-16 18:39   ` [PATCH v3 0/3] " Junio C Hamano
2023-05-17  9:32 ` [PATCH " Jeff King
2023-05-17 16:00   ` Junio C Hamano [this message]
2023-05-17 17:37     ` Jeff King
2023-05-17 17:52       ` Eric Sunshine
2023-05-17 18:02         ` Kristoffer Haugsbakk
2023-05-17 19:58   ` Kristoffer Haugsbakk

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=xmqqo7mjq779.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=code@khaugsbakk.name \
    --cc=git@vger.kernel.org \
    --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.