views:

47

answers:

2

Several posts talk about removing a file or directory from GIT - but they don't go as far as explaining how to PUSH those changes into the main repository.

For example, this works just fine to remove the directory but when I try to PUSH this change to the main Git repo, I am denied:

! [rejected]        master -> master (non-fast forward)
error: failed to push some refs to '/repo/project.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again.  See the 'non-fast forward'
section of 'git push --help' for details.

What is the last step to actually push this to the main repo and actually remove that directory?

+1  A: 

When you remove something so aggressively, you rewrite history. Therefore, the upstream repository is rejecting your change because it would result in a loss of history. In this case, you will need to use

git push --force
Nick Lewis
...but you should understand what you're doing, and make sure you really want to do it. See my answer.
Jefromi
You rarely want to --force a push. 99% of the time, the drawbacks outweigh the benefits.
Bryce
Yep - appreciate the warnings and understand it is definitely not a good practice - especially in a group setting. In my case, it is just me and I accidentally committed some auto-generated code that I don't want in the repo (and I want to feel like a Git Ninja :) and this was one edge-case that I needed to better understand how to enact.
Luther Baker
@Luther Baker cool. I just slap these warnings on everything, because even if the OP knows what they're doing, someone else might not. Some poor sap is going to be looking for a quick fix, not read any of the man pages, google, end up at SO, execute the first thing in a code block they see, then be very surprised when everyone else says "why can't I pull anymore?"
Jefromi
A: 

Nick Lewis' answer is sufficient, but I just want to add some emphasis, more than will fit in a comment. Here's a quote from the git filter-branch man page:

WARNING! The rewritten history will have different object names for all the objects and will not converge with the original branch. You will not be able to easily push and distribute the rewritten branch on top of the original branch. Please do not use this command if you do not know the full implications, and avoid using it anyway, if a simple single commit would suffice to fix your problem. (See the "RECOVERING FROM UPSTREAM REBASE" section in git-rebase(1) for further information about rewriting published history.)

Italics emphasis added - that's pretty important. Filter-branch really does rewrite history, it'll screw up anyone who's cloned/pulled from your repo, and it's scary. You should really know all that before you give it a go. Most people here are pretty good about providing that reminder whenever they recommend filter-branch or rebase; I think it's appropriate to have a pretty strong repetition of it here, on a question where the answer is push --force in order to completely rewrite the history in your public repo. That's a scary operation.

Jefromi