Wandering Thoughts archives


Pruning deleted remote Git branches (manually or automatically)

As someone who periodically wants to read the source code for various programs (and also a cautious person), I maintain a relatively large collection of copies of upstream Git repositories. These copies are for reference, not development, and I intend them to be more or less exact mirrors of the upstream original.

(Sometimes this means that I need to set 'git config pull.ff only' to avoid surprise merges if the upstream ever changes their history. Most upstreams don't ever do this, fortunately.)

Most upstreams that I mirror have a sparkly clean official public repository, where all of the branches are intended for long term official public consumption; any development branches or other short lived things aren't exposed through the official repo. But some do all of their development in their public tree, complete with short lived branches for features, bugfixes, issues being corrected, and so on. These repositories see a steady turnover of previously available branches being deleted. Well, they get deleted in the upstream official repository; if you just do a plain 'git pull', they don't get deleted in yours, and so until recently when I became aware of this, my mirrors had more or less all of the branches that had ever existed in the repos since I started mirroring them.

(How I discovered this issue is that one upstream reused a branch name they had previously deleted. When my regular 'git pull --ff-only' tried to pull their version of the branch, things complained.)

As the git fetch manpage covers, there are basically two ways to fix this. As a one-off command, I want:

git pull --prune --ff-only

(You can also do the 'git fetch --prune' version.)

But since this is likely to come up repeatedly for repositories that use branches like this, I really want to set this as an option in the repository so it happens on all future pulls, with:

git config fetch.prune true

(Reading the git fetch manpage tells me that I probably want to prune tags too for these repositories, although so far I haven't had any problems there.)

This is definitely something that I don't want to enable for all upstream repositories that I track because it allows upstreams to erase history on me (to put it strongly). Usually repos don't do this and usually I don't care about the history of branches, but some repos have long-lived branches that I care about and that I want to keep in my copy (possibly forever), regardless of the upstream's opinion. So currently I'm only turning it on for repos where I know they churn branches this way and that I'm sort of 'sure, whatever' about in general.

(If I cared a lot about this, I think there are ways to only track some upstream branches, such as the long-lived ones that I care about, and never even fetch all of the churning ones. But I haven't dug into Git that deeply so far.)

(This is one of the entries that I write for my own future reference.)

programming/GitPruneRemoteBranches written at 23:58:34; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.