2

How do I make Git (on computer) forget a deleted file, while GitHub (online) remembers the un-deleted file?

Background:

I made some "issue template" files in GitHub online, then made a git pull & noticed that I got the files, so I made a .gitignore file to ignore the "issue" files. But git isn't ignoring them (yet?), and want to push the deletions of the files to GitHub, which is wrong, they should exist on GitHub, but not on Git.

I do not want to push the deletion of the files & just have to re-create them & hope .gitignore works.

Theory:

My think I need to un-track the files or delete the files from the tracking index, somehow?

I have tried:

  • different combinations of:

    • git rm <file>

    • git rm --cached <file>

    • git update-index --assume-unchanged <file>

I want the exact opposite of these questions:

chepner
  • 497,756
  • 71
  • 530
  • 681
Sebastian Norr
  • 7,686
  • 2
  • 12
  • 17
  • 1. "issue template" **are** in the git repository. What is the good reason to want to delete them locally. Do they cause a specific problem? Because solutions to this problem are boring to manage. 2. FYI, `.gitignore` is only for untracked files and so, has no effects on already tracked files. – Philippe Dec 06 '19 at 14:44
  • Those files only have an effect on the GitHub site itself, they are useless & just in the way locally (unless I want to change them for some reason, which I don't at the moment). – Sebastian Norr Dec 09 '19 at 10:48
  • That's what I thought. You are going toward problems or things difficult to handle because that's not how git is working. And all that just to hide one folder (You put all that in the `.github` folder, right!?! See https://github.blog/2016-02-17-issue-and-pull-request-templates/). That doesn't worth the effort... – Philippe Dec 09 '19 at 12:06

1 Answers1

2

Solution: git update-index --remove --assume-unchanged <file_path>

WARNING!

A side effect of this is that Git will TOTALLY forget the existence of the file & not respect the settings in the .gitignore file, so even if you later remove the restriction in .gitignore it will not be downloaded again. (if you have a better solution, PLEASE share it.)

You can start tracking the file again with this command:

git update-index --remove --no-assume-unchanged <file_path> (notice the: --no- assume-unchanged)

Starting condition:

  • After a git pull you have files in Git (locally) that you only want to be in GitHub (online).

Step by step solution:

  1. Open CMD (the CoMmanD prompt)
    1. Press Windows-button + R (or equivalent for your OS).
    2. Type "CMD" & press OK.
  2. Type: cd ("cd" & a space) then drag & drop the folder you want to move into on the command prompt (it should automaticatically add the full path to the file, otherwise type it in manually, you must use quotes if the path contains any spaces).
    1. It should look something like this: cd "C:/path/to/the/folder" Press Enter. Now you're hopefully at the right place.
  3. Now type: git update-index --remove --assume-unchanged (end with a space) & again drag-&-drop the file you want to remove on the command prompt. (I'm not sure if it works with folders?)
    1. It should look like this: (it's longer than necessary, but easier to do)
    2. git update-index --remove --assume-unchanged "C:/path/to/the/folder/unwanted_file.txt"
  4. Now you can delete the unwanted file. (drag to recycle bin or something)
  5. (Repeat step 3 & 4 for all remaining unwanted files in the same repository (use step 2 to change repository))
Paolo
  • 21,270
  • 6
  • 38
  • 69
Sebastian Norr
  • 7,686
  • 2
  • 12
  • 17
  • Be aware that you confuse `--assume-unchanged` (for performance problem) and `--skip-worktree` (for files changed locally). See https://stackoverflow.com/a/13631525/717372 – Philippe Dec 06 '19 at 14:40
  • Don't use `--remove` here in your `update-index` (well, you *can*, it's harmless as long as the file is still in your work-tree at the time, but it's misleading). Your goal is to set one of the two "assume the file in the work-tree is correct" bits on the index entry, while not changing the index hash ID entry, so that the index copy of the file keeps going into each *new* commit but Git never *compares* the index copy of the file to the work-tree copy-or-lack-thereof. – torek Dec 06 '19 at 17:54