Introduction
Like almost all professional programmers I have been using the Git version control system for a long time now. Besides Git, I have been using Mercurial and Fossil (though Fossil only for personal projects). Some of Git's features have escaped my attention until recently and maybe this list of (so far) three short topics can help others who missed the same documentation entries as I did.
Author: David Heiko Kolf, 2026-02-23.
Cloning and pulling over static HTTP
For several years I used to have Fossil running as a CGI application on my website, which provided a convenient, easy to install way to synchronize my projects. However, having a complex program constantly available in public worried me quite a bit, especially as I might not always have the time to care about updates. So I removed it again and replaced the content with static release files and web pages. The static files also have the additional benefit that they are not as resource-intense when confronted with misbehaving crawlers as dynamic web pages would be.
If I had used Git for these projects, I could have just published repositories as plain files and other people could still synchronize with the project using the "dumb http" mode of Git.
Worktrees for code reviews
At work I often have to deal with multiple checkouts at the same time: The one where I am making my own changes, others where I am doing code reviews, and further ones where I am reviewing bug reports on release tags. With Fossil I knew I could just open multiple folders for the same repository, but with Git I actually cloned the repository multiple times, even when the history had a significant file size.
This would not have been necessary however: Git also supports multiple checkouts for the same repository with the "git worktree" command.
Shallow clones for data protection
We once switched the contractor for a project and I was worried about the Git history created by the previous contractor: It contained the names of the employees who were assigned to our project and the timestamps of when they were at work. This might be data protected by law and I would not be allowed to pass it on to other people. In order to get the job done I just copied all the files into a new repository, which was a complete break with the previous history.
But there would have been a better solution: I could have made a shallow
clone using the command git clone --no-local --depth 1 [origin]
[target]. The cloned repository would have just contained the
latest commit, which I could have created for this purpose. It would be
displayed as "grafted". The new contractor could have worked on it and I
would have been able to merge their new commits into a complete history.
A praise for Git
While I am not always happy about some design choices of Git (which will probably be a future article), its strengths and the workflows it enables are good reasons for its popularity.