If I’m understanding your description correctly, the issue was likely that test_file was untracked, so git let it hang around in your sandbox while you switched branches.

I have not verified this behavior, but it makes sense if this is the case.

When you switch branches in your git, git’s only rule is not to destroy information.  This means that if a tracked file has been modified, it should refuse to do the switch.  However, if a tracked file has not been modified, it is free to bring a different revision into your sandbox or to delete it from your sandbox (the rationale for this is that you can get the file and its contents back by switching back to the original branch).

But with an untracked file, git’s designers likely had to decide between two options:

1)Refuse to do the switch until the user has disposed of the untracked file.

2)Do the switch, but leave the untracked file in place, unchanged.

Note that the following would NOT have been an option:

3)Delete the tracked file.  (Not an option because you could not recover the file.)

I’m guessing that git’s designers chose (2) because it is less obtrusive.  It would be a common use case that developers have extra untracked files in the sandbox when switching branches.

(*) One case that I would be curious about is if you are on a branch where test_file is not tracked, you create test_file, then try to switch to a branch where test_file IS tracked.  I’m betting git will refuse to let you switch branches.

Again, git’s priority would be to not destroy your data.  Leaving an untracked file in your sandbox while switching branches does not destroy data.

If you test (*), let me know the results.