Background

You might say, "why not just use git to take care of this," which is fair. The truth is that I don't really care about the histories as long as there's revision. Here's the situation:

I keep a personal ikiwiki instance for all of my notes, tasks, and project stuff. There's nothing revolutionary, and I even use deft, dired, and some hacked up lisp to do most of the work. But I also work on a lot of projects that have their own git repositories and I want to be able to track the notes of some of those files in those repositories as well.

Conflicts.

There are some possible solutions:

1. Use hard links so that both files will point at the same data on disk.

Great idea, but it breaks on multiple systems. Even if it might have worked in this case, it freight ens me to have such fragile systems.

Note: the more I play with this, the less suitable I think that it might be for multi system use. If one or both of the sides is in a git repo, and you make changes locally and then pull changes in from a git upstream, the git files, may look newer than the files that you changed. A flaw.

2. Only edit files in one repository or the other, and have a pre-commit hook, or similar, that copies data from the new system to the old system.

I rejected this because I thought I'd have a hard time enforcing this behavior.

3. Write a script that uses some diff3 to merge (potential) changes from both sources of changes.

This is what I did.

The script actually uses the merge command which is a wrapper around diff3 from rcs. shrug.

Beyond my somewhat trivial and weird use-case, I actually think that this script is more useful for the following situation:

You use services like Dropbox as a way of getting data onto mobile devices (say,) but you want the canonical version of the file to live in a git repository on your system.

This is the script for you.

I hope you enjoy it!

See Staged Differences

The git diff command shows you the difference between the last commit and the state of the current working directory. That's really useful and you might not use it as much as you should. The --cached option shows you just the differences that you've staged.

This provides a way to preview your own patch, to make sure everything is in order. Crazy useful. See below for the example:

git diff --cached

Eliminate Merge Commits

In most cases, if two or more people publish commits to a shard repository, and everyone commits to remote repositories more frequently then they publish changes, when they pull, git has to make "meta commits" that make it possible to view a branching (i.e. "tree-like") commit history in a linear form. This is good for making sure that the tool works, but it's kind of messy, and you get histories with these artificial events in them that you really ought to remove (but no one does.) The "--rebase" option to "git pull" does this automatically and subtally rewrites your own history in such a way as to remove the need for merge commits. It's way clever and it works. Use the following command:

git pull --rebase

There are caveats:

• You can't have uncommitted changes in your working copy when you run this command or else it will refuse to run. Make sure everything's committed, or use "git stash"
• Sometimes the output isn't as clear as you'd want it to be, particularly when things don't go right. If you don't feel comfortable rescuing yourself in a hairy git rebase, you might want to avoid this one.
• If the merge isn't clean, there has to be a merge commit anyway I believe.

Amend the Last Commit

This is a recent one for me..

If you commit something, but realized that you forgot to save one file, use the "--amend" switch (as below) and you get to add whatever changes you have staged to the previous commit.

git commit --amend

Note: if you amend a commit that you've published, you might have to do a forced update (i.e. git push -f) which can mess with the state of your collaborators and your remote repository.

Stage all of Current State

I've been using a versing of this function for years now as part of my download mail scheme. For some reason in my head, it's called "readd." In any case, the effect of this is simple:

• If a file is deleted from the working copy of the repository, remove it (git rm) from the next commit.
• Add all changes in the working copy to the next commit.

git-stage-all(){
   if [ "`git ls-files -d | wc -l`" -gt "0" ]; then; git rm --quiet `git ls-files -d`; fi
   git add .
}

So the truth of the matter is that you probably don't want to be this blasé about commits, but it's a great time saver if you use the rm/mv/cp commands on a git repo, and want to commit those changes, or a have a lot of small files that you want to process in one way and then snapshot the tree with git.

Editor Integration

The chances are that your text editor has some kind of git integration that makes it possible to interact with git without needing to drop into a shell.

If you use something other than emacs I leave this as an exercise for the reader. If you use emacs, get "magit," possibly from your distribution's repository, or from the upstream.

As an aside you probably want to add the following to your .emacs somewhere.

(setq magit-save-some-buffers nil)
(add-hook 'before-save-hook 'delete-trailing-whitespace)

Custom Git Command Aliases

In your user account's "~/.gitconfig" file or in a per-repository ".git/config" file, it's possible to define aliases that add bits of functionality to your git command. This is useful defining shortcuts, combinations, and for triggering arbitrary scripts. Consider the following:

[alias]
all-push  = "!git push origin master; git push secondary master"
secondary = "!git push secondary master"

Then from the command line, you can use:

git secondary
git all-push

Git Stash

"git stash" takes all of the staged changes and stores them away somewhere. This is useful if you want to break apart a number of changes into several commits, or have changes that you don't want to get rid of (i.e. "git reset") but also don't want to commit. "git stash" puts staged changes onto the stash and "git stash pop" applies the changes to the current working copy. It operates as a FILO stack (e.g. "First In, Last Out") stack in the default operation.

