2008/12/20 Craig A. Berry <craig.a.be...@gmail.com>:
> 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,
No, plain old git-describe produces output like the last item on the
perl5changes report.
LIke this:
GitLive-blead-26-g60bc010
perl-5.8.0-13291-g52ec13a
The only reason we have GitLive-blead there is because the last tag we
had was Perl5.8.0, and thus it was pretty confusing to see:
perl-5.8.0-13291-g52ec13a in a mail about commits to blead. So i
created GitLive-blead and etc, to mark the "state when we went
GitLive".
However, as you can see there is enough information there to make the
description essentially unique. The tag corresponds to a specific
commit, the number is derived from a known tree walking algorithm, and
the sha1 prefix is there as a disambiguator. And the algorithm to walk
the commits is known to git. What is interesting is that while the
name is unambiguous, and probably also unique, it is contextual. If
you have extra tags your git-describe and my git-describe arent going
to be the same, even tho tho are both probably unambiguous.
> 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.
I think you are taking Rafaels comment out of context. I believe he
was speaking from the perspective of a simple numbering scheme, not
one which provides extra information.
> 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.
Well, IMO counting from 5.10.0 makes sense for blead until the release
of 5.11.0. However it also makes sense for maint-5.10, and thus would
be confusing, although probably still unambiguous. Adding the branch
name resolves that.
> 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.
Yes. We need to be able to take a set of .patch id's and order them.
Keep in mind that .patch files dont 1:1 correspond to commits. They
can't for various reasons. Not every commit will have a corresponding
patch file, or .patch rsync.
> 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.
Its the timestamp the .patch file was created. Again in order to make
them orderable.
> 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.
Full sha1 no. We need to think about this more. I think we have
different requirements from .patch files and from perl -V that just
happend to be simultaneously met by perforce revision numbers. We need
to be able to create the perl -V properly from the content of a .patch
file. We also need to be able to relate a .patch file to a diff as
there are people that expect diffs.
I think we should think about how you can effectively turn a nonlinear
dynamic source like git into a reliable way to create .patch files,
diffs that can be linearly applied, and perl -V output, and still be
useful before we rush to a decision.
Im happy to change the .patch file generator if necessary, but I chose
the format I did for a number of good reasons. git-describe is
contextual, we want to be able to order reports about .patch files
conveniently. We want to be able to generate diffs at the same time as
we generate .patch files, and we probably wnt them to correspond. We
want to be able to generate -V output from either git or a .patch file
so that the output is the same for the same input.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
