Hacker News Reader

Hacker News

Comment by chris_wot | Hacker News Reader

Parent Full thread

chris_wot

The commits actually do give that info. Take for instance this commit:

https://github.com/git/git/commit/c8af66ab8ad7cd78557f0f9f5e...

It actually gives examples and a lengthy explanation and reasoning behind the ban.

View on HN

But why put that info in commit message instead of a comment in the file itself?

Because comments can be tedious and get out of sync with the repo. Why not check the git history? I wish more repos could be like this!

> Why not check the git history?

Because that is effort every person who uses the file has to do over and over again, whereas maintaining the file is effort that has to be done once by one person.

It sounds like you want a manual. Personal preference I guess. The maintainers seem to have decided to keep it in the history. It's not like this was ever meant for anything other than git itself.

If all you have is Git everything looks like a commit.

I really wish tooling like this was more common:

https://github.com/eamodio/vscode-gitlens/tree/v11.2.1#curre... (screenshot)

> Current Line Blame: Adds an unobtrusive, customizable, and themable, blame annotation at the end of the current line

Someone here commented to use git blame to find the commit that banned the functions and read the commits. These people making the suggestions.. must hate other people and their time. Also, what if someone.. for example runs a code formatter on the file, making git blame useless? Is it really so difficult to make a manual or explain properly in the comments about what replacements to use?

Try:

  git blame -w -M

This will ignore whitespace and detect moved or copied lines.

git blame --ignore-rev / --ignore-revs-file

Or even in the compile error message itself.

Now that's what a good commit message looks like!

Commit messages like that are common in the Linux kernel project, which is where git came from (though this particular commit message is a bit on the longer side).

It makes more sense if you think of it as an email message justifying why the project maintainer should accept that change, because that's what they were before git even existed. Still today, unless you're one of the Linux kernel subsystem maintainers, you have to convert your changes to emails with git-format-patch/git-send-email and send them to the right mailing list. Even the Linux kernel subsystem maintainers keep writing commits in that style out of habit (and because Linus will rant at them if they don't).

Reply on news.ycombinator.com