Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Favourite Git Commit

fatbusinessman.com

Post reply on HN
Print view View original

111–120 of 389 posts

Re: My Favourite Git Commit

#111

Post by Chris2048 »

Sharparam wrote: post #6
Chris2048 wrote: post #2

Should this go into a commit message, instead of an issue/ticket?

Since this is describing the commit and what was done and why, the commit seems like a better place. In tools like GitHub, if you make a PR with this commit, it will also automatically put the text in the PR description. I would much prefer this at work over what I usually see with inconsistent commit message styles and not explaining properly what was done, and not following the recommended max length per line.

but "why" includes lots of detail about the steps they went through. Why can't "there was utf-8/non-ascii whitespace in the file" Cover all of that? Why detail all the steps to reproduce?

Re: My Favourite Git Commit

#112

Post by Chris2048 »

adamlett wrote: post #5
Chris2048 wrote: post #2

Should this go into a commit message, instead of an issue/ticket?

I say yes. I like to keep information about the code as close to the code as possible. Issue trackers come and go, and even if you keep the same issue tracker around, how are you going to relate the change in the code to the particular issue down the road? FWIW, I also prefer READMEs to Wikis.

> Issue trackers come and go

What do you mean? Just put an issue ID in the code and/or commit.

Re: My Favourite Git Commit

#113

Post by AdrienLemaire »

This is a lovely commit, thanks for sharing it.

Over the years, I took the habit to request from my coworkers to write semantic commit messages, like https://www.conventionalcommits.org/

You can use git hook libraries like the python pre-commit or javascript husky to check your git commit messages format.

Re: My Favourite Git Commit

#114

Post by nailer »

strictfp wrote: post #30

OR you could just write Replace invalid ASCII char. Fixes rake error 'invalid byte sequence in US-ASCII'. I don't want your entire life story in my commit log.

This is good, I'd add:

> Replace invalid ASCII char. Fixes rake error 'invalid byte sequence in US-ASCII'. See #123

So people can get the life story if they want it.

Re: My Favourite Git Commit

#115

Post by olucode »

mpettitt wrote: post #97
simonh wrote: post #83

My favourite Github commit was someone removing their password from a test list in a penetration testing tool, because they didn't want anyone to know their password. I just tried, but couldn't track it down. The subsequent comment trail was hilarious.

At a guess, https://github.com/danielmiessler/SecLists/pull/155 ?

This is the best PR thread on the internet. Thank you for sharing this.

Re: My Favourite Git Commit

#116

Post by Chris2048 »

the_duke wrote: post #19
Chris2048 wrote: post #2

Should this go into a commit message, instead of an issue/ticket?

This is a big discussion. In a professional setting, companies usually want this information to live in the issue tracker. Mainly to provide insight to managers/other teams without looking at commit messages. But it removes the information from the code: you now need to look at the issue tracker to make sense of changes, eg when looking at the history of a file, or with git-blame. I'd argue that all relevant informat…

> you now need to look at the issue tracker to make sense of changes

Not really, the commit message can be informative without being this verbose.

> you now need to look at the issue tracker

Doesn't seem like a bad thing to me. Issue trackers are designed to search through.

Re: My Favourite Git Commit

#117

Post by sytelus »

I don't like all these information shoved in to commit logs. This should have been filed as issue and then linked to the commit. The issues are much more searchable, readable, commentable, archivable and interactable in many different ways.

Re: My Favourite Git Commit

#118

Post by TwoHeadedBeast »

BlueTemplar wrote: post #66
danmur wrote: post #20

I wish Git wasn't like some generic term for source control. A little diversity is good!

Good point - but what is the use case where another source control system (like SVN?) works better ?

Virtually all use cases in my experience.

Re: My Favourite Git Commit

#119

Post by Chris2048 »

shakna wrote: post #7
Chris2048 wrote: post #2

Should this go into a commit message, instead of an issue/ticket?

The commit message still logs in the usual way, but it carries the whole set of information with it, in a way that a centralised ticket system doesn't. When a developer is looking at logs for solving some problem, they can easily review the rationale for changes. I'd much prefer the log explaining everything, rather than having to look to a ticket that may no longer exist.

> in a way that a centralised ticket system doesn't

Why doesn't it? Are closed issues not searchable?

It seems to me you doubt the ticket retention, but instead of fixing that, use commits to store issues instead.

How do you provide comments or updates on an issue "relevant to the commit" without arbitrary commits?

Re: My Favourite Git Commit

#120

Post by katzgrau »

I'm always intrigued when developers complain that it was "[surprisingly short amount of time] of my life I won't get back."

Maybe I'm not as clever, but I'm lucky if I fix an issue like that within a few hours. It can sometimes derail a workday. In fact, fixing in a few hours would be something worth celebrating!

Post reply on HN