From: Mikko Rapeli <hidden> Date: 2016-06-15 22:47:08
How do I embed a hash, tag or branch name into source code managed by
git?
I've tried searching the net, git manuals etc but haven't found a
replacement for the old '$Id: $' strings from svn. What I need is a way to
map compiled binaries and flash images to git tree heads, tags and
branches.
Thanks,
-Mikko
From: Jakub Narebski <hidden> Date: 2016-06-15 22:47:08
Mikko Rapeli [off-list ref] writes:
How do I embed a hash, tag or branch name into source code managed by
git?
I've tried searching the net, git manuals etc but haven't found a
replacement for the old '$Id: $' strings from svn. What I need is a way to
map compiled binaries and flash images to git tree heads, tags and
branches.
You can embed SHA-1 of a _file contents_ (blob) using '$Id: $' keyword
with `ident` attribute - see gitattributes manpage.
The correct solution of embedding version number is to do it at
_build time_, using e.g. script similar to GIT-VERSION-GEN used by
Git itself and by Linux kernel. It helps if you tag your releases.
If you really, really, really need it, you can embed tag or branch
name into source code using `filter` attribute and custom clean/smudge
filters to do keyword un-expansion and keyword expansion. But please
think twice about what you want to achive with keyword expansion, and
whether keyword expansion is a best solution...
--
Jakub Narebski
Poland
ShadeHawk on #git
From: Mikko Rapeli <hidden> Date: 2016-06-15 22:47:08
On Fri, Jul 31, 2009 at 02:27:50AM -0700, Jakub Narebski wrote:
You can embed SHA-1 of a _file contents_ (blob) using '$Id: $' keyword
with `ident` attribute - see gitattributes manpage.
Great, thanks!
The correct solution of embedding version number is to do it at
_build time_, using e.g. script similar to GIT-VERSION-GEN used by
Git itself and by Linux kernel. It helps if you tag your releases.
This would help, but I'm on cygwin/msysgit and compiling with a
microcontroller IDE MPLAB and PICC-18 compiler, so I really don't
want to dig deeper into build time integration at the moment.
Btw, I don't know how didn't notice that this is a FAQ:
http://git.or.cz/gitwiki/GitFaq#Doesgithavekeywordexpansion.3F
-Mikko
On Fri, Jul 31, 2009 at 02:27:50AM -0700, Jakub Narebski wrote:
quoted
You can embed SHA-1 of a _file contents_ (blob) using '$Id: $' keyword
with `ident` attribute - see gitattributes manpage.
Great, thanks!
quoted
The correct solution of embedding version number is to do it at
_build time_, using e.g. script similar to GIT-VERSION-GEN used by
Git itself and by Linux kernel. It helps if you tag your releases.
Hi Mikko,
I don't know whether you want to use the "ident" command on your final
binary. With Git, that's pointless, as all source files will have the
same $Id$. So it's perfectly sufficient to have only ONE file enriched
with Git's SHA1.
Suggestion: During build time, compile (and link in) a file (e.g.
version.c) with "-DVERSION=\"$(git describe)\"". My version.c looks like
this:
----------------------------------
char const * version()
{
return VERSION;
}
----------------------------------
The function then returns sth. like "foo12004-26-gc6c9273", which means
that you're 26 commits ahead of the annotated tag "foo12004" and your
commit has SHA1 "c6c9273". Then make your application somehow return
that version string when asked (or deliver a version.txt together with
it). This way you know that your binary was built using commit
"c6c9273". You can further refine the VERSION by adding a "-dirty" if
the working tree was dirty at build time. Then you'll know that your
binary was based on c6c9273 "with some changes".
Make sure that version.c is the ONLY file that compiles with that
-DVERSION switch. Otherwise all files get re-compiled when $(git
describe) changes. That's not what you want.
HTH, Dirk
From: Jakub Narebski <hidden> Date: 2016-06-15 22:47:08
On Sat, 1 August 2009, Dirk Süsserott wrote:
Am 31.07.2009 11:52 schrieb Mikko Rapeli:
quoted
On Fri, Jul 31, 2009 at 02:27:50AM -0700, Jakub Narebski wrote:
quoted
quoted
You can embed SHA-1 of a _file contents_ (blob) using '$Id: $' keyword
with `ident` attribute - see gitattributes manpage.
Great, thanks!
quoted
The correct solution of embedding version number is to do it at
_build time_, using e.g. script similar to GIT-VERSION-GEN used by
Git itself and by Linux kernel. It helps if you tag your releases.
Hi Mikko,
I don't know whether you want to use the "ident" command on your final
binary. With Git, that's pointless, as all source files will have the
same $Id$. So it's perfectly sufficient to have only ONE file enriched
with Git's SHA1.
You are wrong. In Git $Id$ / $Id: $ expands to SHA-1 id of _blob_
(i.e. of file *contents*), not SHA-1 id of a commit. This way when
switching branches or rewinding branch using git-reset we don't have
to pay huge performance penalty because of `ident`, as we would have
because every file would have to be changed if $Id$ was about commit
id (or if there was $Revision$ or $Author$ implemented).
Suggestion: During build time, compile (and link in) a file (e.g.
version.c) with "-DVERSION=\"$(git describe)\"". My version.c looks like
this:
GIT-VERSION-GEN and various tricks in Makefile do just that, not only
for compiled parts, but also for scripts.
[...]
--
Jakub Narebski
Poland
On Fri, Jul 31, 2009 at 02:27:50AM -0700, Jakub Narebski wrote:
quoted
quoted
quoted
You can embed SHA-1 of a _file contents_ (blob) using '$Id: $' keyword
with `ident` attribute - see gitattributes manpage.
Great, thanks!
quoted
The correct solution of embedding version number is to do it at
_build time_, using e.g. script similar to GIT-VERSION-GEN used by
Git itself and by Linux kernel. It helps if you tag your releases.
Hi Mikko,
I don't know whether you want to use the "ident" command on your final
binary. With Git, that's pointless, as all source files will have the
same $Id$. So it's perfectly sufficient to have only ONE file enriched
with Git's SHA1.
You are wrong. In Git $Id$ / $Id: $ expands to SHA-1 id of _blob_
(i.e. of file *contents*), not SHA-1 id of a commit. This way when
switching branches or rewinding branch using git-reset we don't have
to pay huge performance penalty because of `ident`, as we would have
because every file would have to be changed if $Id$ was about commit
id (or if there was $Revision$ or $Author$ implemented).
Ok, sorry about that. Actually I haven't read the concerning docs
*that* well when I figured out that keyword expansion with Git
is not exactly a good idea.
quoted
Suggestion: During build time, compile (and link in) a file (e.g.
version.c) with "-DVERSION=\"$(git describe)\"". My version.c looks like
this:
GIT-VERSION-GEN and various tricks in Makefile do just that, not only
for compiled parts, but also for scripts.
Right, but my explanation shows the overall intention of that.
So, Mikko, have a look at GIT-VERSION-GEN and my suggestion and
use some kind of summary of them.