Join GitHub today
Git push has some rejections #36
I recently used BFG to remove some old files and change a few texts in my test files. The clean operations went all OK without a problem. When I tried to push the changes I had the following error message at the end:
These are some of the rejected messages:
Am I in trouble? Did I just mess up my repository? Is there anyway to correct this error?
I would really appreciate any help, thanks.
You're not in trouble! However this is something I could cover with better documentation - issue #16 relates to this. The refs beginning 'refs/pull' are synthetic read-only refs created by GitHub - you can't update (and therefore 'clean') them, because they reflect branches that may well actually come from other repositories - ones that submitted pull-requests to you.
So, while you've pushed all your real refs, the pull requests don't get updated. There's no real way to fix them with your existing repo with the GitHub admin tools. The severity of an issue depends on whether you were trying to remove any 'private' data:
referenced this issue
May 10, 2015
In order to change Git history (ie to change a repo to make it look like that file was never added) brand new commits have to be created. This is how Git works - every commit-id reflects a hash of it's history - change the history, change the commit id. To delete a file, you have to create new 'clean' commit history, and throw away the old 'dirty' history.
So yes, your commit history has been duplicated, but that's essential. And this can be awkward if you have old pull requests lying around, pointing to the old history.
does this mean that bfg can't "clean" your history on any github repository that has had pull requests "touching" any file you're trying to remove?
what i mean is, you look at the history (on github) and you can see that the history has been re-written and the file(s) you're cleaning out cannot be seen on the commits but if you go through the pull request history or if you still have the hash for the commit the file was introduced in (as an example), you can still see it (and its contents). unless i'm wrong.
so in order for someone to remove a file for sure they'd have to:
i have a public repo in which (i believe) this issue is easily seen, in case i didn't explain myself appropriately.
I just try to run bfg without deleting any files, without any open push requests, and it fails, too:
This is what I did:
After that I tried to follow the suggestions at http://stackoverflow.com/questions/34265266/remote-rejected-errors-after-mirroring-a-git-repository and did following:
with the following config with updated fetches:
But still without effect (see output above) :-(
No (open) push requests, only 1 additional branch - so it should be very simply, isn't it?
I think you mean Pull Requests. You are distinguishing open PRs from closed ones, however GitHub is retaining a (read-only) ref for each PR, regardless of whether it is open or closed. This allows you to later view the PR and the diffs it represents, even if that history would have been otherwise lost/garbage-collected if it were not merged into an ongoing branch.
Since you originally followed the BFG documentation and used
How you deal with this depends on what you are using BFG for and what you want to achieve. If you want sensitive or large files completely removed from the GitHub repo, then you need to contact GitHub support according to https://help.github.com/articles/remove-sensitive-data/ (emphasis mine):
In other words, GitHub Support might be able to provide further info on how you can discard the old history referenced by PRs.
If you just want bulk removed from what default (non-mirror) clones see, then you don't have to worry about these, as they aren't fetched by default, but be aware that the size of the repo on GitHub will actually increase slightly as a result.