If you have a large number of disparate tags on a large repo you could be an 
O(N*M) search issue, which is proably why the default is what it is.

The --first-parent is proably a good idea, as long as you know that there is a 
first parent tag available - I'm not sure if there is a synthetic {root} tag 
for case when there isn't (see 'git help revisions' ;-).

When in doubt simply use the commit sha1 - it's guaranteed to exist and be 
unique ;-)


  ----- Original Message ----- 
  From: Yves Goergen 
  To: Git for human beings 
  Sent: Monday, December 07, 2015 8:03 PM
  Subject: [git-users] Performance of git describe --candidates

  I'd like to use the 'git describe' command to generate a version string based 
on the most recent version tag, like "v1.2.3". I'm afraid that the default 
value of 10 candidates will prevent proper function most of the time with 
larger number of commits between tags. Is it really such a bad idea to simply 
consider all commits in the repository instead of just 10? Is there a defined 
value for that or should I just specify something as large as 999999?

  Would it be quicker to add the option --first-parent at the same time?

  The tool that generates such version strings should work under all conditions 
and the tag name might not be used in certain configurations, yet it must still 
be determined because it's unknown whether the tag name should be used later. 
So the tool may well run in repositories that don't use tags but have kind of 
many commits. Is it possible to keep this reasonably fast, say under half a 
second, or should I add a switch for collecting tag information first?

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to