git checkout -f branch doesn't remove extra files

I've just got around to noticing some of the new (to me) features in git, and started experimenting with branches.

I see that when I switch view to a different branch with:

	$ git checkout -f someoldbranch

that any files that exist in my previous branch view but not in "someoldbranch" are not deleted. I can find and remove them easily with:

	$ git-ls-files --others | xargs rm -f

but I wondered whether this was a deliberate choice (to avoid clobbering .o files etc. for people who have run a make in their tree).

Currently git-ls-files doesn't have a way to specify a branch ... but it it did, the something like:

	comm -1 <(git-ls-files -b oldbranch) \
		  <(git-ls-files -b newbranch) | xargs rm -f

would clean up the spurious files.

-Tony

"Luck, Tony" <tony.luck@intel.com> writes:

Not really.

When possible, please use "git checkout" without -f. That form uses "git-read-tree -u -m", which can tell from your current index file what's changed and what's going away. This is only possible if read-tree can rely on what is in your index file actually matches the status of your working tree, and the -f flag to checkout is to work around cases where you cannot give that guarantee to read-tree and would want/need to start over from scratch. With -f flag, you are telling git-read-tree to ignore what is currently recorded in your index file, hence what should be in your working tree before checkout. There is no way for git-read-tree to tell which are source files that exist only in the old thing you had checked out before (i.e. should be removed) and which are files your build procedure left and/or files you made by hand outside of SCM control (i.e. should be kept) without that information, so that is why those files were left behind.