Re: [PATCH] git-submodule: Instead of using only annotated tags, use any tag found in .git/refs/tags

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jun 28, 2007, 05:27 UTC
Message-ID: <20070628052754.GJ32223@spearce.org>
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E27011CFD8F@az33exm24.fsl.freescale.net>

Medve Emilian-EMMEDVE1 <Emilian.Medve@freescale.com> wrote:

Show 10 quoted lines

> 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.