Hacker News Reader

Comment by amelius | Hacker News Reader

Or integrate with an issue tracker and/or project management tool, and you'll get:

    43ec6aa Fix issue 1001
    4fe84ab Fix issue 1002
    753aa05 Implement feature request 1003
    df3a662 Implement spec 1004

View on HN

I'd say _add_ issue tracker reference, not replace the description with it

    43ec6aa Fix error when the URL is not reachable (#1001)
    4fe84ab Add error message if something went wrong (#1002)
    753aa05 Add server fingerprint check (#1003)
    df3a662 Fix shadow box closing problem (#1004)

this.

Issue trackers like JIRA can be configured to search for commit-Ids in the messages, which will give you all commits associated with a ticket.

Adding ticket IDs to commits has fallen a bit out of fashion since feature-branches and pull request workflows have become popular. But adding the ticket ID to the commit messages allows for trunk-based development style, while not losing the ability to make a code review over the commits referencing a ticket.

Most of the time I write the ticket ID in the text below, which keeps the `git log --oneline` pretty, the tools can still pick it up.

Yup, though I usually put the ticket number in the body of the commit rather than the title.

I tend to put it in at the front:

    43ec6aa [1001] Fix error when the URL is not reachable
    4fe84ab [1002] Add error message if something went wrong
    753aa05 [1003] Add server fingerprint check 
    df3a662 [1004] Fix shadow box closing problem

That makes the corresponding issue easier to find.

Me too, but I put a full hyperlink to the github/gitlab issue in the body instead of just the number so that someone can just click and start reading what it's about. It also creates a back-reference on the issue page in some web-based issue trackers like Github.

Now you need to look up what 1001, 1002 or 1003 are.

It takes time and makes you unable to skim-read the commit history.

Also projects are often migrated, offshored etc., and it's not rare for repositories to get uncoupled from the ticket system.

Now "1004" tells me nothing, because I've got the source code and VCS history, but no access to the original Jira where the issue was reported.

I don't really agree with this approach, you should use either tags or branch names to link issues with git, commit titles are not the right place. It's very common for an issue to span multiple commits, this solution feels insufficient. If you feel it's necessary, you can add the issue number to the commit message body, but as a title it's not that useful. Humanly readable titles are the best option, if I need to find something I will be using git log or grep anyway.

I respectfully disagree. Regardless of branching model, why not use commit titles like:

`{Jira-1234} ADD flux capacitor control module`

... and put more verbose details in the commit message body if/when needed?

I think the opposite tends to be more helpful. The title should give you as much information as possible at a glance since it's likely to be seen in a list of commits or as part of the history of a file or line of code.

The more verbose details and ticket id should be in the body since I'm more likely to care about them once I've pulled up the commit to review in detail.

Not to belabor the point, but once you're familiar with the contents of a given ticket (the "{Jira-1234}" reference in my example), the commit message titles' information density goes way, way up. Adding this ~12-character prefix results in useful, scannable, one-line commit messages. I see no downside.

How about an actually informative and useful alternative:

43ec6aa Fixed crash when network fails mid transfer (#1001)

The meta is to use present tense

(If you apply this commit, it will) fix the button.

I really hope this was sarcastic.

It's true though, I've seen this all over the place.

Reply on news.ycombinator.com