I was speaking from a human/user perspective as I'm aware what a hash
is...although collisions in git can occur (unlikely) which never occur in a
one-up counting system (barring rollover).
If one were to say "XXXXXX" is the most current version of WSJT-X the vast
majority of users would not know how to figure out if they are current or not.
Bad to assume people building wsjtx know git. Ergo my comment which again, was
made from a human perspective that it's not a very good system...for users of
WSJT-X. Works fine for developers and configuration control. And when one
says a problem was fixed in "XXXXXX" nobody (and I mean nobody) can know if
their WSJT-X contains that change without grepping the git log to know if it's
in there.
We will be seeing more of this same question in the future I'm sure so some
consideration should be given to making it a one-up counter again perhaps
appending it to the 6-digit git number.
de Mike W9MDB
On Monday, July 9, 2018, 6:35:11 PM CDT, Bill Somerville
<[email protected]> wrote:
Hi Mike,
some comments in line below.
On 09/07/2018 17:51, Black Michael via wsjt-devel wrote:
> No...that number does not increment...it's basically random with git
> (it's a hash value). It's just the first 6 digits of the "commit"
> line which is a hexadecimal number
The git SHA-1 hash codes are not random, anything but in fact. They are
a unique representation of a commit and all it's history that is
reproducible with absolute certainty even if the commit is moved to a
different repository. This is key to how git can maintain integrity
across distributed and unconnected repositories.
>
> There is a means to making an increment version # but it's not
> frequently used -- basically one way is to count the # of log entries.
It is basically futile and pointless on anything but the most trivial
centralized work flow model with no branching, ever.
>
> As long as your version matches the most recent log entry 6-digit
> number you're current. And yes...it's not a very good system as one
> can't say "ensure you are at least version X".
That was never true even with Subversion since svn revision numbers are
common to all branches. An svn revision number is no more than a label
for a change set on some branch. All it's magnitude tells you is when
the commit was made with respect to another, but since consecutive
commits could be to different branches, that tells you little or nothing
about the logical lineage of a revision.
Your definition of "not a very good system" is based on a very poor
system as a reference point, so not a very good argument ;)
>
> de Mike W9MDB
>
73
Bill
G4WJS.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
