Mail Archives: geda-user/2014/03/18/13:09:25
Stephen R. Besch wrote:
>>> However I would like to see some git magic to happen and
>>> when I click window about I would get date of the last commit
>>> and commit ID. I sometimes forget to pull before make.
>>
>> A nice way is to call git describe --tags in the build scripts, and
>> put the output in a #define.
>
> The versioning stuff does get complicated, particularly when project
> history is factored in. Git doesn't help since it does not maintain a
> revision counter.
Did you look into what the output of git describe --tags actually is?
It includes the tag name, the number of commits since the tag, and an
abbreviated commit id. This is a most excellent identifier in the repo.
> However, this is really not very hard to fix.
> Use a server side "post-receive" and "pre-receive" scripts to
> increment a counter that is kept in a text file with the date of
> the push.
I can not possibly discourage such arrangements strongly enough.
Insisting on monotonically increasing numbers to identify commits is
madness. If there's more than a single branch then the numbers mean
just as little as commit hashes. Please spend the five minutes needed
to understand the git data model (I'm happy to help explain it!) and
you'll quickly appreciate how useful the commit hash is. git describe
additionally provides distance from the latest tag, although
redundant it can be a nice-to-have bonus.
Finally, version numbers have nothing to do with commits. In fact,
version numbers have nothing to do with anything. They are completely
arbitrary numbers, designed only as a marketing gimmick, to trick
your mind.
Open source is a continuum of change. Sometimes faster, sometimes
slower. I consider timestamps to be the only thing that carries
meaning. Ubuntu-style versioning is not a bad idea at all.
The pcb versioning is equally good, if a tad verbose. :)
//Peter
- Raw text -