0

The .gitignore file successfully ignores all web.config files. This was not always the case. There are lingering historical references to the web.config files. Now occasionally, the web.config files are reverted without warning to a previous state. When developers make changes to restore web.config files no differences are noted as expected.

What explains the unexplained behavior of reverting to a previous version and how can it be stopped? I would prefer not to alter the entire history of the repository but that is permitted for my ends.

-- EDIT -- I found a partial solution. The only problems to this is that it changes my history to include web.config files and then it deletes them. I now think the right thing to do is to override the history even on the server by removing all references to config files from the very beginning.

haleonj
  • 1,438
  • 3
  • 16
  • 30

2 Answers2

1

Probably you checked out an old commit that contains the file. Either using git checkout directly or indirectly during, say, git rebase -i.

phd
  • 82,685
  • 13
  • 120
  • 165
  • Can you please elaborate on how to implicitly or indirectly checkout a file? I now often use `git pull --rebase` and this has corresponded with my troubles. – haleonj Jun 07 '18 at 17:58
  • `git checkout $COMMIT_ID` checks out a commit, i.e. updates all files; `git rebase` checks out all commits being rebased one by one. `git pull --rebase` does `git rebase` so it could be the reason for the file to be updated from an old commit. – phd Jun 07 '18 at 19:58
1

To remove web.config file from all the commit histories, you can execute below commands:

touch .gitignore
echo 'web.config' > .gitginore
git rm --cached web.config
git add .gitignore
git commit -m 'add .gitignore to ignore web.config'
git filter-branch --index-filter 'git rm --ignore-unmatch --cached -r web.config' --prune-empty -f -- --all

It may take a few longer minutes to rewrite histories. After that, web.config file is totally removed from git commit histories.

Marina Liu
  • 36,876
  • 5
  • 61
  • 74
  • I found your answer to be the most helpful. I want to add that if people in my position were to stop at `git rm --cached ` then the files would *initially* remain in the working tree, but subsequent merges and rebases would delete it from the working tree and the file would remain in history to haunt your `git bisect` debugging sessions. – haleonj Jun 13 '18 at 19:14