Hi Jonathan, On Fri, 8 Dec 2017, Jonathan Nieder wrote: > Johannes Schindelin wrote: > > > In particular when local tags are used (or tags that are pushed to some > > fork) to build Git, it is very hard to figure out from which particular > > revision a particular Git executable was built. > > Hm, can you say more about how this comes up in practice? I recently saw a version string on this here list (in a generated patch) that looked something like "git v2.14.0.chrome". I sometimes build custom Git for Windows snapshots from commits that I keep in my own fork. I would expect other people to do the same. With this patch, at least I can verify very easily whether I have access to the corresponding commit or not. > I wonder if we should always augment the version string with the commit > hash. That would probably be more confusing than helpful to the end-users. > E.g. I am running > > git version 2.15.1.424.g9478a66081 which is currently good enough, but in the future may clash with another object, maybe even a commit. Unabbreviated commit names are what I am after. > > We need to be careful, though, to report when the current commit cannot be > > determined, e.g. when building from a tarball without any associated Git > > repository. > > This means that on Debian, it would always print > > built from commit: (unknown) > > Maybe I shouldn't care, but I wonder if there's a way to improve on > that. E.g. should there be a makefile knob to allow Debian to specify > what to put there? I changed the text to "no commit associated with this build". Does that suffice? If not, what "UI" would you suggest (most likely a new Makefile variable? What name would you prefer?). Ciao, Dscho
