All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Robert Dailey <rcdailey.lists@gmail.com>
Cc: Git <git@vger.kernel.org>
Subject: Re: Proposal for pruning tags
Date: Thu, 05 Jun 2014 13:50:58 -0700	[thread overview]
Message-ID: <xmqqoay7rsgd.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAHd499BLX3q2FHLfFpq_14w2mmosywfRqMHVjkke0BRhAAjx7g@mail.gmail.com> (Robert Dailey's message of "Thu, 5 Jun 2014 09:51:47 -0500")

Robert Dailey <rcdailey.lists@gmail.com> writes:

> I've never contributed to the Git project before. I'm a Windows user,
> so I use msysgit, but I'd be happy to install linux just so I can help
> implement this feature if everyone feels it would be useful.
>
> Right now AFAIK, there is no way to prune tags through Git. The way I
> currently do it is like so:
>
> $ git tag -l | xargs git tag -d
> $ git fetch --all

I think you need to explain what you mean by "prune" a lot better
than what you are doing in your message to be understood by others.

After seeing the above two commands, my *guess* of what you want to
do is to remove any of your local tag that is *not* present in the
repository you usually fetch from (aka "origin"), but that directly
contradicts with what you said you wish, i.e.

> This is not only wasteful, but dangerous. I might accidentally delete
> a local tag I haven't pushed yet...

which only shows that your definition of "prune" is different from
"remove what I do not have at 'origin'".

But it does not say *how* that is different.  How should "prune"
behave differently from the two commands above?  How does your
"prune" decide a tag needs to be removed locally when it is not at
your "origin" [*1*]?

There is *nothing* in git that lets you look at a local tag that is
missing from the other side and determine if that is something you
did not want to push (hence it is missing there) of if that is
something you forgot to push (hence it is missing there but you
would rather have pushed if you did not forget).  So you must have
some new mechanism to record and/or infer that distinction in mind,
but it is not clear what it is from your message.

So until that is clarified, there is not much more to say if your
"feature" has any merit---as there is no way to tell what that
"feature" exactly is, at least not yet ;-)


[Footnote]

*1* By the way, removing and then refetching would be a silly way to
    do this kind of thing anyway.  After removing but before you
    have a chance to fetch, your ISP may severe your network
    connection and then what happens?

    Whatever your definition of "prune" is, I would think it would
    be built around "ls-remote --tags" output, to see what tags the
    other repository (or other repositories, by looping over the
    remotes you interact with) have, compare that set with the tags
    you locally have in order to decide which subset of tags you
    locally have to remove.

  reply	other threads:[~2014-06-05 20:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-05 14:51 Proposal for pruning tags Robert Dailey
2014-06-05 20:50 ` Junio C Hamano [this message]
2014-06-06 13:54   ` Robert Dailey
2014-06-06 17:18     ` Junio C Hamano
2014-06-11  9:25 ` Michael Haggerty

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=xmqqoay7rsgd.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=rcdailey.lists@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 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.