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.
On Wednesday 2007 April 25, Junio C Hamano wrote:
quoted
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?
Apologies - I wasn't saying that someone else should add features I want, I
was saying that locally changing /my/ git-tag isn't very useful. I already
get by with git, so when I post suggestions to the mailing list it's usually
with respect to the wider context. In this case, patching git-tag to create
refs/andys-private-tags/ doesn't seem like the right thing to do in mainline
git :-)
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,
... snip ...
That advice on the other hand is excellent.
Is this something that others would be in favour of? I'm soliciting for
reasons why unannotated tags should be auto-followed?
Take a look at exclude_existing() function in builtin-show-ref.c;
your additional option to the command would say something like:
I'd be arguing for making not following unannotated tags the default, and then
supply a switch to make them followed. Is that too painful? I think that's
in keeping with the tradition that unannotated tags are, typically, not
wanted in a central repository - the default update hook prevents it for
example.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
Andy Parkins wrote:
I'd be arguing for making not following unannotated tags the default, and then
supply a switch to make them followed. Is that too painful? I think that's
in keeping with the tradition that unannotated tags are, typically, not
wanted in a central repository - the default update hook prevents it for
example.
Yup. I share your feelings about simple tags. However, unless the repo owner
has decided to explicitly push the simple tag to the repo, or fscked up by
doing "git push --all" when he had cruft in his own repo, those tags are
in fact part of the repo.
In the "oops" case, I'd point this out to the owner so he/she can delete them
from the central repo (and enable the update-hook that barfs when simple tags
are pushed). If the owner actually wants the tags there, then they're
obviously important for some reason, so keeping them might make sense.
If anything, I'd be more interested in teaching git how to clean up simple
tags. That fix is useful on a wider basis and the "simple vs annotated"
recognition code can be useful for skipping unannotated tags when doing
"git push --all --not-simple" (or some such).
I have no idea where to put it though, as I haven't followed git development
very closely as of late.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Andreas Ericsson wrote:
Andy Parkins wrote:
quoted
I'd be arguing for making not following unannotated tags the default, and then
supply a switch to make them followed. Is that too painful? I think that's
in keeping with the tradition that unannotated tags are, typically, not
wanted in a central repository - the default update hook prevents it for
example.
Yup. I share your feelings about simple tags. However, unless the repo owner
has decided to explicitly push the simple tag to the repo, or fscked up by
doing "git push --all" when he had cruft in his own repo, those tags are
in fact part of the repo.
In the "oops" case, I'd point this out to the owner so he/she can delete them
from the central repo (and enable the update-hook that barfs when simple tags
are pushed). If the owner actually wants the tags there, then they're
obviously important for some reason, so keeping them might make sense.
You can delete branch (ref?) using "<branch>:" refspec, if server you push to
has git new enough. HTH.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git