commit type

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: commit type

David Symonds
On Fri, Oct 31, 2008 at 10:58 AM, 7rans <[hidden email]> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: commit type

Samuel Lucas Vaz de Mello
David Symonds wrote:
> On Fri, Oct 31, 2008 at 10:58 AM, 7rans <[hidden email]> 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


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: commit type

7rans
In reply to this post by David Symonds
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.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

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.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: commit type

Bryan Donlan
On Fri, Oct 31, 2008 at 11:15 PM, 7rans <[hidden email]> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

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.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html