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/"