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

31–40 of 389 posts

Re: My Favourite Git Commit

#31

Post by Darkstryder »

tomashubelbauer wrote: post #17

I do feel like Git commit descriptions are severely under-utilised for sure, but I believe there is a reason for that which until fixed, will prevent rich and contentful commit descriptions for flourishing. In the article order: the screenshot is from a commit detail page. How often do you land on this page? You need to specifically click through. If you are in a commit list, the only thing that sets title-only commi…

In the same vein, I wish there would be a standard workflow for putting code inside commit logs.

The typical use case would be database migration scripts : IMO they are always a pain to version properly because fundamentally Git and all the other software versioning tools let you describe the "nodes" (in the graph theory sense of the word) of a codebase ("at commit A the code was in this state, at commit B it was in the other state"), but severely lack when it comes to describe the edges between nodes ("in order to go from state A to state B, you need to execute this code")

I think the temporal dimension of software engineering is still poorly understood, and severely undertooled.

Re: My Favourite Git Commit

#33

Post by drej »

This reminds of a Markdown issue I've had many many many times - sometimes (and only in some engines), headings would not render and I'd only get '# foobar' instead of '...'

It took too long for me to track the issue. When I write '#' using alt-3, I then write a space and oftentimes I don't lift alt soon enough and alt-space creates a non-breaking space (on macOS). And some/most Markdown engines don't recognise '#nbsp;text' as a heading.

I suspect something like this happened in the commit linked here.

Re: My Favourite Git Commit

#34

Post by codegladiator »

Darkstryder wrote: post #31
tomashubelbauer wrote: post #17

I do feel like Git commit descriptions are severely under-utilised for sure, but I believe there is a reason for that which until fixed, will prevent rich and contentful commit descriptions for flourishing. In the article order: the screenshot is from a commit detail page. How often do you land on this page? You need to specifically click through. If you are in a commit list, the only thing that sets title-only commi…

In the same vein, I wish there would be a standard workflow for putting code inside commit logs. The typical use case would be database migration scripts : IMO they are always a pain to version properly because fundamentally Git and all the other software versioning tools let you describe the "nodes" (in the graph theory sense of the word) of a codebase ("at commit A the code was in this state, at commit B it was in…

> when it comes to describe the edges between nodes ("in order to go from state A to state B, you need to execute this code")

Isn't that what a patch file gives ?

Re: My Favourite Git Commit

#35

Post by esotericn »

Darkstryder wrote: post #31
tomashubelbauer wrote: post #17

I do feel like Git commit descriptions are severely under-utilised for sure, but I believe there is a reason for that which until fixed, will prevent rich and contentful commit descriptions for flourishing. In the article order: the screenshot is from a commit detail page. How often do you land on this page? You need to specifically click through. If you are in a commit list, the only thing that sets title-only commi…

In the same vein, I wish there would be a standard workflow for putting code inside commit logs. The typical use case would be database migration scripts : IMO they are always a pain to version properly because fundamentally Git and all the other software versioning tools let you describe the "nodes" (in the graph theory sense of the word) of a codebase ("at commit A the code was in this state, at commit B it was in…

Strongly agree. I run into this a lot with stuff like style commits. You want to ensure that a change hasn't slipped under the radar.

I tend to go for something like:

This commit was generated.

It would be super awesome to have a tool that easily verifies that A->B can actually be reproducibly accomplished by performing the actions in the commit message.

Re: My Favourite Git Commit

#36

Post by esotericn »

codegladiator wrote: post #34
Darkstryder wrote: post #31

Earlier quoted context omitted.

In the same vein, I wish there would be a standard workflow for putting code inside commit logs. The typical use case would be database migration scripts : IMO they are always a pain to version properly because fundamentally Git and all the other software versioning tools let you describe the "nodes" (in the graph theory sense of the word) of a codebase ("at commit A the code was in this state, at commit B it was in…

> when it comes to describe the edges between nodes ("in order to go from state A to state B, you need to execute this code") Isn't that what a patch file gives ?

The patch file gives the output of the execution of the code.

A basic example would be - run 'find -name '*.py' -execdir sed -i 's/foo/bar/g' +' on a repo, and commit the result.

For those not familiar with POSIX shell stuff, that will find and replace 'foo' with 'bar' across the repo.

The command is far more understandable at a glance than the patch (commit) and is far more likely to be reviewed properly.

Re: My Favourite Git Commit

#37

Post by Darkstryder »

codegladiator wrote: post #34
Darkstryder wrote: post #31

Earlier quoted context omitted.

In the same vein, I wish there would be a standard workflow for putting code inside commit logs. The typical use case would be database migration scripts : IMO they are always a pain to version properly because fundamentally Git and all the other software versioning tools let you describe the "nodes" (in the graph theory sense of the word) of a codebase ("at commit A the code was in this state, at commit B it was in…

> when it comes to describe the edges between nodes ("in order to go from state A to state B, you need to execute this code") Isn't that what a patch file gives ?

Sometimes no. For instance a database migration script is not equivalent to the diff between two database creation scripts.

While it should be possible to take a database creation script (state A) and a database migration script (edge A->B) and infer the new resulting database creation script (state B), the reverse is not true.

This is the tables vs events duality described in this great article : https://engineering.linkedin.com/distributed-systems/log-wha...

Re: My Favourite Git Commit

#38

Post by misnome »

drej wrote: post #33

This reminds of a Markdown issue I've had many many many times - sometimes (and only in some engines), headings would not render and I'd only get '# foobar' instead of ' ...' It took too long for me to track the issue. When I write '#' using alt-3, I then write a space and oftentimes I don't lift alt soon enough and alt-space creates a non-breaking space (on macOS). And some/most Markdown engines don't recognise '#nb…

This happened to me all the time, especially with python2 code without encoding declared (which caused a failure to parse the file because of the comment).

I’ve since switched my editors to highlight such characters.

Re: My Favourite Git Commit

#39

Post by clinta »

codegladiator wrote: post #11

Should have been in a doc or wiki instead of commit message. I have never seen any dev searching for error messages in commit messages. For the rest of the points (makes smarter, builds trust and compassion), if it's so worthy put it on the blog (like this blog post itself) so it can has a potential to reach some reach some audiance.

I think this should have been an issue. Open an issue with the original error, document the troubleshooting in the comments of the issue, then close the issue with the commit.

Re: My Favourite Git Commit

#40

Post by crdoconnor »

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.

As close to the code as possible means a code comment, not a commit message.
Post reply on HN