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