Hacker News Reader

Comment by Darkstryder | Hacker News Reader

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.

View on HN

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.

A few version control systems are change-based rather than snapshot-based — darcs¹ and pijul² that I know of.

¹ http://darcs.net/

² https://pijul.org/

> 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...

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.

How do DB migrations relate to the source control graph?

It seems you're implying the codebase changed as a result of a script that itself is not source controlled. I can think of style commits falling in this category, like one of the children of this comment mentions, but DB migrations don't seem to be related.

Reply on news.ycombinator.com