This repository has been archived by the owner. It is now read-only.

`brew prune` gets handsy with git repos / bundler #11481

Closed
trevor opened this Issue Apr 6, 2012 · 13 comments

Comments

Projects
None yet
6 participants
Contributor

trevor commented Apr 6, 2012

testcase:

% git init --bare /usr/local/etc/dontprunemebro
Initialized empty Git repository in /usr/local/etc/dontprunemebro/
% brew -v cleanup
Homebrew 0.9
rmdir /usr/local/etc/dontprunemebro/refs/tags
rmdir /usr/local/etc/dontprunemebro/refs/heads
rmdir /usr/local/etc/dontprunemebro/refs
rmdir /usr/local/etc/dontprunemebro/objects/pack
rmdir /usr/local/etc/dontprunemebro/objects/info
rmdir /usr/local/etc/dontprunemebro/objects
Pruned 0 symbolic links and 6 directories from /usr/local

in practice:

% ~/bin/powerupgo
  gem update --system
  gem update
  brew update
  brew upgrade
  brew cleanup

...

Homebrew 0.9
rmdir /usr/local/lib/ruby/gems/1.9.1/doc
rmdir /usr/local/lib/ruby/gems/1.9.1/cache/bundler/git/stuff-4040404040404040404040404040404040404040/refs/tags
rmdir /usr/local/lib/ruby/gems/1.9.1/cache/bundler/git/stuff-4040404040404040404040404040404040404040/refs/heads
rmdir /usr/local/lib/ruby/gems/1.9.1/cache/bundler/git/stuff-4040404040404040404040404040404040404040/refs
rmdir /usr/local/lib/ruby/gems/1.9.1/cache/bundler/git/stuff-4040404040404040404040404040404040404040/objects/info
rmdir /usr/local/lib/ruby/gems/1.9.1/bundler/gems/stuff-121212121212/.git/refs/tags
rmdir /usr/local/lib/ruby/gems/1.9.1/bundler/gems/stuff-121212121212/.git/objects/info
Pruned 0 symbolic links and 7 directories from /usr/local

(ruby formula not installed)

Contributor

adamv commented Jul 28, 2012

@mxcl @Sharpie @MikeMcQuaid @jacknagel @mistydemeo - cleanup shouldn't assume it's the only git repo in the prefix, should it?

Member

mxcl commented Jul 29, 2012

I can't think of a way that cleanup could know what it shouldn't cleanup.

Member

mxcl commented Aug 6, 2012

This is actually a bug with the prune command. Still not sure how to make it not do these things.

Contributor

adamv commented Jan 13, 2013

As a workaround:

I install Homebrew in a folder that's not /usr/local, and then symlink the brew binary into /usr/local/bin. This way, I keep the .git folder and non-installed Homebrew files out of the way.

The downside to this setup is that bottling doesn't kick in for me.

Owner

MikeMcQuaid commented Jan 14, 2013

@adamv I'm up for allowing you to enable bottles in non-/usr/local with a flag if you want so you can see stuff that breaks/works. I know Qt will definitely not work properly but other stuff may do.

Contributor

Sharpie commented Jan 14, 2013

For many things, we may be able to get by with running an install_name_tool pass after pouring the bottle...

Owner

MikeMcQuaid commented Jan 15, 2013

That already happens I'm pretty sure.

Owner

MikeMcQuaid commented Jan 15, 2013

Basically: I'm happy to roll this out to users selectively who enable some option. I'll work on adding one when I'm back from holiday and if it works for our various testers then we can just blacklist packages like Qt with some DSL addition from being installing in non-/usr/local (or work out a way perhaps of only compiling the stuff that has the location hardcoded in like e.g. qmake.

Contributor

jacknagel commented May 15, 2013

I guess prune should just not descend into .git directories.

Contributor

adamv commented May 16, 2013

I wouldn't even know how to detect a bare git repo (other than trying to call a git command in every pruned folder).

Contributor

jacknagel commented May 16, 2013

Probably just use the presence of HEAD, index, and refs as a heuristic.

Contributor

jacknagel commented May 16, 2013

Though its an annoying special case. I wonder, does this cause problems in practice? It's not ideal that we prune these dirs, but if git can cope with them being missing, and I would hope it can, I'd be tempted to just close this as wontfix.

Contributor

adamv commented May 16, 2013

Closing because no other user has chimed in with "me too" over the course of this being open.

@adamv adamv closed this May 16, 2013

@xu-cheng xu-cheng locked and limited conversation to collaborators Feb 16, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.