On Sun, 2011-04-24 at 02:31 +0200, Adam Borowski wrote: > On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote: > > I would like to see policy forbid the use of commit hashes in versions. > > They aren't ordered, and the information about exactly which commit the > > snapshot was can be included in the changelog. > > If you use "git describe", removing hashes is a bad idea. > > They are needed to identify the version. Version numbers that are not > unique are worthless. If versions are not ordered without the inclusion of a commit hash, they are not ordered *with* it (except by chance). > A small portion of the hash is there only to disambiguate potential > branches, ordering is provided by the number of commits: > 0.9.0-a0-283-g1143071 means: tag "0.9.0-a0", with 283 revisions after it, > from a branch whose head's hash starts with 1143071. > > If I take revision 282 and apply patch X, while you take the same revision > but apply patch Y instead, we both would have the same version number if > hash is not included. But it is not possible for a branch head to be in two different positions at different times which 'git describe' will distinguish only by the hash, unless it is rebased. > You can then checkout 0.9.0-a0-283-g1143071 in any repository that has my > commits and you'll get that exact version. 0.9.0-a0-283 doesn't give you > that. [...] Last time I looked, policy required upstream source to be provided as tarballs, not VCS references. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part