6 ms·

Dots, periods or starting with caps - it makes no difference (except for aesthetics, perhaps.) What does (or at least: did for me) is Angular-style commit messa

by stared 11y ago

Dots, periods or starting with caps - it makes no difference (except for aesthetics, perhaps.) What does (or at least: did for me) is Angular-style commit messages: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit https://github.com/angular/angular.js/blob/master/CONTRIBUTI.... > <type>(<scope>): <subject> > [...] > feat: A new feature > fix: A bug fix > docs: Documentation only changes > style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) > refactor: A code change that neither fixes a bug or adds a feature > perf: A code change that improves performance > test: Adding missing tests > chore: Changes to the build process or auxiliary tools and libraries such as documentation generation There is a big difference in knowing if someone added a feature, fixed something, or did some refactoring.

4ad 11y ago
Starting with caps or not makes a huge difference. It can easily break naive grep/awk. Other problems are typos and idiosyncratic spellings. Always spell-check your commit messages, it should be part of your git hooks.
- emerongi 11y ago
  By that logic we should also take into account all the other 1000s pieces of technology that can operate with text. In the end it all comes down to personal preference or the project guidelines.
  - 4ad 11y ago
    > we should also take into account all the other 1000s pieces of technology that can operate with text Yes, it called the Unix philosophy, good programs do it.
planetjones 11y ago
I just see that as friction. Now a developer who is working on a new feature is reluctant to take opportunities to refactor incase their commit message doesn't match the "standard". Empower the developer and reduce friction to a minimum is my modus operandi. Plus commit often and plan commits: with the example above the commit messages themselves are becoming a chore. Just make the message meaningful and link it to a JIRA issue or something. That's simple enough for me.
- hahainternet 11y ago
  > I just see that as friction. Now a developer who is working on a new feature is reluctant to take opportunities to refactor incase their commit message doesn't match the "standard". Empower the developer and reduce friction to a minimum is my modus operandi. Honestly those commits should probably be split anyway. A commit should represent the smallest 'change' which is singificant.
  - Nilzor 11y ago
    >Honestly those commits should probably be split anyway. A commit should represent the smallest 'change' which is singificant. Which again may result in that refactoring never getting done. Many times I've found myself saying to myself "I must refactor this class.. But I'll just finish implementing this feature first so that I can get a clean commit with only the refactoring afterwards". Suddenly it's 5 o'clock and tomorrow I've forgotten about the refactoring need.
    - manigandham 11y ago
      I struggle to see how this adds so much more effort? You already know you want to refactor it so its not about forgetting to do it, and once the feature is done you'll probably have a better idea of how to refactor everything better and faster. It should actually save time in code productivity vs the extra minutes to do another commit.
    - otherusername2 11y ago
      I can't imagine my workflow being all that special, but I never have to deal with this? I just write new features, refactor if needed, fix unrelated bugs, etc. When I feel like it's commit-time, I cherry-pick changed chunks or lines to commit into single coherent commits. If I've introduced a new feature that required refactoring, I'll first pick all the chunks that belong to the refactoring and commit; then I'll commit the new feature and afterwards commit any bugfixes and other side endeavors that may have come up during the development of the new feature. This is one of the reasons I don't like working with Subversion anymore. Committing, say, two changed lines in a file with many changes is nearly impossible. In 'git gui' it's a simple as selecting the lines, right-click, "Stage lines for commit" and pressing the commit button, and I'm back to working on whatever it was I was really working on.
arethuza 11y ago
For some reason the fact that "feature" is abbreviated to "feat" while "refactor" which is actually longer than "feature" is left alone irritates me - which, of course, doesn't mean anything other than to demonstrate how silly this kind of argument can be!
- pandler 11y ago
  True, but "ref" is ambiguous since that abbreviation is usually used to mean "reference". "refac" or "refact" just don't roll off the tongue.
  - deleted 11y ago
    [deleted]
- eli 11y ago
  Every newspaper -- even ones that mostly use AP style -- has its own slightly different style guide. I don't think that proves style guides are pointless.
antirez 11y ago
Hep, that's very good. I'm trying to do this recently, it is very hard btw unless you organize different topics beforehand, but then it is easy to escape since I often try to do something like "Submodule: ...." because later to merge just a single feature is simpler because commits are "tagged" with the name of the feature or module.
- stared 11y ago
  I do have problems with "(<scope>)", but I don't treat commit messages as statements defining code structure, but as hints of what I did. (In any case, I don't use Angular-style commits for all projects. But learning about them was a small (but important) step in reducing complexity, vide http://www.johndcook.com/blog/2015/06/18/most-important-skill-in-software/. http://www.johndcook.com/blog/2015/06/18/most-important-skil...)
braythwayt 11y ago
Whenever I see a convention like this, I think to myself, “There is another data model being serialized into text.”
- WalterGR 11y ago
  So very true. And I struggle with this. "Why should I write something out when tools could do it for me? Isn't me specifying it, then, just me being overly verbose?" But tools often don't - and may never. I'm curious: In any tool for any revision control system ever: in a list of commits, are the commit messages augmented with something useful beyond the basics? ("Basics" being e.g. the first 'n' characters of the human-provided commit message, a revision identifier, a timestamp, and a username.)
  - arethuza 11y ago
    I can vaguely remember that PVCS had a way of explicitly linking tickets to commits, TFS probably has this as well.
    - twohlix_ 11y ago
      Github has a way of linking issues with commits. You just mention the issue in the commit e.g. 'This commit closes #1' and i believe the issue will close with that as well, but it will show up in the issue. Jira and other ticketing systems can often read repos and look for ticket ids. In my commits at work I just mention PRJCTNAME-142 and that'll link to a ticket and aggregate in jira all the commits/pull requeusts/branches... tagged with that
    - breischl 11y ago
      Our internal system has some integration between Jira and Github, such that if you comment a commit with the ticket number then you can see them all in the Jira ticket.
    - smackfu 11y ago
      RTC works like that. You can also set up rules so that you can't even check in without linking a ticket.
