Git Un-Merge

When I last merged a development branch of add-rel-lightbox into the master branch and realised that I’d not finished testing the changes, it was off to the internet to find out how to undo a merge. After a couple of goes at git revert -m 1 refused to do anything, and a little more searching, I found out that there are two types of merge: a Commit Merge and a Fast-Forward merge.

Once it was clear what happened during a merge, it was much easier to see how to go about undoing the change.

Commit Merge

Commit Merge
Commit Merge

When development has taken place on both branches before the merge operation, git has to create a new commit that mixes the changes.

Git will automatically try to make a commit, but using git merge -n (branch_name) or having merge conflicts will leave you to make a manual commit.

Fast-Forward Merge

Fast-Forward Merge
Fast-Forward Merge

If there’s only development in one branch, then when you make the merge, git will just update the head position for the receiving branch. The merging branch is then a sub-set of the history if the recipient branch.
Continue reading Git Un-Merge

LaTeX-SVG-to-PDF as git submodule

I’ve mentioned previously that I’ve got a large project in \(\LaTeX\) and while I was using Dropbox as a pseudo revision control and external backup. However, I’ve since been persuaded that a proper revision control system with meaningful commit message is a better way of tracking progress and changes.

So I’ve moved the project to git, set up a remote repository for synchronisation and backup and started making commits. Then I realised that my symlinked makefile was only included as a link in the git repository. This is different to Dropbox, which would synchronise the contents of the linked file.

Instead of just having a symbolic link to a file that might not exist on another computer, I needed another way of including the file properly. I could just drop the file into the git repository, but then it won’t update if I make any changes to the main project files. If I make use a hard link then git will include the file contents, but then it’s possible to make tracked changes in the \(\LaTeX\) project repository by changing the file in its original repository — and that is just a recipe for confusion.

Instead, it’s probably better to include the makefile repository as a git submodule and then symlink into the sub-repository’s makefile. That way, the exact commit information is included in the parent-repo, but the sub-repo can be updated, changed and branched as needed.

To do this:

cd ~/LaTeX/project/folder
git submodule add git://
rm makefile # if you already have a makefile in the directory 
ln -s LaTeX-SVG-to-PDF/makefile makefile
git add .
git commit -m "added LaTeX-SVG-to-PDF as submodule and linked to makefile"

There are a couple of complications to this method:

If you clone a new local repository of the parent project then you also have to initiate and update the submodules to add their contents.

git clone my@server:git/project.git
cd project
git submodule update --init

And you also need to be careful of including changes to the sub-repos. If you git add . && git commit to the parent-repo with uncommitted changes to the sub-repo, then you’ll be telling the parent-repo to use that dirty head on every clone — not good.

If you’ve made changes to the sub-repo, make sure that these are committed (and pushed) before commiting on the parent-repo.

LaTeX-SVG-to-PDF makefile project source and download.

Putting Dotfiles in Git

If you’re a Windows user, then you probably won’t have come across dotfiles before. For Mac (a form of Unix) and Linux users, dotfiles hold certain environmental settings and customisations, so if you work on more than one computer, you might like a way of sharing your preferences between them.

And they’re called “dotfiles” because any filename that begins with a full stop (period) is a hidden file in Unix, Linux, etc.

Since I started using vim for text editing and made some tweaks to my .vimrc file and added some plugins (pathogen, vim-fugitive and vim-latex), I quickly realised that I’d like to be able to take these settings with me, so I started looking at keeping the configuration files in version control.

Now there are any number of dotfile repositories on github and many, many guides on setting up your dotfiles with git, but I noticed that there were two main arrangements, but the pros and cons of each arrangement seemed to be spread out around the web.

  1. Put your whole home directory into revision control and track only a few files.
  2. Add a dotfiles subfolder in your home directory that is under version control, move in the files that you want to track and symlink them back to the original location.

Which one to choose? I tried both, but I like the second best.

Why? See below: Continue reading Putting Dotfiles in Git

git workflow for self-updating sites


How to Use Revision Control When Your Site Can Make Changes to it’s Own Files

I’m assuming that you have setup git on a shared server, and resolved any git-upload and git-receive errors.

There are two ways to making changes to the website’s files:

  1. Web side changes: The site is updated or file attachments are uploaded.
  2. Offline changes: You make file changes (eg. theme changes or plugin adjustments) and then upload them to your web space.

Because manual integration and merging is a “disaster that you just haven’t had yet”, how is it possible to keep both sets of changes easily combined? Revision control; using git’s merging tools and distributed repository structure to keep everthing running smoothly.

Basically I’m using one bare repository as the master copy (hub repository) and automatically pull from and push to the live website folder (prime repository), while allowing remote access with manual push/pulls to make offline code adjustments (in working clones) that are pushed to the live directory automatically. All the while using git to flag up the commit problems for manual merging, so the live site never gets borked by a outdated overwrite. Continue reading git workflow for self-updating sites