On November 24, 2017 4:52 AM anatoly techtonik 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)%(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.
