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" [off-list ref] writes:
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 wondered whether this was a deliberate choice
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.