Re: commit type

From: bd_ <bdonlan@gmail.com>
Date: Nov 2, 2008, 23:02 UTC
Message-ID: <3e8340490811021502p70ab40a1ocdc9fca012769a29@mail.gmail.com>
In-Reply-To: <loom.20081101T034635-562@post.gmane.org>

On Fri, Oct 31, 2008 at 11:15 PM, 7rans <transfire@gmail.com> wrote:

Show 19 quoted lines

> Johannes Schindelin <Johannes.Schindelin <at> gmx.de> writes:
>
>> So you want to force this onto all Git users?
>
> Not at all. It would be a purely optional. You would never even need to know the
> feature existed if you didn't want to use it. So I'm not sure how that is
> forcing it upon anyone.
>
> Moreover, I suggested it b/c I would find such a feature very useful, and, by
> extension, thought others might as well. Perhaps others have done something
> similar, in which case it would be interesting the hear their take, or on the
> other hand they've never considered it before, but now can consider the
> potential utility of just such a feature.
>
>> If yes: that murmur you hear in the background, it might well be the
>> collective "thanks, but no thanks" of people who do not want that type of
>> distinction between different commits
>
> There is no need to make one. It's purely annotative.

The problem with this approach is that it begins to dictate a set of annotations which are considered 'more important' by the git core than others. By allowing in your 'commit type', it sets a precedent that git will add random, possibly not backwards compatible metadata changes just to support the local policies of some subset of git users. It's far better to provide a generic feature that will cover all users; and using the commit description, with hooks to enforce proper format according to local policy, is just that.

If using the commit description, with hooks to enforce whatever formatting you prefer, is not sufficient for your needs, then it would be useful to discuss exactly how this would be deficient, and then possibly think about adding a /generic/ feature that meets your needs.