X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <20140318170901.1590.qmail@stuge.se>
Date: Tue, 18 Mar 2014 18:09:01 +0100
From: Peter Stuge <peter AT stuge DOT se>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] pcb-20140316 is released
Mail-Followup-To: geda-user AT delorie DOT com
References: <201403170355 DOT s2H3tavv007601 AT envy DOT delorie DOT com> <532741F8 DOT 8090101 AT buffalo DOT edu> <201403171845 DOT s2HIj1kj012076 AT envy DOT delorie DOT com> <20140317185419 DOT GB5081 AT localhost DOT localdomain> <DUB125-W257D599B410B568111A209C67C0 AT phx DOT gbl> <20140318073922 DOT 25660 DOT qmail AT stuge DOT se> <53286E8C DOT 8060403 AT buffalo DOT edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <53286E8C.8060403@buffalo.edu>
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

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