threads / discuss / 16112

commit type

Subject: commit type

## tl;dr

8 messages between Oct 31, 2008 and Nov 3, 2008.

replies: 7people: 5as markdown or json

7rans· Oct 31, 2008, 17:58 UTC · lore

Hi--

I have a feature request.

I'd like to be a able to add a commit type to my commits, like 'major', 'minor', 'bug', etc. it would be useful in reviewing changes, especially when listing changes for end-users to see, because then miscellaneous/administrative commits could be omitted and only changes important to users listed.

Currently I achieve this by adding "[type]" to the end of my commit messages. But of course that's less than optimal. I think being able to add a commit type would be generally useful to everyone, and really has no downside becuase you do not need to use it if you prefer not.

Thanks, trans.

David Symonds· Oct 31, 2008, 18:04 UTC · re: 7rans · lore

Re: commit type

On Fri, Oct 31, 2008 at 10:58 AM, 7rans <transfire@gmail.com> wrote:

> Currently I achieve this by adding "[type]" to the end of my commit messages.
> But of course that's less than optimal.

Why is that less than optimal? It seems a lot less intrusive than what you suggest.

Dave.

Samuel Lucas Vaz de Mello· Oct 31, 2008, 18:56 UTC · re: David Symonds · lore

Re: commit type

David Symonds wrote:

Show 8 quoted lines

> On Fri, Oct 31, 2008 at 10:58 AM, 7rans <transfire@gmail.com> wrote:
> 
>> Currently I achieve this by adding "[type]" to the end of my commit messages.
>> But of course that's less than optimal.
> 
> Why is that less than optimal? It seems a lot less intrusive than what
> you suggest.
>

Also, you can use a hook to check that the commit message contains a valid "type".

 - Samuel

7rans· Oct 31, 2008, 19:20 UTC · re: David Symonds · lore

Re: commit type

David Symonds <dsymonds <at> gmail.com> writes:

Show 8 quoted lines

> 
> On Fri, Oct 31, 2008 at 10:58 AM, 7rans <transfire <at> gmail.com> wrote:
> 
> > Currently I achieve this by adding "[type]" to the end of my commit messages.
> > But of course that's less than optimal.
> 
> Why is that less than optimal? It seems a lot less intrusive than what
> you suggest.

Because it becomes formalized. Which means people can write tools other people can use to work with them.

Having the type embedded in commit message not only clutters up the commit messages, but different people would do it differently, using different brackets or putting it the start or the end of the message, etc.

And of course it would be easier to ask git to list certain types of commits if it knew about them.

7rans.

Johannes Schindelin· Oct 31, 2008, 23:27 UTC · re: 7rans · lore

Re: commit type

Hi,

On Fri, 31 Oct 2008, 7rans wrote:

Show 13 quoted lines

> David Symonds <dsymonds <at> gmail.com> writes:
> 
> > On Fri, Oct 31, 2008 at 10:58 AM, 7rans <transfire <at> gmail.com> 
> > wrote:
> > 
> > > Currently I achieve this by adding "[type]" to the end of my commit 
> > > messages. But of course that's less than optimal.
> > 
> > Why is that less than optimal? It seems a lot less intrusive than what 
> > you suggest.
> 
> Because it becomes formalized. Which means people can write tools other 
> people can use to work with them.

So you want to force this onto all Git users?

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.

If no: what would be the real difference from that suffix in the oneline?

Ciao, Dscho

7rans· Nov 1, 2008, 04:15 UTC · re: Johannes Schindelin · lore

Re: commit type

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.

T.

bd_· Nov 2, 2008, 23:02 UTC · re: 7rans · lore

Re: commit type

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.

7rans· Nov 3, 2008, 01:34 UTC · re: bd_ · lore

Re: commit type

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

Show 13 quoted lines

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