Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #144196 > unrolled thread

Tagging programs with git hash. [slightly OT]

Back to article view | Back to comp.lang.c

Contents

  Tagging programs with git hash. [slightly OT] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-05-31 07:02 -0700
    Re: Tagging programs with git hash. [slightly OT] queequeg@trust.no1 (Queequeg) - 2019-05-31 14:27 +0000
      Re: Tagging programs with git hash. [slightly OT] Mateusz Viste <mateusz@wont.tell> - 2019-05-31 16:42 +0000
        Re: Tagging programs with git hash. [slightly OT] Keith Thompson <kst-u@mib.org> - 2019-05-31 13:23 -0700
        Re: Tagging programs with git hash. [slightly OT] queequeg@trust.no1 (Queequeg) - 2019-05-31 21:10 +0000
          Re: Tagging programs with git hash. [slightly OT] Mateusz Viste <mateusz@wont.tell> - 2019-06-01 09:31 +0000
            Re: Tagging programs with git hash. [slightly OT] queequeg@trust.no1 (Queequeg) - 2019-06-01 12:39 +0000
    Re: Tagging programs with git hash. [slightly OT] David Brown <david.brown@hesbynett.no> - 2019-05-31 16:28 +0200
    Re: Tagging programs with git hash. [slightly OT] fir <profesor.fir@gmail.com> - 2019-05-31 07:51 -0700
    Re: Tagging programs with git hash. [slightly OT] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-05-31 15:59 +0100
      Re: Tagging programs with git hash. [slightly OT] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-05-31 22:56 +0100
        Re: Tagging programs with git hash. [slightly OT] John Forkosh <forkosh@panix.com> - 2019-06-01 02:55 +0000
          Re: Tagging programs with git hash. [slightly OT] fir <profesor.fir@gmail.com> - 2019-06-01 04:26 -0700
            Re: Tagging programs with git hash. [slightly OT] fir <profesor.fir@gmail.com> - 2019-06-01 04:35 -0700
        Re: Tagging programs with git hash. [slightly OT] Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-01 04:03 -0700
    Re: Tagging programs with git hash. [slightly OT] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-05-31 13:30 -0700
    Re: Tagging programs with git hash. [slightly OT] Eli the Bearded <*@eli.users.panix.com> - 2019-05-31 21:46 +0000
    Re: Tagging programs with git hash. [slightly OT] Shuggie <shuggie@latepaul.com> - 2019-06-01 11:21 +0100
    Re: Tagging programs with git hash. [slightly OT] Ike Naar <ike@iceland.freeshell.org> - 2019-06-01 21:23 +0000
      Re: Tagging programs with git hash. [slightly OT] Keith Thompson <kst-u@mib.org> - 2019-06-01 14:34 -0700
      Re: Tagging programs with git hash. [slightly OT] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-06-02 12:36 -0700
        Re: Tagging programs with git hash. [slightly OT] Keith Thompson <kst-u@mib.org> - 2019-06-02 14:35 -0700

Page 1 of 2  [1] 2  Next page →

#144196 — Tagging programs with git hash. [slightly OT]

Git and similar version control systems have an internal version tag, in git 
it is the sha-1 hash, which is used to identify the version within the control system.

Now it would be nice to tag the executable with this hash, so that if a user 
reports a bug, you can ask them to run it in a mode that displays the
hash, then go back to the correct version in the repository to find the
bug.

But here we have a problem. The hash is created by applying a hash algorithm
to the entire source, which is designed to change every digit of the hash
if even a character of the source is changed. So if we add the hash to the
source, we've changed the hash. So we can't tag an executable with its
version number.

[toc] | [next] | [standalone]

#144204

Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:

> But here we have a problem. The hash is created by applying a hash algorithm
> to the entire source, which is designed to change every digit of the hash
> if even a character of the source is changed. So if we add the hash to the
> source, we've changed the hash. So we can't tag an executable with its
> version number.

Fetch the current commit hash during compilation (for example with git 
rev-parse --short HEAD) and put it in a macrodefinition in your makefile 
or similar.

CFLAGS += -DCOMMIT_HASH=\"$(shell git rev-parse --short HEAD)\"

-- 
https://www.youtube.com/watch?v=9lSzL1DqQn0

[toc] | [prev] | [next] | [standalone]

#144219

