Pitfalls of how to remove the file from Git management

If you want to remove file “a” from currently Git management, you will do as follows.

And you may want to define “.gitignore”. This approach has been introduced in many places.

But in this case, when you checkout the past commit, you will see that the file “a” was overwritten by the previous contents. The file was supposed to be outside the control of Git.

You can reproduce the fact as follows.

By the last checkout, the contents of “a” will be rewritten to “initial”. In other words, even if “unmanaged” the file, the contents of the current file will be lost to be “managed” and go back to the past.

In this case, it is fatal in that because there is no history of changes of management outside, you can not retrieve the current file “a”.

I’ve also studied to try if you do not create “.gitignore”.

At the time you are trying to rewrite “a” with the last checkout, you will fail with an error. I think this is a desirable result. Git should remind you here, that unmanaged file “a” were managed at the past. If you moved file “a” somewhere once, you can checkout to get back “a” in the past.

Why the difference between the two situations happen this?

If there is “.gitignore”, the current file “a” has no interest to Git. Therefore Git would also be carried out without having to worry about checkingout to overwrite.
On the other hand, if there is no “.gitignre”, because “a” is “Untracked” file, Git does not checkout to overwrite it on its own.

Is this correct?

However, if there is no “.gitignore”, you are inconvenient to be displayed every time “Untracked”. Is not the only way to rm all “a” back in the past using rebase -i?
I am investigating whether there is any good way.

Your email address will not be published.