Local git clone clean up

[John Ralls]

On Jun 10, 2014, at 3:27 AM, Geert Janssens wrote:

> I'm writing this mostly as a references for other devs...
> 
> After John's recent cleanups in branches and tags I noticed my local git clone was still keeping 
> references to some branches and tags that are not longer in the public git repository. So I set 
> out to clean this up.
> 
> The most radical approach would be to remove my local clone and reclone the public repository. 
> That would certainly ensure full synchronisation, but I would also loose my local branches.
> 
> So in the end I did this:
> 
> - To remove all references to deleted remote branches in the public repository:
> 
> git fetch -p
> 
> Nice and easy.
> 
> - Then I noticed that all the remote branches were in my list twice, once as "remotes/origin/xyz" 
> and once as "remotes/xyz". The former are the references to the remote public git repository. 
> The latter I'm not really sure about. I guess they are leftovers from a remote I have removed at 
> some point or from the svn-git bridge we used to have.
> 
> git branch -d remotes/xyz
> gives an error, as does
> git branch -d xyz
> (assuming xyz does not exist as a local branch, but in that case this is not the command to use 
> anyway)
> 
> So to get rid of those I went directly into the hidden .git directory and manually removed these 
> branch references:
> 
> cd .git/refs/remotes
> rm *
> 
> Note that this will print a warning that "origin" can't be deleted because it's a directory. That's 
> precisely what I wanted because I want to keep the references to the "origin" repository. If you 
> want to play on the safe side, you are advised to delete the references in .git/refs/remotes one 
> by one, verifying each time if the correct branch reference has been deleted.
> 
> - Lastly I found there were still a lot of tags in my repository that were not (or no longer) in the 
> remote public repository. I haven't manually added any tags in my repository so they must be 
> the result of tags that got deleted remotely. It turns out that "git fetch -t -p" doesn't prune 
> deleted tags. In order to fix this I again used brute force: I first deleted *all* tags from my local 
> repository and then imported the tags from the remote repository:
> 
> for tag in $(git tag); do git tag -d "$tag"; done
> git fetch -t --all
> 
> Only do this if you never created tags yourself or don't care losing your private tags !
> 
> The end result is a nice clean local clone with all my private branches still available...
> 


git pull --rebase -p worked perfectly for me just now, but this laptop has a fairly recent clone rather than one migrated from the svn days.

Bear in mind that most references (i.e. tags and branches) don't exist in .git/refs, they're in .git/packed-refs. The only safe way to operate on that is with git update-ref. That means that deleting files in .git/refs/remotes won't necessarily get rid of all of the bogus branches. It's good that it worked for you.

I didn't touch the tags, except to remove the 0Root that I'd accidentally pushed on Sunday, but maybe they were symbolics pointing to branches merged into archive and deleted. No matter, it's good to have less clutter. Maybe I should remove some more, like gnome2-merge-[0-9]+-(post|pre).

Regards,
John Ralls