0

A colleague has done a few things I told them not to do:

  • forked the origin repo online
  • cloned the fork, added a file that shouldn't have been added to that local repo
  • pushed this to their fork

I've then:

  • merged the changes from the fork and found the file

I want to remove this from:

  • my local repo
  • the fork
  • their local repo

I have a solution for removing something from the history, taken from Remove file from git repository (history). What I need to know is, should my colleague also go through this, and will a subsequent push remove all info from the fork? (I'd like an alternative to just destroying the fork, as I'm not sure my colleague will do this)

SOLUTION: This is the shortest way to get rid of the files:

check .git/packed-refs - my problem was that I had there a refs/remotes/origin/master line for a remote repository, delete it, otherwise git won't remove those files
(optional) git verify-pack -v .git/objects/pack/#{pack-name}.idx | sort -k 3 -n | tail -5 - to check for the largest files
(optional) git rev-list --objects --all | grep a0d770a97ff0fac0be1d777b32cc67fe69eb9a98 - to check what files those are
git filter-branch --index-filter 'git rm --cached --ignore-unmatch file_names' - to remove the file from all revisions
rm -rf .git/refs/original/ - to remove git's backup
git reflog expire --all --expire='0 days' - to expire all the loose objects
(optional) git fsck --full --unreachable - to check if there are any loose objects
git repack -A -d - repacking the pack
git prune - to finally remove those objects
Community
  • 1
  • 1
ian
  • 12,003
  • 9
  • 51
  • 107
  • Note that if you do this with a repo you've already pushed from, or that someone's pulled from, things might get weird... you'd have to do it in every copy, i'd think. – cHao Oct 15 '12 at 03:15
  • Yep, that's why I haven't just gone ahead with it, but I know no one else has touched their fork. – ian Oct 15 '12 at 03:16
  • or will touch their fork, I should add. – ian Oct 15 '12 at 03:17
  • 1
    Destroying the fork is really the cleanest option, i think. I'm pretty sure that rewriting history locally won't do much good; all the warnings and such that i've seen suggest git would get pretty confused when the two repos disagree about stuff that already happened. – cHao Oct 15 '12 at 03:26
  • Good call. I'm setting out some new guidelines to try and stop this in future. – ian Oct 15 '12 at 16:57
  • possible duplicate of [Completely remove file from all Git repository commit history](http://stackoverflow.com/questions/307828/completely-remove-file-from-all-git-repository-commit-history) –  Apr 05 '14 at 01:02

1 Answers1

1

Well, pushing will definitely cause little trouble as you won't have a linear history. Using --force flag to push and pull should do the job.

Although, if not, ask your colleague to reset their branch at the first known commit git reset --hard <initial commit sha-1> and then ask them to pull. This way should work as the reset won't properly be a change in the local branch; the branch will only be marked as behind it's remote counterpart by lots of commit. Then, fetching and merging will go easy as they'll go up all the way with a linear history.

But of course, such a manoeuvre need organization/timing between your team.

Simon Boudrias
  • 42,953
  • 16
  • 99
  • 134