Hi, > Admittedly, I don't immediately see the date in there. You will as soon as you have seen another one.
> Also, always > think about how you can enforce this properly. Most people don't even > know how to get a short hash. Too bad for “most people”, they'll have to learn (that “getting” a short hash is just getting the first chars of it). We could have an explanation page for that too. > > Also condensing the date to skip the century is a good idea in the > > year 2016. Still 84 years to come without a century problem of patch > > file names. > > This makes it harder to spot as a date. I agree, I'd be for keeping the whole year, unless we really need to cut down two characters. > > I would even go that far to skip the date completely. It doesn't > > really tell you much. If someone bothers of the age of a patch, then > > you can always check git with the hash. > > We already had this discussion, Anselm, and we concluded back then > that the date is a great heuristic. The git hash first forces you to > have the repo at hand. When you go check the patches, the first thing > you have to think about is: Is this patch still quite recent? > The recency is always with respect to the project at hand, however, > this decision can only be made by the user and depends on the nature > of the commits. > Additionally, if you have a list of patches > st-externalpipe-ea87104.patch > st-externalpipe-fbd023a.patch > st-externalpipe-fe0239e.patch > you don't see which one is the newest one. But there shouldn't be that many in the first place. The correct way would be to have a patch for release versions, and one for last git version, the rest is maintenance. Though having the date in the filename wouldn't hurt and indeed is handy to quickly see a patch age. > As a last point of thought: The shorthash gives no info at all. It > could either be a broken patch against HEAD or not, however, pasting > the hash in the name somehow claims more than it does, and gives less > information to 99% of people. The shorthash gives the information on which commit it was made against. It could be broken against HEAD or not, but you wouldn't have a patch named st-externalpipe-BROKEN.patch anyway. Also it helps to lookup which changes (commits) have been made since the patch has been produced for maintenance.