To be honest, I'm not a git stash power user. For me it's just a stack that I put patches on and pull them off later. Apparently it's possible to pop things off the stash in any order you like, and I'm sure I'm missing other subtlety.

Everyone has room for growth.

Ignore Files

You can add files and directories to a .gitignore file in the top level of your repository, and git will automatically ignore these files. One "ignore pattern" per line, and it's possible to use shell-style globing.

This is great to avoid accidentally committing temporary files, but I also sometimes put entire sub-directories if I need to nest git repositories within git-repositories. Technically, you ought to use git's submodule support for this, but this is easier. Here's the list of temporary files that I use:

.DS_Store
*.swp
*~
\#*#
.#*
\#*
*fasl
*aux
*log

Host Your Own Remotes

I've only once accidentally said "git" when I meant "github" (or vice versa) once or twice. With github providing public git-hosting services and a great compliment of additional tooling, it's easy forget how easy it is to host your own git repositories.

The problem is that, aside from making git dependent on one vendor, this ignores the "distributed" parts of git and all of the independence and flexibility that comes with that. If you're familiar with how Linux/GNU/Unix works, git hosting is entirely paradigmatic.

Issue the following commands to create a repository:

mkdir -p /srv/git/repo.git
cd /srv/git/repo.git
git init --bare

Edit the .git/config file in your existing repository to include a remote block that resembles the following:

