#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

curl -X GET \
  -H "Content-type: application/json" \
  -H "Accept: application/json" \
  "https://octothorp.es/~/git"