Re: git-fetch and unannotated tags

Andy Parkins [off-list ref] writes:

quoted

You could even modify git-tag to create them for you with some
appropriate switch ...

Well yes, but that's the answer to everything isn't it?

The answer to everything you want to change the current
behaviour is to code something that implement that change.  What
else is new?

I suspect that if you look at what git-fetch.sh does in the
paragraph that follows /^# automated tag following/, it probably
is not that much change.  At that point,

 (1) $ls_remote_result contains the output from "git ls-remote $URL"
     we ran earlier, LF and everything intact.

 (2) show-ref --exclude-existing=refs/tags/ discards, out of
     $ls_remote_result, everything that does not begin with refs/tags/,
     and at the same time, discards the ones you already have.
     This is done after stripping away ^{} markers.

 (3) The remainder is fed to the while loop, which says "if we
     already have the object pointed at by a surviving ref under
     refs/tags/ in the remote, follow that tag".

So I think you could filter out the ones that do not have
corresponding ^{} in $ls_remote_result from the while loop.  As
the use of "show-ref --exclude-existing" is to speed things up
by reducing the work done in the while loop written in shell, I
would suggest giving another option to show-ref that can be used
together with --exclude-existing.

Take a look at exclude_existing() function in builtin-show-ref.c;
your additional option to the command would say something like:

  - ignore everything that do not begin with match (as we do now
    already);

  - if we do not have the ref we read from the stdin (determined
    with the call to path_list_has_path() there), instead of
    running printf() unconditionally as we do now, make sure we
    have both refs/tags/foo and refs/tags/foo^{} in the input.
    And show only those.