under normal conditions, you should have no real issue, however if you have 
'lots' of tags, or want to compare to some tag in the depths of history, then 
it's time for a closer reading of the man page options.

A 'DAG' is a 'Directed Acyclic Graph', which in the real world means that git 
arranges it's commits in a linked 'graph' like structure [1].

So at the base of each graph there is a root commit that nominally points 
backward to 0h{40} [a unique marker for the bottom] [2]. Then each commit 
records the sha1 of its predecessor, and so a 'string of pearls' is created 
which links all the way down to the root (and git can follow that quickly..). 

The tip of the string of pearls is recorded in the branch (ref) name. Because 
they always point backward there can be NO cycles or loops in the graph (hence 
directed = point backwards; and Acyclic = no loops).

At any point (commit) one can start a fresh string of pearls (new commit), with 
it's own ref/branch name - so now we are starting to draw this like a tree, 
with the leaves at the tip of the 'branches (of the flowering oak tree)' each 
getting their own name... and can be drawn like a Graph (hence DAG).

A merge is like tying two strings together in the merge commit, so it records 
its two, or three, or four, (etc.) co-parents in the commit (now the graph 
looks more like a map of one way streets with bisections, extra under and over 
passes..), but its still a DAG.

Finally, a tag, is a moderately special variant of a commit object (i.e. it's a 
tag object, and its the objects that have the sha1 values), which points back 
to a specific commit, and is meant to be immutable (as a social convention and 
matter of trust). The tags are listed in their own area of the refs structure, 
distinct from the branch refs/heads structure, hence they can also be used as a 
way into the commit graph, and compared to the branch graph.

If you have specific tags you are wanting to describe against, then provide 
those on the command line as per the man page, to speed up the search process 
and avoid saturation of the command's search.

Hope this helps and wasn't too simplistic.


[1] the commit graphs are often collogially called trees, but that use is 
distinct from 'tree objects' which hold one level of directory structure of 
what is committed. Blob objects hold the actual contents of files. So we have 
the 4 types: commit, tag, tree and blob objects. 
http://eagain.net/articles/git-for-computer-scientists/ has nice pictures as 
well ;-)
[2] IIRC, a root commit doesn't actually record anything (i.e. missing line) 
for it's parent, but internally the program simply uses the sha1 equivalent of 
null 0h{40}, but that's an implementation detail ;-). 
  ----- Original Message ----- 
  From: Yves Goergen 
  To: Git for human beings 
  Cc: philipoak...@iee.org 
  Sent: Sunday, December 20, 2015 3:31 PM
  Subject: Re: [git-users] Performance of git describe --candidates

  Okay, that must have been a misunderstanding. I don't know what DAG is. Do I 
still need to worry that with default options, under any realistic 
circumstances the command may not find the most recent tag?

  Am Dienstag, 8. Dezember 2015 21:51:31 UTC+1 schrieb Philip Oakley:
    I may have mis-read the question…

    If the question is to say that the ’10 candidates’ is too few because you 
think that it is ‘COMMIT candidates’, then that would be a misreading of the 
man page. 

    It is the number of candidate TAGS that is being limited for the DAG 
graph’s depth comparison. The depth value can be as large as you like (i.e. as 
large as is needed given the history graph), as long as there is a tag to act 
as the base for the description.

    The other thing is to also add the “--always" option so that even if there 
isn’t a suitable tag you still at least get an answer (with the minimal sha1 of 
the commit (rev/branch) being described.




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