#git
- VCS-Enabled SQL Change Management
https://justatheory.com/2012/01/vcs-sql-change-management/
Some thoughts on how to use VCS history to determine what changes need to be deployed or reverted without relying on a configuration file.
- Migrating Bricolage CVS to Git
https://justatheory.com/2009/04/bricolage-cvs-to-git/
Following a discussion on the Bricolage developers mail list, I started down the path last week of migrating the Bricolage Subversion repository to Git. This turned out to be much more work than I expected, but to the benefit of the project, I think. Since I had a lot of questions about how to do certain things and how Git thinks about certain things, I wanted to record what I worked out here over the course of a few entries. Maybe it will help you manage your migration to Git.
- Sqitch — VCS-powered SQL Change Management
https://justatheory.com/2012/04/sqitch-draft/
Back in January, I wrote three posts outlining some ideas I had about a straight-forward, sane way of managing SQL change management. The idea revolved around specifying scripts to deploy and revert in a plan file, and generating that plan file from VCS history. I still feel pretty good about the ideas there, and work has agreed to let me write it and open-source it. Here is the first step making it happen. I call it “Sqitch.”
- SQL Change Management Sans Duplication
https://justatheory.com/2012/01/sql-change-management-sans-redundancy/
Here’s how I propose to eliminate the duplication of code between deploy and revert SQL change management scripts.
- How I configure my Git identities | benji
https://benji.dog/articles/git-config/
This may be overkill, but it works on my machine
Follow #git
on RSS or use the
JSON API
curl -X GET \
-H "Content-type: application/json" \
-H "Accept: application/json" \
"https://octothorp.es/~/git"