Work continues on “Project: Leaflet” and when I last left off [1], I mentioned that git [2] is nearly perfect for handling the fine-grained revision control [3].
I'm here to report—it is.
The ability to make changes to one version of “Project: Leaflet” (say, the MySQL [4] version) and then selectively merge changes into the other version (in this case, the PostgreSQL [5] version) isn't that bad with git.
I currently have three respositories for “Project: Leaflet”—the “master” repository with two branches, one for the MySQL version, and one for the PostgreSQL version; another one that's my working MySQL repository, and the third that's the working PostgreSQL version.
The workflow isn't that bad. I make changes on one of the work repositories, say, the MySQL version:
>
```
mysql-work> vi somefile.c # make changes, test, etc
mysql-work> git commit -a # have working version, commit changes
```
Then, when done there, I go to the master repository:
>
```
master> git checkout mysql
Switched to branch "mysql"
master> git pull server-path-to-mysql-work
[ bunch of output ]
master> git log >/tmp/changes
master> git checkout postgresql
Switched to branch "postgresql"
```
I then view the changes made, and pick which commits I want to merge:
>
```
master> git cherry-pick f290b3e50e4cea1c3ee5e5265faa996943ef8542
# that large value is the ID of the commit
# I pick the ones that apply
[ bunch of output ]
master> git cherry-pick 574756ffaa10cdc8452b33bf3d0ab8b786395080
[ bunch of output ]
```
Then go to the other work repository, and pull the now-merged changes:
>
```
postgresql-work> git pull server-path-to-master
[ bunch of output ]
postgresql-work> vi somefile.c # make any non-portable changes,
postgresql-work> git commit -a # tests, etc,
```
And then back to the master to pull back the PostgreSQL changes and any non-specific merges that may have come up. I could probably make it smoother, as git is also a revision control toolkit, but as of yet, it's not yet annoying enough to warrant the work.