6

I am using git describe as the driver for versioning in my application at build time. It looks roughly like: git describe --always --dirty --match version*

I tag my versions with a pattern like version.1.2.3 and the build figures out the version of the application based off what the last commit that was tagged with something like version.* was. If I haven't tagged a given commit, then the version number ends up something like version.1.14.3-24-ged66bf5, which is based of the most recent tag, how many commits since that tag and the git commit id.

This works really well for me personally, but I'm having a problem with doing builds off of a shallow clone on my CI server.

When using the "shallow clone" option on my git build in jenkins (I'm guessing it's just doing "--depth=1"), my git describe command is no longer doing what I want it to do. My version number just ends up being the commit id - I guess this is because there are no tagged versions in the shallow clone, so the --always parameter for the describe command just ends up spitting out the commit id.

I can deal with this for the moment by not doing a shallow clone.

But I really like driving my versioning off of the git describe - how can I keep using it even with shallow clones? I think what I need to be able to do is specify at the time of the shallow clone, that I want the depth to be "from the tip of the branch back to the latest version that has a tag matching version.*".

Is that a thing I can do with Git?

Shorn
  • 19,077
  • 15
  • 90
  • 168
  • Have you thought of creating a `git alias` that does just that? I'm by no means an expert on creating sophisticated ones, but I know that you can get pretty crazy workflows implemented, by using them. Alternatively use git hooks that listen to your deployment branch (`post-commit-hook`) and do pretty much the same thing. – jhoepken Feb 29 '16 at 10:52
  • 1
    @JensHöpken What would this git alias look like? – Shorn Mar 02 '16 at 00:05

1 Answers1

8

You can't: a shallow clone is missing the tag objects and commits they tag.

More precisely, this depends on the depth of that clone and how far back one must go in history to find appropriate tags. Making your shallow clone with --depth 1000 might suffice, for instance. The precise number depends on how many commits you have between1 the tags you care about.

You are correct that if git provided a "deepen until tagged", that would do the trick, but git doesn't, and worse, deepening a shallow clone does not automatically bring over tags.

(It would be possible to write a script that uses git ls-remote and git fetch --depth to keep deepening a clone until some tagged commit(s) appear, then have the script apply the tags manually, as it were. This probably would only take a few dozen lines of Python or shell code, for instance, depending on how robust you wanted it. But it's not included with git itself.)

1The notion of "between" is a bit iffy in a non-linear graph, but the general idea should be clear enough here, I think.

torek
  • 448,244
  • 59
  • 642
  • 775