0

I'm following the directions from the BFG Repo-Cleaner site here...

https://rtyley.github.io/bfg-repo-cleaner/

Everything seems to have run successfully, and my repo is much smaller now, but when I try to do the last step of...

$ git push

All I get in return is this

$ git push
Everything up-to-date

After doing the git push, I checked my remote repo, which is on a GitLab instance that I have full control over, I don't see any record that a push happened. Plus, the repository on GitLab still shows that it is the large size that is was before I started using BFG Repo-Cleaner.

I've made sure that my branch on GitLab is not protected, and that my account has rights to push to it.

I'm not sure if I'm doing something wrong, or if this is the expected behavior, and I don't know how to verify that the git push actually worked.

twindham
  • 930
  • 9
  • 31
  • 1
    First, are you sure the repo you cleaned was cloned directly from GitLab? Or did you mirror-clone another local repo? (If you're not sure, `git remote -v` in the cleaned repo.) Even then, `Already up to date` is a strange response (unless you accidentally pushed from the wrong repo). But also, I'm not sure in gitlab whether this will work without deleting and recreating the repo – Mark Adelsberger May 10 '17 at 17:59
  • +Mark Adelsberger ... It is possible that I may have cloned this repo from a local repo instead of the gitlab instance of the repo, but not likely. When I do `git remote -v` in the cleaned repo, it shows that origin is set to the gitlab repo, but I could have done that manually. I was slinging repos around a lot yesterday. OBTW, I'm confused by the last sentence in your comment, because I'm not sure what you mean by the word "this". – twindham May 10 '17 at 18:07
  • 1
    Well, if the origin URL is correct then it doesn't really matter how it was cloned. My last sentence was just pointing out that hosted repos, to benefit from what you're doing, need to expose the ability to run `gc`; but I've since peeked at the gitlab docs, and you may be ok there. (Just, once the push is done, you may still need to invoke housekeeping functions on gitlab's end.) So next thought... – Mark Adelsberger May 10 '17 at 18:10
  • 1
    When you cloned I assume you used the `--mirror` option (as this is recommended procedure). Did you also give the `--mirror` option to `push`? **BUT** before you do that, you want to make sure any refs you don't mean to preserve in the remote are gone. (e.g. I can't recall if BFG creates backup refs of the "before" state) – Mark Adelsberger May 10 '17 at 18:12
  • +Mark Adelsberger ... Yes, I did use the --mirror option when cloning per the BFG instructions. I just tried a `$ git push --mirror` and I got the same result as before, `Everything up-to-date` – twindham May 10 '17 at 18:53
  • I may have figured out the issue here. I will post an answer to this question if my theory is correct. The theory is that I've screwed up badly. What I've done is run BFG on a different, giant, repository. This giant repo was so big that the second last instruction of `$ git reflog expire --expire=now --all && git gc --prune=now --aggressive` would never finish without my machine running out of memory. So, I took that repository and tried to split it up using these instructions... https://help.github.com/articles/splitting-a-subfolder-out-into-a-new-repository/ (1) – twindham May 10 '17 at 19:08
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/143909/discussion-between-twindham-and-mark-adelsberger). – twindham May 10 '17 at 19:08

0 Answers0