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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