[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = [username]@[hostname]:/srv/git/repo.git

If you already have a remote named origin, change the occurrence of the word remote in the above snippet with the name of your remote. (In multi-remote situations, I prefer to use descriptive identifier like "public" or machine's hostnames.)

Then issue "git push origin master" on the local machine, and you're good. You can us a command in the following form to clone this repository at any time.

git clone [username]@[hostname]:/srv/git/repo.git

Does anyone have git tricks that they'd like to share with the group?

The Staging Area

The state of every committed object (i.e. file) as of the last commit is the HEAD. Every commit has a unique identifying hash that you can see when you run git log.

The working tree, or checkout, is the files you interact with inside of the local repository. You can checkout different branches, so that you're not working in the "master" (default or trunk) branch of the repository, which is mostly an issue when collaborating with other people.

If you want to commit something to the repository, it must first be "staged" or added with the git add command. Use git status to see what files are staged and what files are not staged. The output of git diff generates the difference between the HEAD plus all staged changes, and all unstaged changes. To see the difference between all staged changes and HEAD use the "git diff --cached".

The staging area makes it possible to construct commits in very granular sorts of ways. The staging area makes it possible to use commits, less like "snapshots" of the entire tree of a repository, and rather as discrete objects with that contain a single atomic change set. This relationship to commits is enhanced by the ability to do "squash merges" and squash a series of commits in a rebase, but it starts with the staging area.

If you've staged files incorrectly you can use the git reset command to reset this process. Used alone, reset is a non destructive operation.

Branches

The ability to work effectively in branches is the fundamental function of git, and probably also the easiest to be confused by. A branch in git, fundamentally, is just a different HEAD in the same repository. Branches within a single repository allow you to work on specific sets of changes (e.g. "topics") and track other people's changes, without needing to make modifications to the "master" or default branch of the repository.

The major confusion of branches springs from git's ability to treat every branch of every potentially related repository as a branch of each other. Therefore it's possible to push to and pull from multiple remote branches from a single remote repository and to push to and pull from multiple repositories. Ignore this for a moment (or several) and remember:

A branch just means your local repository has more than one "HEAD" against which you can create commits and "diff" your working checkout. When something happens in one of these branches that's worth saving or preserving or sharing, you can either publish this branch or merge it into the "master" branch, and publishes these changes.

The goal of git is to construct a sequence of commits that represent the progress of a project. Branches are a tool that allow you to isolate changes within tree's until you're ready to merge them together. When the differences between HEAD and your working copy becomes to difficult to manage using git add and git reset, create a branch and go from there.

Rebase

Rebasing git repositories is scary, because the operation forces you to rewrite the history of a repository to "cherry pick" and reorder commits in a way leads to a useful progression and collection of atomic moments in a project's history. As opposed to the tools that git replaces, "the git way" suggests that one ought to "commit often" because all commits are local operations, and this makes it possible to use the commit history to facilitate experimentation and very small change sets that the author of a body of code (or text!) can revert or amend over time.

Rebasing, allows you to take the past history objects, presumably created frequently during the process of working (i.e. to save a current state) and compress this history into a set of changes (patches) that reflect a more usable history once the focus of work has moved on. I've read and heard objects to git on the basis that it allows developers to "rewrite history," and individuals shouldn't be able to perform destructive operations on the history of a repository. The answer to this is twofold:

• Git, and version control isn't necessarily supposed to provide an consistently reliable history of a projects code. It's supposed to manage the code, and provide useful tools to managing and using the history of a project. Because of the way the staging area works, sometimes commits are made out of order or a "logical history object" is split into two actual objects. Rebasing makes these non-issues.
• Features like rebasing are really intended to happen before commits are published, in most cases. Developers will make a series of commits and then, while still working locally, rebase the repository to build a useful history and then publish those changes to his collaborators. So it's not so much that rebasing allows or encourages revisionist histories, but that it allows developers to control the state of their present or the relative near future.

Bonus: The git stash

The git stash isn't so much a concept that's difficult to grasp, but a tool for interacting with the features describe above that is pretty easy to get. Imagine one of the following cases:

You're making changes to a repository, you're not ready to commit, but someone writes you an email, and says that they need you to quickly change 10 or 12 strings in a couple of files (some of which you're in the middle of editing,) and they need this change published very soon. You can't commit what you've edited as that might break something you're unwilling to risk breaking. How do you make the changes you need to make without committing your in-progress changes?

You're working in a topic branch, you've changed a number of files, and suddenly realized that you need to be working in a different branch. You can't commit your changes and merge them into the branch you need to be using that would disrupt the history of that branch. How do you save current changes and then import them to another branch without committing?

Basically invoke git stash which saves the difference between the index (e.g. HEAD) and the current state of the working directory. Then do whatever you need to do (change branches, pull new changes, do some other work,) and then invoke git stash pop and everything that was included in your stash will be applied to the new working copy. It's sort of like a temporary commit. There's a lot of additional functionality within git stash but, that's an entirely distinct bag of worms.

Onward and Upward!

The Context

• git writing on wikish.
• haikus in git
• writing like a programer
• git thoughts

git is this version control system that's designed to be used in a distributed manner, and supports a very divers and non-linear workflow. While it's designed to support the work of software developers--particularly in large projects like the linux kernel--at the core, git is just a file system layer that has an awareness of time and iteration. It also does its magic on any kind of text files... code or writing. I use git to manage a lot of my writing--indeed, most of my digital life, which is a bit weird admittedly; and as a result people on the Internet, not to mention my coworkers,come to me with git questions from time. This post is a response to a more recent change.

How I Work

I have two kinds of repositories: general repositories which store a bunch of different kinds of files that I need to work: the general repositories that store files that I always need to get things done, and specific project-only repositories that only have the text (and possibly notes) for a very specific project. I also have a "writing" repository where I do drafting for the blog, and start writing projects that I'd like to version, but are too small yet for their own project repositories. The brief overview:

• garen is like my home directory within my home directory, and it has config files, scripts. and other daily essentials.
• org stores my org-mode files.
• fiction projects: I have five repositories in ~/ that store fiction projects, that I'm theoretically working on in some capacity, though I haven't touched most of them regularly.
• writing holds blog drafting, and a couple of not-exactly-fiction, projects that I'm not quite ready to admit exist.
• website content: wikish, tychoish.com, cyborginstitute.com, the cyborg institute wiki and a few other website projects that I'm involved with have repositories to store their content.

The lesson here, about repository organization, is that git wants you to have distinct repositories for different projects. Its possible to merge repositories together (really!) and also to separate the histories of specific directories into their own repositories if you're so inclined.

I write in emacs almost exclusively, I sometimes use magit, which is a delightful interface to git that works within emacs in a very emacs-centric way. If you use dired, magit will be familiar. Having said that, I mostly just add files, make commits and push repositories. Although I've been very interested in flashbake for some time, I've never really used it: it seems designed for people who aren't used to version control or git, and the fact that I am means that it feels cumbersome to me. I suppose I should take this as a challenge, and attempt to hack it into something more usable from my perspective, but I've not felt the urge yet.

I use gitosis (but it's in the debian repositories) on foucault (my server) to manage the publication of my git repositories. I push regularly, both to make sure that all of my machines are up to date, and also as a way of keeping my systems backed up. While I don't take snapshots of my systems, I've been able to set up systems and been up and running inside of ninety minutes after reimaging a laptop without loosing a single bit. Although unorthodox, git is my backup strategy, and the restores work fine. I strongly recommend having your own git hosting set up. It's not difficult, and while I think git hub is awesome on it's own terms, independence and self sufficiency is really important here.

I don't really take advantage of any branching and merging in git, though I've played with it enough to know how it works. I do have a branch in the repository for the novel I'm writing for an editor to be able to edit the novel as I write on it without needing to see their changes and comments until I get to that point.

And that's sort of it. I use jekyll (or an old personal fork) and soon to be cyblog) as well as ikiwiki to publish content, but other than that, I just write stuff.

In any case, if you have thoughts on the subject I'd love to see your input on the wikish git writing page.

Write on!