In the forked project, .gitignore files are registered in .gitore (in particular, with settings) by specifying cms/media .

Is it possible to return to the commit in which these changes were added to the .gitignore file, correct it and use filter-branch to rewrite the commit history so that the file is displayed in the end?

added from comment:

What should I do if I need to change, for example, setting.json , but it does not pull up with git pull from github? because I thought it was because setting.json is specified in .gitignore , or something that doesn’t pull up means that setting.json is not in the repository?

  • and what is the ultimate goal? Do you want to add any files mentioned in .gitignore to the repository? So add: git add путь/к/файлу/каталогу . for this to rewrite history is not necessary. - aleksandr barakin
  • @alexanderbarakin, no, the ultimate goal is to pull up the file that was specified in .gitignore and therefore does not pull up with git pull from github - onlNas
  • The content of the .gitignore file does not affect the contents of the repository and the working copy of the files extracted from the repository. and in the repository you have the same thing as on github-e: objects like commit, tree and blob. but not the files and directories that you see in the working copy of your repository. - aleksandr barakin
  • And what's stopping you from deleting this line from .gitignore and creating files from history by hand? - korytoff
  • @alexanderbarakin, then could you tell me what needs to be done if I need to change, for example, setting.json, but is it not pulled by git pull from the github? because I thought it was because setting.json is specified in .gitignore, or something that doesn’t pull up means that setting.json is not in the repository? Thanks in advance - onlNas

1 answer 1

he doesn't pull up with git pull from github

the pull command does not "pull up" any files at all. pull - these are two consecutive commands: fetch and checkout .

fetch copies new objects (such as commit , tree , blob ) from the specified repository (for example, from the github.com server) to your local repository. for the sake of truth, it also turns out some meta-information like “where one branch or another points to” (a branch in git is a floating pointer to commit).

checkout unpacks (if necessary) objects from the repository and recreates the file / directory tree - a working copy of your repository.

if after such unpacking in the working copy there is no file, then it means that it is not mentioned in the object of the tree type, to which the object of the commit type refers, for which the checkout command was executed.

if you are sure that a certain file was once in the repository, you can check it with the command:

 $ git log -- путь/к/файлу

all commits that have changed this file will be displayed. if nothing is displayed, it means that this file has never been present in the repository (at least with this name - путь/к/файлу ).

if commits are displayed, you can retrieve the contents of this file after any of these commits (but not the most recent one - because by this commit the file was deleted or renamed) with:

 $ git checkout хэш-коммита -- путь/к/файлу

getting the content (or creating it from scratch) and editing it if necessary, you can already add this file to the index (the -f option is necessary to ignore the .gitignore content):

 $ git add -f путь/к/файлу

and fix this fact with a commit. and no .gitignore content will prevent you from doing this.

and there is no need to rewrite the history of commits on such a trivial matter.

  • Shouldn't it be necessary to write git add --force путь/к/файлу to add a file hidden by a gigonor? - Pavel Mayorov
  • @PavelMayorov, yes, thanks for the clarification. - aleksandr barakin
  • @alexanderbarakin, Thank you! and how can I see a list of files that was after a certain commit? - onlNas
  • @onlNas, stackoverflow.com/a/444317/4827341 : git ls-tree --name-only -r хэш-коммита - aleksandr barakin