On Fri, 31 May 2019 14:27:18 +0000, Queequeg wrote:
> Fetch the current commit hash during compilation (for example with git
> rev-parse --short HEAD) and put it in a macrodefinition in your makefile
> or similar.
> 
> CFLAGS += -DCOMMIT_HASH=\"$(shell git rev-parse --short HEAD)\"

This has the ugly drawback that the build process breaks as soon as 
there's no git involved - like distributing the source code in a 
standalone *.tar.gz or so.

A possibly more flexible alternative would be computing a completely 
independent hash within the makefile and writing it to some header file 
(version.h, perhaps?). Obviously, such hash must be computed based on all 
source files of the project, *excluding* version.h.

Mateusz

[toc] | [prev] | [next] | [standalone]

#144233

Mateusz Viste <mateusz@wont.tell> writes:
> On Fri, 31 May 2019 14:27:18 +0000, Queequeg wrote:
>> Fetch the current commit hash during compilation (for example with git
>> rev-parse --short HEAD) and put it in a macrodefinition in your makefile
>> or similar.
>> 
>> CFLAGS += -DCOMMIT_HASH=\"$(shell git rev-parse --short HEAD)\"
>
> This has the ugly drawback that the build process breaks as soon as 
> there's no git involved - like distributing the source code in a 
> standalone *.tar.gz or so.

Then whatever (a script, a "make tarball" target, etc.) creates
the *.tar.gz file can run the appropriate git command and write its
output to a file.  The Makefile can invoke something that invokes
git and falls back to reading that file if the git command fails.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#144238

Mateusz Viste <mateusz@wont.tell> wrote:

> This has the ugly drawback that the build process breaks as soon as 
> there's no git involved - like distributing the source code in a 
> standalone *.tar.gz or so.

True, I didn't think about it.

Actually I'm using it (or maybe "I saw it" would be more appropriate, as 
I'm maintaining this code, but I didn't write it) only in one project at 
work, which was never compiled without git present (is needs git to fetch 
dependencies anyway).

> A possibly more flexible alternative would be computing a completely 
> independent hash within the makefile and writing it to some header file 
> (version.h, perhaps?). Obviously, such hash must be computed based on all 
> source files of the project, *excluding* version.h.

But how would you track this hash and assign it to an actual git hash?

I never had this problem, because everything I distribute outside of dev 
team is an official release with assigned version number that corresponds 
to a git tag.

-- 
https://www.youtube.com/watch?v=9lSzL1DqQn0

[toc] | [prev] | [next] | [standalone]

#144256

On Fri, 31 May 2019 21:10:49 +0000, Queequeg wrote:
> But how would you track this hash and assign it to an actual git hash?

Tracking is a job for the versioning system that is used (git, svn, cvs..) 
- it's no more complex than doing a text search looking for a specific 
string within the version.h file's history.

> I never had this problem, because everything I distribute outside of dev
> team is an official release with assigned version number that
> corresponds to a git tag.

To be honest, for my "serious" (ie. work-related, paid-for, highly 
proprietary) projects, I do use a variant of what you suggested initially 
- although I use svn exclusively because of my allergy to git, hence my 
"versions" are svn revisions in lieu of git hashes. But for things where 
the source code is to be distributed, the version.h approach may work 
well (better than manually assigning alpha/beta/gamma versions at least).

Mateusz

[toc] | [prev] | [next] | [standalone]

#144268

Mateusz Viste <mateusz@wont.tell> wrote:

>> But how would you track this hash and assign it to an actual git hash?
> 
> Tracking is a job for the versioning system that is used (git, svn, cvs..) 
> - it's no more complex than doing a text search looking for a specific 
> string within the version.h file's history.

Again, true, but isn't it an overcomplication?

> To be honest, for my "serious" (ie. work-related, paid-for, highly 
> proprietary) projects, I do use a variant of what you suggested initially 
> - although I use svn exclusively because of my allergy to git, hence my 
> "versions" are svn revisions in lieu of git hashes.

Why are you allergic to git? :)

I didn't have a choice (we use git exclusively), but I befriended git and 
use it now even in my private projects. I somehow evolved from vss to cvs, 
to svn, to bazaar and, currently, to git.

> But for things where the source code is to be distributed, the version.h 
> approach may work well (better than manually assigning alpha/beta/gamma 
> versions at least).

