From: "anatoly techtonik" <techto...@gmail.com>
comment at end - Philip
On Fri, Nov 24, 2017 at 1:24 PM, Ævar Arnfjörð Bjarmason
<ava...@gmail.com> wrote:
On Fri, Nov 24, 2017 at 10:52 AM, anatoly techtonik <techto...@gmail.com>
wrote:
On Thu, Nov 23, 2017 at 6:08 PM, Randall S. Becker
<rsbec...@nexbridge.com> wrote:
On 2017-11-23 02:31 (GMT-05:00) anatoly techtonik wrote
Subject: Re: Unify annotated and non-annotated tags
On Sat, Nov 11, 2017 at 5:06 AM, Junio C Hamano <gits...@pobox.com>
wrote:
Igor Djordjevic <igor.d.djordje...@gmail.com> writes:
If you would like to mimic output of "git show-ref", repeating
commits for each tag pointing to it and showing full tag name as
well, you could do something like this, for example:
for tag in $(git for-each-ref --format="%(refname)" refs/tags)
do
printf '%s %s\n' "$(git rev-parse $tag^0)" "$tag"
done
Hope that helps a bit.
If you use for-each-ref's --format option, you could do something
like (pardon a long line):
git
for-each-ref --format='%(if)%(*objectname)%(then)%(*objectname)%(else)%(objectname)%(end)
%(refname)' refs/tags
without any loop, I would think.
Thanks. That helps.
So my proposal is to get rid of non-annotated tags, so to get all
tags with commits that they point to, one would use:
git for-each-ref --format='%(*objectname) %(refname)' refs/tags>
For so-called non-annotated tags just leave the message empty.
I don't see why anyone would need non-annotated tags though.
I have seen non-annotated tags used in automations (not necessarily well
written ones) that create tags as a record of automation activity. I am
not sure we should be writing off the concept of unannotated tags
entirely. This may cause breakage based on existing expectations of how
tags work at present. My take is that tags should include whodunnit,
even if it's just the version of the automation being used, but I don't
always get to have my wishes fulfilled. In essence, whatever behaviour a
non-annotated tag has now may need to be emulated in future even if
reconciliation happens. An option to preserve empty tag compatibility
with pre-2.16 behaviour, perhaps? Sadly, I cannot supply examples of
this usage based on a human memory page-fault and NDAs.
Are there any windows for backward compatibility breaks, or git is
doomed to preserve it forever?
Automation without support won't survive for long, and people who rely
on that, like Chromium team, usually hard set the version used.
Git is not doomed to preserve anything forever. We've gradually broken
backwards compatibility for a few core things like these.
However, just as a bystander reading this thread I haven't seen any
compelling reason for why these should be removed. You initially had
questions about how to extract info about them, which you got answers
to.
So what reasons remain for why they need to be removed?
To reduce complexity and prior knowledge when dealing with Git tags.
For example, http://readthedocs.io/ site contains a lot of broken
"Edit on GitHub" links, for example -
http://git-memo.readthedocs.io/en/stable/
And it appeared that the reason for that is discrepancy between git
annotated and non-annotated tags. The pull request that fixes the issue
after it was researched and understood is simple
https://github.com/rtfd/readthedocs.org/pull/3302
However, while looking through linked issues and PRs, one can try to
imagine how many days it took for people to come up with the solution,
which came from this thread.
--
anatoly t.
So if I understand correctly, the hope is that `git show-ref --tags` could
get an alternate option `--all-tags` [proper option name required...] such
that the user would not have to develop the rather over the complicated
expression that used a newish capability of a different command.
Would that be right?
Or at least update the man page docs to clarify the annotated vs
non-annotated tags issue (many SO questions!).
And indicate if the --dereference and/or --hash options would do the
trick! - maybe the "^{}" appended would be part of the problem (and need
that new option "--objectreference" ).
Philip