Bahamut 11y ago
One really nice side-effect is that these commits can be used to autogenerate changelogs, which is what the Angular team does.

by stared 11y ago

4ad 11y ago

Starting with caps or not makes a huge difference. It can easily break naive grep/awk. Other problems are typos and idiosyncratic spellings. Always spell-check your commit messages, it should be part of your git hooks.

emerongi 11y ago
By that logic we should also take into account all the other 1000s pieces of technology that can operate with text. In the end it all comes down to personal preference or the project guidelines.
- 4ad 11y ago
  > we should also take into account all the other 1000s pieces of technology that can operate with text Yes, it called the Unix philosophy, good programs do it.

planetjones 11y ago

I just see that as friction. Now a developer who is working on a new feature is reluctant to take opportunities to refactor incase their commit message doesn't match the "standard". Empower the developer and reduce friction to a minimum is my modus operandi. Plus commit often and plan commits: with the example above the commit messages themselves are becoming a chore. Just make the message meaningful and link it to a JIRA issue or something. That's simple enough for me.

hahainternet 11y ago
> I just see that as friction. Now a developer who is working on a new feature is reluctant to take opportunities to refactor incase their commit message doesn't match the "standard". Empower the developer and reduce friction to a minimum is my modus operandi. Honestly those commits should probably be split anyway. A commit should represent the smallest 'change' which is singificant.
- Nilzor 11y ago
  >Honestly those commits should probably be split anyway. A commit should represent the smallest 'change' which is singificant. Which again may result in that refactoring never getting done. Many times I've found myself saying to myself "I must refactor this class.. But I'll just finish implementing this feature first so that I can get a clean commit with only the refactoring afterwards". Suddenly it's 5 o'clock and tomorrow I've forgotten about the refactoring need.
  - manigandham 11y ago
    I struggle to see how this adds so much more effort? You already know you want to refactor it so its not about forgetting to do it, and once the feature is done you'll probably have a better idea of how to refactor everything better and faster. It should actually save time in code productivity vs the extra minutes to do another commit.
  - otherusername2 11y ago
    I can't imagine my workflow being all that special, but I never have to deal with this? I just write new features, refactor if needed, fix unrelated bugs, etc. When I feel like it's commit-time, I cherry-pick changed chunks or lines to commit into single coherent commits. If I've introduced a new feature that required refactoring, I'll first pick all the chunks that belong to the refactoring and commit; then I'll commit the new feature and afterwards commit any bugfixes and other side endeavors that may have come up during the development of the new feature. This is one of the reasons I don't like working with Subversion anymore. Committing, say, two changed lines in a file with many changes is nearly impossible. In 'git gui' it's a simple as selecting the lines, right-click, "Stage lines for commit" and pressing the commit button, and I'm back to working on whatever it was I was really working on.

arethuza 11y ago

For some reason the fact that "feature" is abbreviated to "feat" while "refactor" which is actually longer than "feature" is left alone irritates me - which, of course, doesn't mean anything other than to demonstrate how silly this kind of argument can be!

pandler 11y ago
True, but "ref" is ambiguous since that abbreviation is usually used to mean "reference". "refac" or "refact" just don't roll off the tongue.
- deleted 11y ago
  [deleted]
eli 11y ago
Every newspaper -- even ones that mostly use AP style -- has its own slightly different style guide. I don't think that proves style guides are pointless.

antirez 11y ago

Hep, that's very good. I'm trying to do this recently, it is very hard btw unless you organize different topics beforehand, but then it is easy to escape since I often try to do something like "Submodule: ...." because later to merge just a single feature is simpler because commits are "tagged" with the name of the feature or module.

stared 11y ago
I do have problems with "(<scope>)", but I don't treat commit messages as statements defining code structure, but as hints of what I did. (In any case, I don't use Angular-style commits for all projects. But learning about them was a small (but important) step in reducing complexity, vide http://www.johndcook.com/blog/2015/06/18/most-important-skill-in-software/. http://www.johndcook.com/blog/2015/06/18/most-important-skil...)

braythwayt 11y ago

Whenever I see a convention like this, I think to myself, “There is another data model being serialized into text.”

WalterGR 11y ago
So very true. And I struggle with this. "Why should I write something out when tools could do it for me? Isn't me specifying it, then, just me being overly verbose?" But tools often don't - and may never. I'm curious: In any tool for any revision control system ever: in a list of commits, are the commit messages augmented with something useful beyond the basics? ("Basics" being e.g. the first 'n' characters of the human-provided commit message, a revision identifier, a timestamp, and a username.)
- arethuza 11y ago
  I can vaguely remember that PVCS had a way of explicitly linking tickets to commits, TFS probably has this as well.
  - twohlix_ 11y ago
    Github has a way of linking issues with commits. You just mention the issue in the commit e.g. 'This commit closes #1' and i believe the issue will close with that as well, but it will show up in the issue. Jira and other ticketing systems can often read repos and look for ticket ids. In my commits at work I just mention PRJCTNAME-142 and that'll link to a ticket and aggregate in jira all the commits/pull requeusts/branches... tagged with that
  - breischl 11y ago
    Our internal system has some integration between Jira and Github, such that if you comment a commit with the ticket number then you can see them all in the Jira ticket.
  - smackfu 11y ago
    RTC works like that. You can also set up rules so that you can't even check in without linking a ticket.

Bahamut 11y ago

One really nice side-effect is that these commits can be used to autogenerate changelogs, which is what the Angular team does.