Community
Participate
Working Groups
`git describe HEAD` produces output such as v0.11.3-100-gbbcf552. The basic algorithm is to search backwards from HEAD until an annotated tag is found (here v0.11.3), and then counts up the number of commits that are not part of the annotated tag, but are part of HEAD (here 100), then suffixes the whole thing with a unique abbreviation of HEAD (bbcf552). I actually wrote most of the current C Git describe code, so I should be able to port it over fairly quickly... assuming I can find the time to write the Java implementation of it. There are some gotchas with the tag matching logic to prevent a maintenance fix release from causing the revision numbering to jump backwards. I fixed this in C Git as part of: commit 80dbae03b010b1e5c6e0e4f475578d6cadaadecf Author: Shawn O. Pearce <spearce@spearce.org> Date: Wed Jan 10 06:39:47 2007 -0500 Chose better tag names in git-describe after merges.
Koshuke has implemented this, here's the review https://git.eclipse.org/r/#/c/14871/
I am using JGit 3.3.2.201404171909-r from http://download.eclipse.org/egit/updates. Describe is implmented and it seems to work. Example: Git.wrap(repository).describe().setTarget(ObjectId.fromString("hash")).call() Is there a reason this bug is still open? Thanks Max
we missed to close this bug the implementation was merged as f045a68a78f251af836c6b0a18a22a6d9e5f55a0 on Oct 2, 2013
In that case, thanks for the patch! As nobody seems to mind, I'll go ahead and mark this as resolved.
