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

[MathiasBaumgartinger]

Code of Conduct

• [X] I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?

https://github.com/github/docs/blob/main/content%2Frepositories%2Fworking-with-files%2Fmanaging-large-files%2Fabout-large-files-on-github.md

What part(s) of the article would you like to see updated?

As mentioned in my PRQ I think for many use-cases, with all due respect, BFG is an overloaded and unintuitive tool. Removing a file can be done rather straightforward with an interactive rebase.

As a clumsy git(hub) user I would have appreciated the suggestion for such a solution a lot.

Additional information

Content of Pull-Request

Alternatively, git rebase may be used to alter the commit in an earlier state. First, you need to identify the hash of the commit where the change happened. For instance, to modify 35da8436, you may use

$ git rebase --interactive 35da8436~

The tilde (~) is strictly necessary to reapply the subsequent commits. git rebase will now open your default git editor of structure:

pick 35da8436 style: add new resources for roofs and clean up some old ones
pick 09f6df0d feat/WIP!: major restructure and rewrite of components

Change pick to edit in the line of the commit to be modified. Once the file is saved, the HEAD of the repository will be at the named commit. The commit may now be modified. Repeat the steps mentioned previously:

  $ git rm --cached GIANT_FILE
  # Stage our giant file for removal, but leave it on disk
  $ git commit --amend -CHEAD
  # Amend the previous commit with your change
  # Simply making a new commit won't work, as you need
  # to remove the file from the unpushed history as well

Consequently, you may return to the original HEAD using git rebase --continue and push the smaller commits using git push.

[welcome[bot]]

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

[nguyenalex836]

@MathiasBaumgartinger Thank you for raising this issue! I'll get this triaged for review :sparkles: Our SME team will provide feedback regarding the best next steps for this issue - thanks for your patience! 💛

[github-actions[bot]]

Thanks for opening an issue! We've triaged this issue for technical review by a subject matter expert :eyes:

[newren]

Thanks for sending in a suggestion for the docs; very much appreciated.

While you raise a valid point, I am concerned that the suggestion might only be applicable in special circumstances and these instructions might hurt others who don't fall into the same circumstances as you:

• The rebase instructions you provide presume that only a single commit is problematic; it might be multiple, and explaining how to hande multiple commits would require extending the instructions. Also, there's a problem of knowing which commits are problematic because...
• The rebase instructions you provide presume that the user knows which commit(s) is/are problematic rather than which file. If another user tries to use these rebase instructions and guesses the wrong commit, they may end up leaving the big file in the repository.
• There is a risk that if the big file was both added in one commit and modified in a later one, that users will run into conflicts and end up with a mess they don't know how to resolve. Trying to explain how to handle conflicts (possibly repeatedly) as part of an interactive rebase seems out-of-scope for this document, but necessary if we're actually suggesting this route.
• The rebase instructions presume that the history between the big commit and the current tip of history has no merges. That might be true in most cases, but could be very problematic for users who attempt to use the same instructions but for whom that is not true.

If we do mention git-rebase, then I think we'd need to mention that it's only applicable in special cases (linear history, you know which commit(s) added or modified the problematic file, you are familiar with what to do if conflicts arise). Rather than expand the document to cover all those cases, I think it'd be better to just have a brief mention that git-rebase can do the job in these special cases and link to upstream docs but then recommend other tool(s) instead.

I'm already planning on a few big changes to the sensitive-data-removal document soon, I could modify this document at the same time to make that brief mention.

[github-actions[bot]]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further. See this blog post on bug reports and the importance of repro steps for more information about the kind of information that may be helpful.