I've not used Git Extensions (which apparently is just a GUI tool for interacting with Git) or TFS, but I'm going to assume that we only have a Git repository here, and we're not dealing with a more complicated situation where it's a mirror of some TFVC repository that also needs to be cleaned.
I'm really new to GIT and these 28 files were placed into the repo
about a year ago before I started working and discovered the issue.
Good news, this is exactly the sort of problem the BFG was created to solve!
Any help or steps on how to do this.
The documentation for the BFG Repo-Cleaner is at: https://rtyley.github.io/bfg-repo-cleaner/
... you'll definitely find it helpful if you take the time to read it, especially the Usage section (which explains the procedure leading up to, and following on from using the BFG) but also the Your current files are sacred... and Examples section.
I've tried BFG Repo-Cleaner and Git Extensions. Git Extensions to see
if the folder is still there after running through the BFG steps.
What command line arguments did you use when you tried to invoke the BFG, and what errors or output did it give you? That kind of information is always useful to people trying to help you! The command I'd use in your situation would have been:
$ bfg --delete-folders "Workstation Install"
Note that passing filenames with spaces to command line apps is always a bit subtle, but enclosing the folder name (just the folder name, not it's path within the the repo) in double quotes should work I think.
Don't know how to do this for BFG: By default, the HEAD branch is
protected, and while its history will be cleaned, the very latest
commit (the 'tip') is a protected commit and its file-hierarchy won't
be changed at all.
You're quoting from the Your current files are sacred... section in the BFG's documentation there, so I'm guessing that you've read it but unfortunately it wasn't clear enough?
You might find it helpful to read this Stackoverflow answer, an alternatively-worded explanation by a different person of this safety feature in the BFG.
To attempt to explain it once again myself: You don't want these files, right? So you are fine to start off by making a normal commit deleting them from your master branch? At that point you can check that your project still works without those files (which sounds pretty likely in your case, but might not be the case for other projects doing a clean-up - what if they delete a file that breaks some tests?).
Then you're ready for the much more radical step of rewriting all of Git history - you can run the BFG, and you only have to deal with the problems of sharing this updated history - you don't have to deal with the problem of suddenly breaking your project by removing those files, because
you've already taken checked (and fixed) that issue in advance.
Why is this safety feature in the BFG?
As the author of the BFG, I did not want to field support questions from users who had accidentally broken the build of their project by running the BFG - better that users break and fix their projects before they get to the step of running the BFG! So the BFG does not delete any file present in the latest commit - you need to manually ensure the current version of your file tree is clear of those unwanted files.
Full disclosure: I'm the author of the BFG Repo-Cleaner.