True. Or maybe, as Keith suggested, if you keep the source in revision 
control system and produce tarballs from it, you could just put the git 
hash, or svn revision, or any other pointer, to the version.h instead of 
a private hash. Why not?

-- 
https://www.youtube.com/watch?v=9lSzL1DqQn0

[toc] | [prev] | [next] | [standalone]

#144205

On 31/05/2019 16:02, Malcolm McLean wrote:
> Git and similar version control systems have an internal version tag, in git 
> it is the sha-1 hash, which is used to identify the version within the control system.
> 
> Now it would be nice to tag the executable with this hash, so that if a user 
> reports a bug, you can ask them to run it in a mode that displays the
> hash, then go back to the correct version in the repository to find the
> bug.
> 
> But here we have a problem. The hash is created by applying a hash algorithm
> to the entire source, which is designed to change every digit of the hash
> if even a character of the source is changed. So if we add the hash to the
> source, we've changed the hash. So we can't tag an executable with its
> version number.
> 


Put something like:

	GITHASH = `git log -1 --format="%H"`

	CFLAGS += -DGITHASH=${GITHASH}

into your Makefile.  Then in the code you'll have a macro called
"GITHASH" with the has in it.

Make sure that the object file for the module that uses this macro is
dependent on all your source files, of course, so that the build works
correctly.

You might want to have this -D flag only on that one file, especially if
you are using something like ccache.

[toc] | [prev] | [next] | [standalone]

#144208

W dniu piątek, 31 maja 2019 16:02:21 UTC+2 użytkownik Malcolm McLean napisał:
> 
> But here we have a problem. The hash is created by applying a hash algorithm
> to the entire source, which is designed to change every digit of the hash
> if even a character of the source is changed. So if we add the hash to the
> source, we've changed the hash. So we can't tag an executable with its
> version number.

if you hash a file than you have a hash for this file if you want tu put it into that file so there is new file so this has is not suitable then

everything is logicaly ok with that imo

if yopu want that kind of hashing which is also able to save this into its own hashing file there is need for special hashing algorithm, which also can be written imo (i find it possible to write hash into a file thet has this hash then, but someone need to write this hashing routine, thts all

[toc] | [prev] | [next] | [standalone]

#144210

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> Git and similar version control systems have an internal version tag,
> in git it is the sha-1 hash, which is used to identify the version
> within the control system.
>
> Now it would be nice to tag the executable with this hash, so that if a user 
> reports a bug, you can ask them to run it in a mode that displays the
> hash, then go back to the correct version in the repository to find the
> bug.
>
> But here we have a problem. The hash is created by applying a hash algorithm
> to the entire source, which is designed to change every digit of the hash
> if even a character of the source is changed. So if we add the hash to the
> source, we've changed the hash. So we can't tag an executable with its
> version number.

Theoretically, this function -- the hash of a hash-containing source --
will have a fixed point which would be the solution.  Unfortunately it
will be impossible to find!

The solution is to have the hash as data, not literal source, as DB has
suggested using a command-line macro to supply the data.

You could also patch the executable.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#144246

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> Git and similar version control systems have an internal version tag,
>> in git it is the sha-1 hash, which is used to identify the version
>> within the control system.
>>
>> Now it would be nice to tag the executable with this hash, so that if a user 
>> reports a bug, you can ask them to run it in a mode that displays the
>> hash, then go back to the correct version in the repository to find the
>> bug.
>>
>> But here we have a problem. The hash is created by applying a hash algorithm
>> to the entire source, which is designed to change every digit of the hash
>> if even a character of the source is changed. So if we add the hash to the
>> source, we've changed the hash. So we can't tag an executable with its
>> version number.
>
> Theoretically, this function -- the hash of a hash-containing source --
> will have a fixed point which would be the solution.  Unfortunately it
> will be impossible to find!

It's a sad indictment of my state of mind, but I spent the time walking
the dog thinking about this and I am not longer sure there will be a
fixed point.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#144252

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> 
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> Git and similar version control systems have an internal version tag,
>>> in git it is the sha-1 hash, which is used to identify the version
>>> within the control system.
>>>
>>> Now it would be nice to tag the executable with this hash, so that if a
>>> user reports a bug, you can ask them to run it in a mode that displays
>>> the hash, then go back to the correct version in the repository to find
>>> the bug.
>>>
>>> But here we have a problem. The hash is created by applying a hash
>>> algorithm to the entire source, which is designed to change every digit
>>> of the hash if even a character of the source is changed. So if we add
>>> the hash to the source, we've changed the hash. So we can't tag an
>>> executable with its version number.
>>
>> Theoretically, this function -- the hash of a hash-containing source --
>> will have a fixed point which would be the solution.  Unfortunately it
>> will be impossible to find!
> 
> It's a sad indictment of my state of mind, but I spent the time walking
> the dog thinking about this and I am not longer sure there will be a
> fixed point.

Yeah, "fixed point" is exactly the phrase that popped into my head
while reading mm's original post (maybe we've both been studying
too much domain theory:). And then, ditto again, the existence
question, and the impracticality certainty.
   And then the further question: is it possible to devise a hash
