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

`brew update` should have a `--force` option #14224

Closed
cooljeanius opened this Issue Aug 16, 2012 · 24 comments

Comments

Projects
None yet
8 participants

brew update often fails because it says it would overwrite local changes. Personally I don't care if it overwrites local changes, because most of the time I haven't actually made any and it's just a false positive, and even if I had made some, I'd rather have them replaced with the official update anyway. There should be a --force option to allow brew update to overwrite local changes.

Owner

MikeMcQuaid commented Aug 16, 2012

We've been discussing this. I think it would be better as either a) the default or b) a prompt rather than an option that isn't very discoverable.

Member

mxcl commented Aug 16, 2012

It doesn't often fail, it's an edge case bug. I'd like to understand why you get it so often (as well as fix it). Any ideas?

Well, I think the reason I get it so often is because it kind of causes a chain reaction. Things go like this:

  1. I do brew update
  2. It fails half-way through, telling me I have local changes that it would overwrite
  3. I fix the files it tells me to
  4. I try brew update again
  5. This time, the changes it was able to make the previous time before it failed get counted as "local changes that would be overwritten", so it fails part-way through again, and now I have to go fix those
  6. Repeat steps 3-5
Member

mxcl commented Aug 16, 2012

You should just git reset --hard origin/master and never have trouble again. This is documented on the wiki etc.

Owner

MikeMcQuaid commented Aug 16, 2012

@mxcl I wonder if we shouldn't just prompt and offer to do that for the user. Perhaps similarly for brew doctor problems.

I agree, offering to do it for the user would be much easier.

swrobel commented Oct 24, 2012

👍

This was referenced Dec 5, 2012

Contributor

samueljohn commented Dec 19, 2012

@MikeMcQuaid that would be the best option. A doctor that actually "heals" and not just list the diagnosis :-)

Contributor

aaronsnoswell commented Mar 12, 2013

+1. A --force option would be my preference, as it matches with other brew commands.

Regarding Issue #18544 what dir wants the "git reset --hard origin/master"?

Contributor

samueljohn commented Mar 18, 2013

I personally do this in brew --repository @myacavone. I know the doctor suggests in the Library subdir.

Thank you @samueljohn. I'm happy to do that, but if there's other debugging info anyone wants before then, I'll wait a few hours.

Contributor

samueljohn commented Mar 18, 2013

@myacavone for debugging purpose: What is git status and git diff (post gist, if long)?

BigIron:local mjy$ git status
# On branch master
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# Library/Contributions/cmds/
# Library/ENV/pkgconfig/leopard/
# Library/ENV/pkgconfig/mountain_lion/
# Library/Homebrew/macos/
# Library/Homebrew/vendor/multi_json/engines/
nothing added to commit but untracked files present (use "git add" to track)
BigIron:local mjy$ git diff
BigIron:local mjy$

Contributor

samueljohn commented Mar 18, 2013

brew update then brew doctor and it should suggest to git clean -d -f. This should remove the untracked dirs, too. If this does not fix it for you, please reopen.

@samueljohn samueljohn was assigned Mar 18, 2013

Contributor

samueljohn commented Mar 18, 2013

If any maintainer thinks a --force option to update is still needed: Also reopen.

If any maintainer thinks a --force option to update is still needed: Also reopen.

Hoping some maintainer thinks this...

Owner

MikeMcQuaid commented Mar 22, 2013

@samueljohn I wonder if brew update should suggest that.

Contributor

samueljohn commented Mar 22, 2013

I'd prefer suggesting that (or suggesting to ask the doctor) over just brutally removing local changes.

@samueljohn samueljohn reopened this Mar 22, 2013

Contributor

samueljohn commented Mar 22, 2013

After thinking about this for a while, I have changed my mind. (makes me look fickle now)
I think of system admins and automated scripts to handle homebrew (like boxen, you know). They might certainly want to brew update --force instead of a suggestion.

The suggestion could be shown for brew update. And brew update --force does the hard thing?

I could implement that if you want me to @adamv @jacknagel @mxcl @mistydemeo @MikeMcQuaid ?

Owner

MikeMcQuaid commented Mar 22, 2013

@samueljohn I meant brew update should suggest the user run that manually. Yeh, I think a --force argument which prints a big warning perhaps with a countdown would be sensible.

@Sharpie Sharpie pushed a commit to Sharpie/homebrew that referenced this issue Apr 7, 2013

@samueljohn samueljohn doctor: Tweak git-clean suggestion for empty dirs
git clean -f is not enough. Needs `-d` somtimes to
handle cases when we rename a dir.

Fixes #18544 and fixes #14224
970cfc0

@nesv nesv added a commit to nesv/homebrew that referenced this issue Apr 12, 2013

@samueljohn @nesv samueljohn + nesv doctor: Tweak git-clean suggestion for empty dirs
git clean -f is not enough. Needs `-d` somtimes to
handle cases when we rename a dir.

Fixes #18544 and fixes #14224
80214a8
Member

mxcl commented Jul 16, 2013

I'm not really sure what to say on this issue. I just wish we knew why it was happening as it shouldn't happen and if it didn't happen (unless the user had actually edited files) we would be great.

Member

mxcl commented Jul 29, 2013

The solution is not to make update capable of damaging stuff, but to have brew doctor diagnose and provide advice for fixing this. brew update can print the same message.

When this sort of thing happens it is not sensible for us to try and fix it, as the system is broken, many things could be wrong, any attempts by us to fix it may make it worse, a human (sadly) needs to judge the steps to take.

Contributor

adamv commented Sep 9, 2013

Closing in favor of some recent fixes to update as well as #22375.

@adamv adamv closed this Sep 9, 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.