1

I recently forked a project and after a few dozen commits, noticed there was some sensitive info I wanted to remove from a file. While wanting to remove that, either by undoing only my commits for that file, and redoing changes as one, or possibly replacing a text string, I found BFG. What I ran was:

bfg --replace-text replacements.txt -fi file .

and then 'git reflog expire…' as suggested by the BFG output. After force pushing to remote, my fork nows says:

This branch is XXX commits ahead, XXX commits behind …:master.

Too late now perhaps to undo unless I want to refork and add my changes as one commit. Is there any fix?

edit: My situation is very similar to the one here:

Git Merge Duplication after Ineffective BFG Use

git log doesn't show anything wrong but using other apps, I see the entire history has duplicates for each commit. Github Desktop also shows two branches, master and originalproject/master and I remember it only showing master before. I don't quite know enough about git to figure out the next step. Trying a git reset --hard master xxxx using the commit id from log says 'Cannot do hard reset with paths'.

empedocle
  • 1,862
  • 1
  • 14
  • 25
  • Interactively rebase your branch on to the forked project's master and squash all your commits into one. – Jonathan.Brink Feb 05 '16 at 00:36
  • I don't see the issue. You had sensitive information uploaded to your remote repo and now you've fixed that? Is the issue that while you were stuffing around with this stuff that your upstream repo got too far ahead? – Massey101 Feb 05 '16 at 01:35

1 Answers1

1

To understand the cause of this, you need to understand the consequences of rewriting history in Git. BFG is a tool that rewrites Git commits, and therefore your project history.

Git tracks commits via commit-hashes. The commit-hash is computed from a number of things - the parent commit hash, the content in the repo (tree hash), the author, committer, date/time of the commit, commit-message etc. If any of these change, such as file-contents, parent commit, then the commit-hash will change when that commit is re-written during a cleanup. From the first such commit you re-write, every subsequent commit will then differ and have a different hash, regardless of whether it was rewritten or not, since the parent hash will differ from that point forward.

In a universe of repos cloned/forked from an upstream repo, Git can tell where divergence has occurred by comparing common/new commit (hashes). Since you rewrote the history in your clone, it now diverges from the upstream from the point of the first commit you rewrote. This is what Git is telling you when it explains your branch ahead/behind.

If you only rewrite commits you made in your own fork, since you forked, and you haven't merged, then this is unlikely to be a big problem. If that is not true, then unless you can get the upstream repo to rewrite their history, then you are going to forever have a potentially large divergence.

As is suggested in the comment from Jonathan.Brink, your best bet is to rebase your cleaned commits onto the youngest common parent commit.

javabrett
  • 7,020
  • 4
  • 51
  • 73