RE: Re: Unify annotated and non-annotated tags

["Randall S. Becker" <rsbecker@nexbridge.com>]

On November 24, 2017 4:52 AM anatoly techtonik wrote:
>On Thu, Nov 23, 2017 at 6:08 PM, Randall S. Becker <rsbecker@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 <gitster@pobox.com> wrote:
>>>> Igor Djordjevic <igor.d.djordjevic@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)%(objectnam
>>>> e)%(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.

Just pointing out that changing the semantics of a basic data item in git may have unintended consequences.