On Fri, Dec 19, 2008 at 3:44 PM, demerphq <demer...@gmail.com> wrote:
> 12/19 karl williamson <pub...@khwilliamson.com>:
>> And a test fails: t/run/switches.t It's looking for just a patch number:
>> # Failed at run/switches.t line 265
>> # got '
>> # This is perl, v5.11.0
>> DEVEL"blead-20081219.17:05:08-b1fccde5a5d6d9eece3886ce5cb9dc7b9027bee2"
>> built for i686-linux
> This is something that should change. Our build process should use
> git-describe if possible for the version string.
> However for that to be useful we have to change a bunch of other
> things, and have to start tagging.
Plain old git-describe with no options gives you the name of the most
recent tag on the current branch and the number of commits since that
tag, but there are at least two common situations where that's not
sufficient. As Rafael has explained more than once in various forums
(possibly not on public mailing lists -- I don't remember), the way
merges work means you can have two different ways to get the same
number of commits since the tag. Also, you can have situations (like
we have now with blead) where you have no relevant tag to count from.
The most recent tag visible from blead is 5.10.0 because 5.11.0 has
not been released, but that's not a very useful place to count from
for blead.
After a lot of discussion, I thought we had decided on parsing the
branch name and an abbreviated version of the SHA1 out of git describe
--all --long something like so:
% git describe --all --long
heads/maint-5.8-0-ga00da08
% git describe --all --long | perl -ne '$_ =~ m{^.+/(.+)-\d+-g(.+)$};
print "$...@$2\n";'
maint-...@a00da08
At least that's what we documented on the wiki before the switchover
and what was happening in the pre-release rsync set-up. What we're
seeing now is a little different, which is ok as long as it works and
gets settled soon.
I like the addition of the timestamp as long as it's the timestamp of
the push or pull from the perspective of the main repository and not
the timestamp of the original commit. If it were the latter, it could
shuffle backward and forward as people take varying amounts of time to
push their changes.
I'm not so fond of having the full SHA1 as part of the patchlevel
string that is going to show up every time someone types perl -V.
Does gitweb understand abbreviated SHA1 strings like everything else
in git? If so, there's no reason I can think of that we want the
whole thing. If not, I can see the utility of it since anyone
(hopefully Test::Smoke in the future) can construct meaningful URLs
from the SHA1.