that guarantees such a fixed point, and where convergence to it
doesn't require an infinite-sequence lub? Or, can you conversely
show that no such (hash) function exists? (Probably outside the
scope of this ng, but when has that ever stopped anybody?:)
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#144262

W dniu sobota, 1 czerwca 2019 04:56:05 UTC+2 użytkownik John Forkosh napisał:
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> > Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> > 
> >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >>
> >>> Git and similar version control systems have an internal version tag,
> >>> in git it is the sha-1 hash, which is used to identify the version
> >>> within the control system.
> >>>
> >>> Now it would be nice to tag the executable with this hash, so that if a
> >>> user reports a bug, you can ask them to run it in a mode that displays
> >>> the hash, then go back to the correct version in the repository to find
> >>> the bug.
> >>>
> >>> But here we have a problem. The hash is created by applying a hash
> >>> algorithm to the entire source, which is designed to change every digit
> >>> of the hash if even a character of the source is changed. So if we add
> >>> the hash to the source, we've changed the hash. So we can't tag an
> >>> executable with its version number.
> >>
> >> Theoretically, this function -- the hash of a hash-containing source --
> >> will have a fixed point which would be the solution.  Unfortunately it
> >> will be impossible to find!
> > 
> > It's a sad indictment of my state of mind, but I spent the time walking
> > the dog thinking about this and I am not longer sure there will be a
> > fixed point.
> 
> Yeah, "fixed point" is exactly the phrase that popped into my head
> while reading mm's original post (maybe we've both been studying
> too much domain theory:). And then, ditto again, the existence
> question, and the impracticality certainty.
>    And then the further question: is it possible to devise a hash
> that guarantees such a fixed point, and where convergence to it
> doesn't require an infinite-sequence lub? Or, can you conversely
> show that no such (hash) function exists? (Probably outside the
> scope of this ng, but when has that ever stopped anybody?:)

imagine you are hashing such string

"askjhaskjhaskjhaskjhas"

by some thing liek adding its ascii vaues  wich will produce something like "2134"

so you add ut to the end

"askjhaskjhaskjhaskjhas2134"

 but now the sum chenges slightly 
say to  2345

on trivial solution is not to hash one or two last bytes (or not necessary last) to make you can put value that will fit

like

"askjhaskjhaskjhaskjhas23505"

now assume that 2350 is value taht hashes whole string, just this last 5 you chosen  by yourself out of some range to this sum be correct

you may found something bebbr but imo its kinda proof that has can be done, so no fundamental  problem with that

at least how i see it not spending to much time on it

[toc] | [prev] | [next] | [standalone]

#144263

