Medve Emilian-EMMEDVE1 <Emilian.Medve@xxxxxxxxxxxxx> wrote:
> While playing with git-describe I noticed that the --all option is maybe
> not trying first to find a tag as the man page suggests but it goes
> directly for .git/refs. Here is some output from my git repo clone with
> yesterday's head on the master branch:
>
> $ git-describe aeb59328453cd4f438345ea79ff04c96bccbbbb8
> v1.5.2.2-549-gaeb5932
>
> $ git-describe --all aeb59328453cd4f438345ea79ff04c96bccbbbb8
> heads/master
Yea. Look at what's happening. In the --all case we attach
heads/master into the ->util field of aeb5's struct commit*.
Since no annotated tag (a ref with prio 2) and no lightweight tag
(a ref with prio 1) was found pointing at aeb5 we kept that ->util
field pointing at the heads/master ref (which has prio 0).
The --all and --tags options are about selecting what refs can
appear in that ->util field. That's _all_ they do.
Later in describe() at l.151 we immediately display a ref if there
is one in the ->util field:
150 n = cmit->util;
151 if (n) {
152 printf("%s\n", n->path);
153 return;
154 }
So we're favoring a ref that points directly at a commit over any
other ref. We only search if we don't have a ref pointing directly
at the input commit. Searching is when ranking really gets involved.
> Do you think we want to fix that? If yes, I could look into it and
> submit a patch.
I'm not sure. If we "fixed" this then --all would only ever turn
up a head if no annotated tag exists on the entire history of that
input commit. Because the "fix" would be to actually not return
right away here at l.151, but instead to drop down further into the
slower loop where we traverse through commits, pick our candidates,
rank them, and then pick the highest priorty ref that is also
the closest. The annotated tag would always win over the head.
At which point --all is only ever useful if the repository *never*
had an annotated tag along the input branch. I'm not sure that's
useful as a description for a commit. If no annotated tag exists
the raw commit SHA-1 is probably a better description. Its at
least stable with time. ;-)
In my opinion, git-describe is doing *exactly* what the manual page
says it does. But both the current implementation and the manual
page were last majorly overhauld by me. So take my comments about
the documentation with a grain of salt. ;-)
--
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
