djwonk

There are many ways to name commits in git. For example:

$ git show HEAD^ # the parent of the HEAD commit

This made me hope that there was an analog for finding an immediate child. I did not see any evidence of this in the docs. So I went on the git IRC room and engaged in a discussion.

I suggested using a syntax such as HEAD$ — inspired by regular expressions, which use ^ to match the beginning of a line and $ to match the end of a line. I got a lot of pushback along the lines of (1) “this can’t be sanely done” or (2) “I don’t see why this would be useful.”

1. “This can’t be sanely done”

I don’t believe it. I’m sure the git community has solved far harder problems already. Git stores a repository as a directed acyclic graph and it is easy to lookup a parent. Traversing to a child is more expensive (but probably not prohibitively expensive.) With some caching and incremental updating, looking up a child should not be very costly. This is an interesting discussion to have — and there are lots of salient details that we can talk about in the comments — but ultimately this is a matter of ‘how to do it’ not ‘if it can be done’.

2. “I don’t see why this would be useful”

I have mixed feelings about this statement. I understand that building software is about choices, and open source software is often about scratching your own itches. So I can understand why a person might say, “I wouldn’t use the child style syntax, so why should I care about it?” Indifference is one thing: it is perhaps natural. But sometimes people take indifference a step further and also say that the idea is not of value to the community — this is flawed. In any case, broad concepts of user interface symmetry and beauty have more gravitas than one-off individual preferences.

Design should drive implementation

Git is unnecessarily complicated to new users. Parts of the git community do not grok the importance of the user perspective. Symmetry and beauty are not just nice to have: they are essential drivers for API design. A good API design goes a long way in enhancing the user experience.

The intrinsic worth of symmetry

The discussion was interesting and civil but somewhat unsatisfying because there was an elephant in the room: the importance of symmetry as a fundamental concept. Sometimes I see things as symmetrical or beautiful and others just don’t. I will try to explain.

Symmetry in user interface design can be defended on psychological or linguistic grounds. Humans think in opposites. Hot and cold. Parent and child. Love and hate. Don’t let ‘opposite’ throw you — the ‘opposite’ relationship is a very strong cognitive link.

Once an API lets you find a parent, it won’t be long before a user asks for the ability to find the child. Big surprise! Opposites are just part of how humans think. My suggestion: when people ask for symmetry, give it to them whenever you can.

It is expensive to try to fight that expectation. So don’t. Build great software for people. Don’t propagate the status quo by holding onto your current view of the software as being ‘good enough.’

Instead, admit that your API has a little flaw (of asymmetry) and take an objective look at what can be done about it. Remember: API design is more important than implementation details; so change the implementation as needed.

Don’t try to convince users that their intuition is wrong; instead, build a better user experience so that their intuition is right. As the application designer, you have the ability to frame concepts as you see fit. Frame them so the opposites make sense and everyone will be better off.

Conclusion

Neither pushback #1 nor #2 convinced me. I suspect they are veneers; the real reason seems to be: (3) “we have more important things to work on”. There is nothing wrong with saying that, but I find it interesting when people do not admit it up front. It seems like a defense mechanism.

I am hoping to bring a few more eyes to an equality bug I found in MongoMapper:


p1 = Post.new
p2 = p1.dup
p1 == p2 # => true
# so far so good
p2.title = 'changed'
p1 == p2 # => false
# uh-oh!


If you want to see chaos, please join us for a spirited mailing list discussion. Despite my best efforts, it seems to be spiraling out of control.

Update as of 5:55pm: ActiveRecord gets it wrong, too, but in a different way:


p1 = Post.new
p2 = p1.dup
p1 == p2 # => false
# drat!
p2.title = 'changed'
p1 == p2 # => false
# double drat!


Update as of 6:08pm: DataMapper is the only one that gets it right:


p1 = Post.new
p2 = p1.dup
p1 == p2 # => true
# yay!
p2.title = "x"
p1 == p2 # => false
# yay!


Just a few minutes ago, I wanted to take a look at HAppS, a Web server written in Haskell. I tried checking out HAppS-HTTP using the directions on the front page:
darcs get --partial --tag=0.9.2 http://happs.org/repos/HAppS-HTTP

