Re: commit type

[7rans <transfire@gmail.com>]

bd_ <bdonlan <at> gmail.com> writes:

> 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.

Except for going so far as to add full-on tagging to commits, I'd don't see how
it could be more generic. Perhaps I'm misunderstood. I'm not suggesting any
particular set of types, if that's what you think. Just the ability to add one.
For example:

  git commit -m "describe some change" --type anything-at-all

So the types *I* would use are 'major', 'minor' and 'bug', but others could use
whatever types they'd like. Ie. developers could have their one type policies.
And I agree, it would be cool to define hooks to enforce the policy.

The problem with adding them to the description is that other tools have no idea
about them and so can't not display them when they aren't wanted --a logging
tool is a good example. It is also means more complicated scripting is required
to do anything with them, not a huge deal, but a pita nonetheless.