On Thu, 16 Jun 2016 07:27:58 +0200
Anselm R Garbe <garbeam_AT_gmail.com> wrote:
Hey Anselm,
> I would suggest to use: <project>-<patch title>-<short git hash>-<YYMMDD>.patch
st-externalpipe-ea87104-160423.patch
Admittedly, I don't immediately see the date in there. Also, always
think about how you can enforce this properly. Most people don't even
know how to get a short hash.
> Replacing the "git" portion with the short hash makes it much more
> accurate to what git version the patch applies to.
but it breaks sorting.
> 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 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.
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.
Cheers
FRIGN
--
FRIGN <dev_AT_frign.de>
Received on Thu Jun 16 2016 - 16:15:46 CEST