Unfortunately, this failed with this error message:

darcs: failed to read patch:
Tue Dec 18 14:22:39 EST 2007 alex@happs.org
tagged 0.9.1.2
/Users/david/src/HAppS-HTTP/_darcs/patches/20071218192239-49c54-88c23fec4a12830b80c79ff71af2341d7cc59e1e.gz: openBinaryFile: does not exist (No such file or directory)

This is kind of sad. I’d like to check out HAppS, but I can’t even download it! This is not a good first introduction to a code base. :/

Please give this a try. If it fails for you too, please make a note here on ticket #39 in the issue tracker. Thanks!

I just read a cool idea from the Git Internals PDF by Scott Chacon on page 33. If you don’t know how well a merge might work, just create a new branch and try the merge there. If it works, it will be easy enough to merge into your master branch as a next step.

Something that Mr. Chacon didn’t mention (at least not in the vicinity of page 33) is that there is a –no-commit flag on the git merge command:


--no-commit
Perform the merge but pretend the merge failed and do not
autocommit, to give the user a chance to inspect and further tweak
the merge result before committing.


Remote then Local

It is easy to setup a local branch (we’ll call it zzz here) to track a pre-existing remote branch:

$ git --track branch zzz origin/zzz

Alternately, if you use the branch.autosetupmerge setting in your git config to enable automatic branch tracking [1], the command is even shorter:

$ git branch zzz origin/zzz

Local then Remote (reverse)

This much is easy. But what about the reverse? In other words, how do you start with a local branch, push to a remote, and have the local track the remote?

Take One

Let’s give it a try. A warning: it isn’t quite as easy as you might hope.

$ git branch zzz
$ git checkout zzz
# make some changes to files ...
$ git push origin zzz
$ git pull origin zzz

The explicit form of git pull above works. But the shorter form “git pull” is easier, but when we try it we get an error message (but at least it is helpful):

$ git pull
From git@my-server.com:my_project
 * [new branch]      zzz -> origin/zzz
You asked me to pull without telling me which branch you
want to merge with, and 'branch.zzz.merge' in
your configuration file does not tell me either.	Please
specify which branch you want to merge on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details.

If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:
    branch.zzz.remote = <nickname>
    branch.zzz.merge = <remote-ref>
    remote.<nickname>.url = <url>
    remote.<nickname>.fetch = <refspec>

See git-config(1) for details.

Adding those lines to the git config file by hand is doable, but not very elegant. You might rather use the command line way:

git config branch.zzz.remote origin
git config branch.zzz.merge refs/heads/zzz
# Note: I'm assuming you already have "origin" setup
# as a remote, so I don't include those commands here.

The latter way lends itself to scripting better than the former. Still, I wasn’t really satisfied with either approach.

Take Two

So I was curious to see if there are other ways to start with a local branch then create a remote branch and have automatic tracking. I did some searching and read over the following blog posts:

• Start a New Branch on your Remote Git Repository by Geoff Lane
• Pushing and Tracking Remote Branches with Git by Mark Eli Kalderon
• Git Push – Just the Tip by Rein Henrichs
• Improving my Git Workflow by Trevor Squires
• Git Branch Auto Tracking by Mike Champion

There was considerable diversity in the solutions presented.

Take Three

In my opinion, Mark Eli Kalderon’s post explains the simplest and most elegant approach. Here is his approach, slightly adapted:

$ git checkout -b zzz
# Let the hacking commence...
$ git push origin zzz
$ git checkout master # see note 2
$ git branch -f zzz origin/zzz
$ git checkout zzz
# Let the hacking continue...

The key to this approach is using the “-f” flag with “git branch” to force the re-creation of the local branch. It is short and easy to remember. If you find something simpler, please share it. Thanks.

Notes

1. To enable automatic branch tracking globally, use:
   

   $ git config --global branch.autosetupmerge true
   

   To do it for a specific repository, use:

   $ git config branch.autosetupmerge true
   

2. I added the “git checkout master” because otherwise the “git branch -f …” line would fail with this message: “fatal: Cannot force update the current branch.”
3. It probably doesn’t matter for the purposes of this discussion, but I’m using git 1.6.2.3 installed via MacPorts (“sudo port install git-core”).