W dniu sobota, 1 czerwca 2019 13:27:00 UTC+2 użytkownik fir napisał:
> W dniu sobota, 1 czerwca 2019 04:56:05 UTC+2 użytkownik John Forkosh napisał:
> > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> > > Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> > > 
> > >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> > >>
> > >>> Git and similar version control systems have an internal version tag,
> > >>> in git it is the sha-1 hash, which is used to identify the version
> > >>> within the control system.
> > >>>
> > >>> Now it would be nice to tag the executable with this hash, so that if a
> > >>> user reports a bug, you can ask them to run it in a mode that displays
> > >>> the hash, then go back to the correct version in the repository to find
> > >>> the bug.
> > >>>
> > >>> But here we have a problem. The hash is created by applying a hash
> > >>> algorithm to the entire source, which is designed to change every digit
> > >>> of the hash if even a character of the source is changed. So if we add
> > >>> the hash to the source, we've changed the hash. So we can't tag an
> > >>> executable with its version number.
> > >>
> > >> Theoretically, this function -- the hash of a hash-containing source --
> > >> will have a fixed point which would be the solution.  Unfortunately it
> > >> will be impossible to find!
> > > 
> > > It's a sad indictment of my state of mind, but I spent the time walking
> > > the dog thinking about this and I am not longer sure there will be a
> > > fixed point.
> > 
> > Yeah, "fixed point" is exactly the phrase that popped into my head
> > while reading mm's original post (maybe we've both been studying
> > too much domain theory:). And then, ditto again, the existence
> > question, and the impracticality certainty.
> >    And then the further question: is it possible to devise a hash
> > that guarantees such a fixed point, and where convergence to it
> > doesn't require an infinite-sequence lub? Or, can you conversely
> > show that no such (hash) function exists? (Probably outside the
> > scope of this ng, but when has that ever stopped anybody?:)
> 
> imagine you are hashing such string
> 
> "askjhaskjhaskjhaskjhas"
> 
> by some thing liek adding its ascii vaues  wich will produce something like "2134"
> 
> so you add ut to the end
> 
> "askjhaskjhaskjhaskjhas2134"
> 
>  but now the sum chenges slightly 
> say to  2345
> 
> on trivial solution is not to hash one or two last bytes (or not necessary last) to make you can put value that will fit
> 
> like
> 
> "askjhaskjhaskjhaskjhas23505"
> 
> now assume that 2350 is value taht hashes whole string, just this last 5 you chosen  by yourself out of some range to this sum be correct
> 

you can also said the trick is - you hash a file to soem hash assuming some last byte or bytes than just update that few last bytes to be like hash wants it to be

liek assume that sum of file id 1990 
store this "1990" as a hash then update last byte to it be just 1990

hope im not wrong, (liek stupid dik hopes) but i think i get a bigger chance to be ok ;c


> you may found something bebbr but imo its kinda proof that has can be done, so no fundamental  problem with that
> 
> at least how i see it not spending to much time on it

[toc] | [prev] | [next] | [standalone]

#144258

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> Git and similar version control systems have an internal version tag,
>>> in git it is the sha-1 hash, which is used to identify the version
>>> within the control system.
>>>
>>> Now it would be nice to tag the executable with this hash, so that
>>> if a user reports a bug, you can ask them to run it in a mode that
>>> displays the hash, then go back to the correct version in the
>>> repository to find the bug.
>>>
>>> But here we have a problem.  The hash is created by applying a
>>> hash algorithm to the entire source, which is designed to change
>>> every digit of the hash if even a character of the source is
>>> changed.  So if we add the hash to the source, we've changed the
>>> hash.  So we can't tag an executable with its version number.
>>
>> Theoretically, this function -- the hash of a hash-containing
>> source -- will have a fixed point which would be the solution.
>> Unfortunately it will be impossible to find!
>
> It's a sad indictment of my state of mind, but I spent the time
> walking the dog thinking about this and I am not longer sure there
> will be a fixed point.

Right.  Certainly it is the case for some hash functions -- even
considering just those where every bit of output is potentially
affected by every bit of input -- that there may not be a fixed
point.  It seems likely (for good hash functions such as sha-1)
that there will be at least one fixed point for any given set of
source files, but like you say there is no good way to find one.
(And if there were a good way to find one then that would be an
argument for using a better hash function.)

[toc] | [prev] | [next] | [standalone]

#144234

On Friday, May 31, 2019 at 10:02:21 AM UTC-4, Malcolm McLean wrote:
> Git and similar version control systems have an internal version tag, in git 
> it is the sha-1 hash, which is used to identify the version within the control system.
> 
> Now it would be nice to tag the executable with this hash, so that if a user 
> reports a bug, you can ask them to run it in a mode that displays the
> hash, then go back to the correct version in the repository to find the
> bug.
> 
> But here we have a problem. The hash is created by applying a hash algorithm
> to the entire source, which is designed to change every digit of the hash
> if even a character of the source is changed. So if we add the hash to the
> source, we've changed the hash. So we can't tag an executable with its
> version number.

One option would be to maintain a database online for each version
and have the bug code contact that database, query the information
for the current version (a SHA-1 on the .exe should be sufficient
to uniquely identify it), and then retrieve all information about
whatever went into that build.

