Andy Parkins <andyparkins@xxxxxxxxx> writes:
>> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html