Every DVCS only pulls the unique changes. It’s like the definition of a DVCS.

Anyway, I agree that object longevity is interesting in git, but it’s really not anything that I think most users would need to concern themselves with.

With usual usually, git-gc, the packing step only compresses. It removes nothing. Which means that even objects that you have removed totally (changes from a branch that you never merged in, and you deleted the branch), they don’t expire. The future auto-packing “git gc –auto” or the standard packing “git gc” won’t remove these objects. There is a second step that needs to be taken.. “git gc –purge”. Even then, only unreachable objects will be removed. Git has another feature– the reflog. The reflog is a very special “branch” since it records each position of HEAD in the last 30 days (by default). So removed branches won’t be purged by purge until after waiting for 30 days, when the last reference to them will finally be released.

I use stgit continuously. stgit is designed for managing patch series like you see posted to lkml. It allows you to edit them, regenerate the series, and rebase to a new kernel version. quilt is similar and not based on a specific VCS. If your patches need public review you want to be using one of these systems.

The visualization tools are nice too.

Another important git feature is bisect. Bisect does a binary search in the commits to track down the one that caused the bug. This is a very useful feature, I’m not sure if any other VCS has it.

I believe the latest git versions nag you at commit time if a ‘git gc’ would help. ‘git gc’ isn’t really critical, who cares is git is using 100MB more disk that it has to. If it bothers you type ‘git gc’. It doesn’t significantly change the performance of git, it just reduces the disk space needs.

Another fairly unique git feature is remotes. ‘git add remote linus git://linusrepo’ You can add all of the kernel repositories from other developers to your remotes. ‘git fetch remote’ pulls down the changes. What is neat about this is that git figures out all of the common commits between the repos and only pulls down the unique changes. After you fetch them use ‘git merge’ to bring them into your local branch.

If using stgit:
git fetch linus (pull down the change’s from Linus’ repo)
stg rebase linus/master (merge in linus’ changes and fix up your patches to apply on them)
stg export (export the patch set to disk or directly email it to lkml)

Another git trick:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git digispeaker
cd digispeaker
git config remote.origin.url http://git.digispeaker.com/projects/digispeaker-kernel.git
git pull

In this trick you pull in all of the kernel history from the high speed servers at kernel.org (or your local server). You then switch servers and pull in only my changes from my slow hosting provider.

Of course if you already have a local kernel repo just add digispeaker as a remote and it will download in a few seconds.

if that is the case, then I think hg is just as good as git, just that it doesn’t force you to run any “hg gc” once in a time

[1] commit d4bb43ee273528064192848165f93f8fc3512be1