On Wednesday 14 of November 2012 21:40:47 Darrell Anderson wrote: > For the development branch, part of the package name should convey > information that we all are packaging in a similar manner. > > Thus, whether we name a package krita-trinity or trinity-krita is not as > important as we all consistently use the text string "trinity." > > Likewise for conveying GIT snapshot information about the package. > > I ran the command above: > > git log $(git tag | sort | tail -n1)..HEAD --pretty=oneline | wc -l > 384 > > The result "384" conveys little information to end-users. That is, > end-users would not be able to know from that number the snapshot moment of > the package. > > Our goal should be to adopt a package naming scheme that ensures a > reasonable degree of consistency among all packagers. There is no way for > all of us to have the exact same text strings in the packages because each > distro is different. None of us create packages at the exact same moment. > We are only seeking a reasonable degree of consistency. > > Using dates or hashes is sensible but only when we use them consistently. > > My concern with hashes is they are gibberish when used by themselves. They > convey no useful information by themselves. > > Dates make sense to me when related to the snapshot moment of the > repository. Dates do not make sense to me when representing when the > package was created. Nothing stops a person from updating a local > repository and then building packages from that snapshot a week later. In > such an example the date provides no meaningful information. When a person > builds a package a week later but the date represents the snapshot moment > of the repository then the date retains meaning. > > Because of the recent server updates, I have not updated my local > repository for several days. At this moment in my local repository, the > date/time stamp of tdelibs/.git/ORIG_HEAD is Nov 10 11:46. I could convert > that to 201211101146 or some other combination such as 2012_11_10_11_46. > With that method I don't need to extract a hash from anywhere. > > I could use both date and a hash: 20121110-03733ab1 or > 201211101146-03733ab1. The hash and time stamp will change with each patch > pushed, even when there are multiple pushes during a day. Thus, both > date-hash and date-time convey useful information about the repository > snapshot moment. Yet to end-users, I believe a date-time string conveys > more useful information. > > The following command extracts the date-time: > > find tdelibs/.git/ORIG_HEAD -printf "%TY%Tm%Td%TH%TM\n" > 201211101146 > > I could extract the module's most recent hash: > > cat tdelibs/.git/ORIG_HEAD | cut -c 1-8 > 03733ab1 > > With all of that said, the git shortlog method I have been using runs into > the same challenge. The number has meaning to me because the number is > always increasing. A date is a much better informational guide. We only > need agree on a consistent way to extract that date from the module. :) I mean the combined number of commits and git hash. For example: TARGET=14.0.0 cd tde/main/tdelibs echo $(basename $PWD)-trinity-$TARGET~pre$(git log $(git tag | sort | tail -n1)..HEAD --pretty=oneline | wc -l)+$(git rev-parse HEAD | colrm 9) This will give for all the exact same results. This will contain important information == git hash. And also the growing number useful to simple compare "older < later". Slavek --