It would be better to have this kind of code outside of source code
in my opinion, and add the functionality to be able to query what-
ever is needed, and to build that database with each build, rather
than trying to bake it into each .exe.

In the alternative, ship a build_info.txt file that goes along with
your installation and query that locally.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#144243

In comp.lang.c, Malcolm McLean  <malcolm.arthur.mclean@gmail.com> wrote:
> Git and similar version control systems have an internal version tag,
> in git it is the sha-1 hash, which is used to identify the version
> within the control system.
...
> But here we have a problem. The hash is created by applying a hash algorithm
> to the entire source, which is designed to change every digit of the hash
> if even a character of the source is changed. So if we add the hash to the
> source, we've changed the hash. So we can't tag an executable with its
> version number.

No, the hash isn't applied to the *entire* source. The hash is applied
to the entire history of the source that has been checked in.

Two crucial ways that differs:

1. If I have uncommitted changes, the value from
        git rev-parse --short HEAD
   or
	git log -1 --format="%H"
   as suggested else-thread, is a lie: it is the hash of the commited
   code, not the code compiled.

2. Generated code, put in .gitignore, will not be hashed.

Using a hash function to create generated code with the hash value of
the source is the obvious fix. Also including the git SHA-1 if available
will be useful for tracking major releases. When the git SHA-1 matches a
known commit on the origin, a similar compile-time generated hash should
also match (in the sense of being correllated, not being the same).

But an instance separated from the git history can still have that
second hash be exactly the same as one generated from the origin source
at some stage (naive copies of source code, or code compiled with
changes that are not commited, but will be in origin in the future). And
code where the generated hash matches nothing else become immediately
suspect for any sort of bug report.

There is a little bit of fragility in making sure that the generated
hash includes all of the code that is compiled into a project, while not
accidentally including other code that might be in the same directory.

Elijah
------
yacc generated C code is, eg, something that may need to be avoided

[toc] | [prev] | [next] | [standalone]

#144257

Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> Git and similar version control systems have an internal version tag, in git 
> it is the sha-1 hash, which is used to identify the version within the control system.
> 
> Now it would be nice to tag the executable with this hash, so that if a user 
> reports a bug, you can ask them to run it in a mode that displays the
> hash, then go back to the correct version in the repository to find the
> bug.
> 
> But here we have a problem. The hash is created by applying a hash algorithm
> to the entire source, which is designed to change every digit of the hash
> if even a character of the source is changed. So if we add the hash to the
> source, we've changed the hash. So we can't tag an executable with its
> version number.

Have a look at the way IANA do their versioning:

https://github.com/eggert/tz

Essentially they have a file called version that's used to build a 
version.h. version itself is either supplied if you're building from
release tar ball, or generated with "git describe --dirty" which will
give you a string based on the latest tag and commit. 

The Makefile also lists a set of files as the dependency for re-building
version.

[toc] | [prev] | [next] | [standalone]

#144275

On 2019-05-31, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> Git and similar version control systems have an internal version tag, in git 
> it is the sha-1 hash, which is used to identify the version within the control system.
>
> Now it would be nice to tag the executable with this hash, so that if a user 
> reports a bug, you can ask them to run it in a mode that displays the
> hash, then go back to the correct version in the repository to find the
> bug.

Why not simply tag it with the version number itself?
What's the benefit of using a hash?

[toc] | [prev] | [next] | [standalone]

#144276

Ike Naar <ike@iceland.freeshell.org> writes:
> On 2019-05-31, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> Git and similar version control systems have an internal version tag,
>> in git it is the sha-1 hash, which is used to identify the version
>> within the control system.
>>
>> Now it would be nice to tag the executable with this hash, so that if
>> a user reports a bug, you can ask them to run it in a mode that
>> displays the hash, then go back to the correct version in the
>> repository to find the bug.
>
> Why not simply tag it with the version number itself?
> What's the benefit of using a hash?

For example, if I'm developing a program, I'd like to be able to build a
version of it based on what I've just checked in, which likely won't
have a defined version number.  I'm going to be building working (or
non-working) versions of the program much more often than I'm going to
be doing "official" releases.

One alternative is to define a new version number for each commit.  vim
does this; the latest version in its git repo is v8.1.1446.  But if you
don't want to do that, a version that includes the date and (part of)
the git commit hash also works, and uniquely identifies the version of
the source from which it was built.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web