Yves,
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.
Philip
[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: [email protected]
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.
Philip
From:
...
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
