docs: add alternative to bfg on about-large-files-on-github.md

[MathiasBaumgartinger]

With all due respect, I found BFG really clunky to work with. Hence, I searched for an alternative. Credits to ZelluX (https://stackoverflow.com/a/1186549).

Why:

BFG is a mighty tool, but may have to much overhead for a simple solution concerning big files in a previous commit.

Closes:

What's being changed (if available, include any code snippets, screenshots, or gifs):

Just the documentation on large files and how to handle them in order to be able to push to github.

Check off the following:

• I have reviewed my changes in staging, available via the View deployment link in this PR's timeline (this link will be available after opening the PR).

  • For content changes, you will also see an automatically generated comment with links directly to pages you've modified. The comment won't appear if your PR only edits files in the data directory.

• For content changes, I have completed the self-review checklist.

[welcome]

Thanks for opening this pull request! A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.

[github-actions]

Automatically generated comment ℹ️

This comment is automatically generated and will be overwritten every time changes are committed to this branch.

The table contains an overview of files in the content directory that have been changed in this pull request. It's provided to make it easy to review your changes on the staging site. Please note that changes to the data directory will not show up in this table.

---

Content directory changes

You may find it useful to copy this table into the pull request summary. There you can edit it to share links to important articles or changes and to give a high-level overview of how the changes in your pull request support the overall goals of the pull request.

Source	Preview	Production	What Changed
repositories/working-with-files/managing-large-files/about-large-files-on-github.md	fpt ghec ghes@ 3.14 3.13 3.12 3.11 3.10	fpt ghec ghes@ 3.14 3.13 3.12 3.11 3.10

---

fpt: Free, Pro, Team
ghec: GitHub Enterprise Cloud
ghes: GitHub Enterprise Server

[subatoi]

Hi @MathiasBaumgartinger and thanks for your interest in the GitHub docs 👋

I'm afraid we won't be accepting this contribution on this occasion—I'll outline our reasoning below:

• There are a few places where we'd need to make this change, and it requires a more considered approach than only adding the content you've proposed to one article.

• Generally, we take an "opinionated" approach to content where there are multiple possible solutions, and pick one method and stick to it. That's something that we agree with stakeholders internally at time of publication, and once the content is published, unless there's something actually wrong about using that method and that feedback is surfaced, then we won't change it.

For cases like this, where there isn't an immediately straightforward solution, I'd really recommend opening an issue first before taking time to write a PR. That way we can have a discussion first, and everybody involved—most importantly, you—has a better experience.

I will pass on feedback to the content team in question for any future updates they may make to this article.

Thanks again for your interest in the GitHub docs.

[MathiasBaumgartinger]

Hey there!

I accidentally got caught in the same trap today again. I really cannot understand why you would recommend BFG for a solution that can honestly be solved in a matter so much simpler. For the sake of all other clumsy fellows out there, I would really appreciate you consider exposing this option in your documentation.

[nguyenalex836]

@MathiasBaumgartinger Thank you for sharing! Would you be able to raise an issue (instead of a PR) in this repo on this topic? We can then have our SMEs review your proposal and gather their feedback on the best path forward 💛