Git's Lightweight Merging

one of git’s selling points, some years ago, was that it has lightweight branching compared tools that came before it. as it happens subversion was also launched with claimed lightweight branching compared to cvs. it’s just that git’s branches take that to another level.

anyway, it’s git’s merges that are the truly lightweight thing in my opinion. this article tries to show how that is.

merging back from a task branch with git

let’s make a single source file on master, make a branch for a task we’ve been assigned, change the file there, also change it on the master, then merge the task branch back to the master and delete the task branch:

#!/bin/sh
mkdir foo
cd foo
git init
echo "** create trunk version of file"
echo "efficiently unleash cross-media information without\nimmediate value. dramatically\nmaintain clicks-and-mortar solutions without\nfunctional aspects." > file.txt
git add file.txt
git commit -m "initial version on master"
sleep 2 
echo "** create temp branch .."
git branch task001 
git checkout task001 
echo "** a change on task001"
perl -p -i -e "s/immediate/any/g" file.txt
git commit -am "a change on the task001 branch"
sleep 2 
git checkout master 
echo "** modify master version of file"
perl -p -i -e "s/cross-media/socially-awkward/g" file.txt
git commit -am "different change on master made after the change on branch"
sleep 2 
echo "** merge temp task001 into master"
git merge -s ours task001 -m "merge task001 branch back into master"
git branch -d task001

after the event, the history looks like this:

each of those commits in git could have a separate code review. that is apart from the last one – the auto-merge that was merge task001 branch back into master and it has no diff associated with it. we have nothing review at the moment of merge in our test case. that’s the key take-away – there’s often no ceremony with the merge, and it’s truly lightweight.

the task branch made task001 is long gone (and was only a ‘local’ branch anyway), but the change made on it is retained. it doesn’t matter whether we keep the task branch or not in this case it does’t affect the merge history of the file. this is cool as it means your code review (if you’re reviewing commit by commit) is very efficient.

incidentally, the multiple sleep 2 statements in the script above allow us to compare the actual order of commits via timestamps, with the visualization of the history ( gitx in this case). 19:58:53 followed by 58 then 56 and the merge at 57. interesting (but not wrong in this representation).

trying the same thing with subversion

now we can’t play with local branches for a pure-subversion setup, so both trunk and the task branch task001 exist on the server. here’s the script that’s a subversion version of the git script above:

# $1 is the name of the repo served locally.
#!/bin/sh
svn --username harry --password harry checkout svn://127.0.0.1/$1
echo "** create trunk version of file"
echo "efficiently unleash cross-media information without\nimmediate value. dramatically\nmaintain clicks-and-mortar solutions without\nfunctional aspects." > $1/trunk/file.txt
svn add $1/trunk/file.txt
svn commit $1 -m "initial version on trunk"
sleep 2 
echo "** create temp branch .."
svn copy svn://127.0.0.1/$1/trunk svn://127.0.0.1/$1/branches/task001 -m "create branch"
svn up $1
echo "** a change on task001"
perl -p -i -e "s/immediate/any/g" $1/branches/task001/file.txt
svn commit $1 -m "a change on the task001 branch"
sleep 2 
echo "** modify trunk version of file"
perl -p -i -e "s/cross-media/socially-awkward/g" $1/trunk/file.txt
svn commit $1 -m "different change on trunk made after the change on branch"
svn up $1
sleep 2 
echo "** merge temp task001 into trunk"
svn merge svn://127.0.0.1/$1/branches/task001 $1/trunk
svn ci $1 -m "merge task001 branch back into trunk"

the crucial commit is the merge back from task001 to trunk . the last commit – #7. here’s what that looks like in crucible:

but here’s the change that happened on the branch (#5):

they look the same. if we’d done a code review for #5 (the change on the branch), and some time later a code review for #7 (the merge back to trunk) we’d be duplicating work previously done :-(

it’s fair to say that the merge back to trunk for the subversion and perforce from a task branch, isn’t lightweight. perforce is exactly the same. mercurial and plasticscm are as lightweight as git.