gnuastro-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnuastro-devel] Updates in coding and commit conventions


From: Mosè Giordano
Subject: Re: [gnuastro-devel] Updates in coding and commit conventions
Date: Fri, 6 May 2016 12:51:21 +0200

Hi Mohammad,

2016-05-05 6:51 GMT+02:00 Mohammad Akhlaghi <address@hidden>:
> 2. A convention is suggested for the commit message titles: that they start
> with a short category before the actual title. This is done to more easily
> go through the commit logs. Note that not all changes can be classified by
> files (so Git can automatically separate the commits we want), for example a
> change in the book can easily be about any of the utilities, libraries,
> development, installation and so on.

I don't really like this one.  While it may be useful in principle, I
fear that it's easy it'll became inconvenient in practice.  Most of
other commit guidelines are common to many other projects (usually
they' are 50-chacter long title without full stop and 72-character
long lines for the body), but this rule will easily go unnoticed.  In
addition, contributors will need to go back and forth from the
category list to choose the most appropriate one, and categories
aren't always well defined.  The list of categories is available on
Savannah webpages, but for utilities the short name should be used, and
the list of those names is elsewhere, this is an additional
complication to the very simple process of writing a commit message.
The result is that in some cases people would use a simple catch-all
category making the use of categories completely useless.
Furthermore, the need to use a category plays against keeping a short
title: 7 out of 11 utilities have short names longer than 7
characters, so that the short name plus colon plus a space is long at
least 10 characters.

In general, I think that putting uncommon (and not easy to comply
with) rules on potential contributors will keep them away from a
project rather than encouraging them and this kind of rules should
be avoided.

Bye,
Mosè



reply via email to

[Prev in Thread] Current Thread [Next in Thread]