From: Patrick Steinhardt <ps@pks.im>
To: David Sanderson <yelliott@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: git pull --prune --prune-tags yields a usage error In 2.45.0
Date: Tue, 14 May 2024 08:47:56 +0200 [thread overview]
Message-ID: <ZkMJHMtiQWw4qdT2@tanuki> (raw)
In-Reply-To: <CAC-6ESEfnjK1ubrzoAfUsegM55e55uKugCPSfxnBC607dmZJRA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1859 bytes --]
On Mon, May 13, 2024 at 07:11:00PM -0400, David Sanderson wrote:
> I noticed that "git help pull" mentioned the flag --prune-tags in
> conjunction with --prune, but actually supplying this flag to
> "git pull" results in a usage error. For instance, the command
> "git pull --prune --prune-tags" fails with a usage error. I would
> have expected that this would work, since it works with "git fetch".
>
> I could use "git fetch --prune --prune-tags" as I expected, and
> "git help fetch" does describe --prune-tags on its own as well as
> in the help for --prune.
>
> I confirmed that this behavior still exists in git version 2.45.0.
Indeed. The fact that we mention `--prune-tags` in git-pull(1) at all is
a bug because that command never even implemented this option. I could
see us going one of two ways:
- Adapt the documentation so that we stop mentioning `--prune-tags`.
- Implement support for `--prune-tags` in git-pull(1).
I find the value of `--prune-tags` to be rather dubious as it does the
exact same as `git fetch --prune refs/tags/*:refs/tags/*`. I am heavily
biased though as I understand refspecs just fine, which many of our
users may not. But the bigger downside of `--prune-tags` in my opinion
is that it doesn't only prune tags, but also fetches new ones. So the
effect of the option is somewhat counterintuitive.
So with that in mind I'd rather pick option 1 and stop mentioning the
option in git-pull(1). But that's only a preference of myself, not a
strong "no", and am very happy to be convinced otherwise.
So unless somebody does feel strongly that `--prune-tags` should exist
and provides the patches, my proposal would be to remove the mention of
`--prune-tags` from git-pull(1) for now. We can then add it back in if
somebody does implement the option in the future.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2024-05-14 6:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-13 23:11 git pull --prune --prune-tags yields a usage error In 2.45.0 David Sanderson
2024-05-14 6:47 ` Patrick Steinhardt [this message]
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=ZkMJHMtiQWw4qdT2@tanuki \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=yelliott@gmail.com \
/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 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).