git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 2/2] name-rev: favor describing with tags and use committer date to tiebreak

From
Lars Schneider <larsxschneider@gmail.com>
Date
Mar 17, 2017, 04:07 UTC
Message-ID
<9AE7ADCA-97F9-4857-AC55-76C4BD822C25@gmail.com>
In-Reply-To
<20170315225045.15788-3-gitster@pobox.com>
Show 50 quoted lines
> On 16 Mar 2017, at 06:50, Junio C Hamano <gitster@pobox.com> wrote:
> 
> "git name-rev" assigned a phony "far in the future" date to tips of
> refs that are not pointing at tag objects, and favored names based
> on a ref with the oldest date.  This made it almost impossible for
> an unannotated tags and branches to be counted as a viable base,
> which was especially problematic when the command is run with the
> "--tags" option.  If an unannotated tag that points at an ancient
> commit and an annotated tag that points at a much newer commit
> reaches the commit that is being named, the old unannotated tag was
> ignored.
> 
> Update the "taggerdate" field of the rev-name structure, which is
> initialized from the tip of ref, to have the committer date if the
> object at the tip of ref is a commit, not a tag, so that we can
> optionally take it into account when doing "is this name better?"
> comparison logic.
> 
> When "name-rev" is run without the "--tags" option, the general
> expectation is still to name the commit based on a tag if possible,
> but use non-tag refs as fallback, and tiebreak among these non-tag
> refs by favoring names with shorter hops from the tip.  The use of a
> phony "far in the future" date in the original code was an effective
> way to ensure this expectation is held: a non-tag tip gets the same
> "far in the future" timestamp, giving precedence to tags, and among
> non-tag tips, names with shorter hops are preferred over longer
> hops, without taking the "taggerdate" into account.  As we are
> taking over the "taggerdate" field to store the committer date for
> tips with commits:
> 
> (1) keep the original logic when comparing names based on two refs
>     both of which are from refs/tags/;
> 
> (2) favoring a name based on a ref in refs/tags/ hierarchy over
>     a ref outside the hierarchy;
> 
> (3) between two names based on a ref both outside refs/tags/, give
>     precedence to a name with shorter hops and use "taggerdate"
>     only to tie-break.
> 
> A change to t4202 is a natural consequence.  The test creates a
> commit on a branch "side" and points at it with an unannotated tag
> "refs/tags/side-2".  The original code couldn't decide which one to
> favor at all, and gave a name based on a branch (simply because
> refs/heads/side sorts earlier than refs/tags/side-2).  Because the
> updated logic is taught to favor refs in refs/tags/ hierarchy, the
> the test is updated to expect to see tags/side-2 instead.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---

A quick bisect indicates that this patch might break t9807-git-p4-submit.sh 8 and 13. I haven't looked into it further, yet.

https://travis-ci.org/git/git/jobs/211948406#L2152 https://travis-ci.org/git/git/jobs/211948406#L2460

Non-JS: https://s3.amazonaws.com/archive.travis-ci.org/jobs/211948406/log.txt
- Lars
Previous: Junio C HamanoNext: Junio C Hamano
Message 8 of 46 in “describe --contains sanity”
  1. 0/3 describe --contains sanityMichael J Gruber, Mar 15, 2017
  2. 3/3 name-rev: Allow lightweight tags and branch refsMichael J Gruber, Mar 15, 2017
  3. Junio C HamanoMar 15, 2017
  4. Junio C HamanoMar 15, 2017
  5. Junio C HamanoMar 15, 2017
  6. 0/2 Teach name-rev to pay more attention to lightweight tagsJunio C Hamano, Mar 15, 2017
  7. 2/2 name-rev: favor describing with tags and use committer date to tiebreakJunio C Hamano, Mar 15, 2017
  8. Lars SchneiderMar 17, 2017
  9. Junio C HamanoMar 17, 2017
  10. Junio C HamanoMar 17, 2017
  11. Lars SchneiderMar 17, 2017
  12. Junio C HamanoMar 17, 2017
  13. Junio C HamanoMar 17, 2017
  14. 2/3 name-rev: favor describing with tags and use committer date to tiebreakMichael J Gruber, Mar 29, 2017
  15. 0/3 name-rev sanityMichael J Gruber, Mar 29, 2017
  16. Junio C HamanoMar 29, 2017
  17. Junio C HamanoMar 29, 2017
  18. Michael J GruberMar 30, 2017
  19. Junio C HamanoMar 30, 2017
  20. 3/4 name-rev: provide debug outputMichael J Gruber, Mar 31, 2017
  21. Junio C HamanoMar 31, 2017
  22. Junio C HamanoMar 31, 2017
  23. Michael J GruberMar 31, 2017
  24. Junio C HamanoMar 31, 2017
  25. Junio C HamanoMar 31, 2017
  26. Michael J GruberApr 3, 2017
  27. Junio C HamanoApr 3, 2017
  28. Junio C HamanoMay 20, 2017
  29. Junio C HamanoMar 31, 2017
  30. 4/4 describe: pass --debug down to name-revMichael J Gruber, Mar 31, 2017
  31. 0/4 name-rev sanityMichael J Gruber, Mar 31, 2017
  32. 1/4 name-rev: refactor logic to see if a new candidate is a better nameMichael J Gruber, Mar 31, 2017
  33. 2/4 name-rev: favor describing with tags and use committer date to tiebreakMichael J Gruber, Mar 31, 2017
  34. 1/3 name-rev: refactor logic to see if a new candidate is a better nameMichael J Gruber, Mar 29, 2017
  35. 3/3 name-rev: provide debug outputMichael J Gruber, Mar 29, 2017
  36. Michael J GruberMar 17, 2017
  37. Junio C HamanoMar 17, 2017
  38. 1/2 name-rev: refactor logic to see if a new candidate is a better nameJunio C Hamano, Mar 15, 2017
  39. Stefan BellerMar 16, 2017
  40. Jacob KellerMar 16, 2017
  41. 1/3 describe: debug is incompatible with containsMichael J Gruber, Mar 15, 2017
  42. Junio C HamanoMar 15, 2017
  43. Michael J GruberMar 17, 2017
  44. 2/3 git-prompt: add a describe style for any tagsMichael J Gruber, Mar 15, 2017
  45. Junio C HamanoMar 15, 2017
  46. Michael J GruberMar 17, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.