commit type

commit type

[7rans]

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.

Re: commit type

[David Symonds]

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.

Re: commit type

[Samuel Lucas Vaz de Mello]

David Symonds wrote:
> 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

Re: commit type

[7rans]

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.

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.

Re: commit type

[Johannes Schindelin]

Hi,

On Fri, 31 Oct 2008, 7rans wrote:

> 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

Re: commit type

[7rans]

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.

Re: commit type

[bd_]

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

Re: commit type

[7rans]

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.