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?
If the source repository is shallow, fetch as much as possible so that the current repository has the same history as the source repository. --update-shallow. By default when fetching from a shallow repository, git fetch refuses refs that require updating . git/shallow. This option updates .
Git shallow clone lets you pull down just the latest commits, not the entire repo history. So if your project has years of history, or history from thousands of commits, you can select a particular depth to pull.
Developers should be aware that the depth 1 clone operation only pulls down one branch. If the remote repository contains other branches, they won't be able to check them out locally without a pathspec error. After a git clone depth 1 operation, attempts to checkout an alternate branch will trigger a pathspec error.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With