On Sun, Jul 23, 2017 at 12:23 PM, Stas Sergeev <stsp@xxxxxxx> wrote: > 23.07.2017 11:40, Jacob Keller пишет: >> >> On Fri, Jul 21, 2017 at 12:03 PM, Stas Sergeev <stsp@xxxxxxx> wrote: >>> >>> I wanted some kind of file to use it as a >>> build dependency for the files that needs >>> to be re-built when the head changes. >>> This works very well besides git gc. >>> What other method can be used as simply >>> as that? git show-ref does not seem to be >>> giving this. >> >> There's no real way to do this, and even prior to 2007 when the file >> always existed, there's no guarantee it's modification time is valid. >> >> I'd suggest you have a phony rule which you always run, that checks >> the ref, and sees if it's different from "last time" and then updates >> a different file if that's the case. Then the build can depend on the >> generated file, and you'd be able to figure it out. > > OK, thanks, that looks quite simple too. > I will have to create the file by hands that > I expected git to already have, but it appears > not. > >> What's the real goal for depending on when the ref changes? > > So that when users fill in the bug report, I can > see at what revision have the bug happened. :) > While seemingly "just a debugging sugar", the > hard experience shows this to be exceptionally > useful. > I think even linux kernel does something like > this, and solves that task the hard way. For > example I can see a script at scripts/setlocalversion > whose output seems to go to > include/config/kernel.release and a lot of > logic in the toplevel makefile about this. > So not liking the fact that every project solves > this differently, I was trying to get the solution > directly from git. But I'll try otherwise. generally, I'd suggest using "git describe" to output a version based on tag, and as part of your build system set that in some sort of --version output of some kind. Thanks, Jake
