3 ms·

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

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.

codegladiator 7y ago
> 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 ?
- esotericn 7y ago
  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.
- Darkstryder 7y ago
  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-what-every-software-engineer-should-know-about-real-time-datas-unifying https://engineering.linkedin.com/distributed-systems/log-wha...
esotericn 7y ago
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. <shell script here> 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.
kps 7y ago
A few version control systems are change-based rather than snapshot-based — darcs¹ and pijul² that I know of. ¹ http://darcs.net/ http://darcs.net/ ² https://pijul.org/ https://pijul.org/
shrimpx 7y ago
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.

codegladiator 7y ago

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

esotericn 7y ago
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.
Darkstryder 7y ago
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-what-every-software-engineer-should-know-about-real-time-datas-unifying https://engineering.linkedin.com/distributed-systems/log-wha...

esotericn 7y ago

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. <shell script here> 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.

kps 7y ago

A few version control systems are change-based rather than snapshot-based — darcs¹ and pijul² that I know of. ¹ http://darcs.net/ http://darcs.net/ ² https://pijul.org/ https://pijul.org/

shrimpx 7y ago

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.