1

master branch has these files and folders (simplified):

C:\Local\TickZoom\Project>ls
file.txt         name.txt      public

public branch is tracking a vendor repository and has been subtree merged as public folder in master branch above. public has three folders only (simplified):

C:\Local\TickZoom\Project>ls
platform  providers  www

When switching from public to master it behaves correctly.

However, when switching from master to public, an odd thing happens. It has all the files and folders of both combined:

C:\Local\TickZoom\Project>git checkout public

C:\Local\TickZoom\Project>ls
file.txt  name.txt   public
platform  providers  www

However, checking git status says nothing has changed.

I discovered that 'git reset --hard' fixes public back.

CLUE: It seems that this only happens after making a new commit to master. Does git do some kind of automatic merge?

After 'git reset --hard', the checkout to master and back to public work fine, even if repeatedly.

The first, I thought it was fixed but it occurred again the next time I made a change. Let me try that one more time now to make sure...

Now, I can't reproduce it. But it did happen twice.

One other CLUE is that the first time I did a git reset --hard it complained about files being locked by processes.

After the offending programs were closed, the git reset --hard succeeded and then the checkout worked between the two branches.

So does the checkout get confused by files being locked and "silently" fail? It would be better, it that's the problem to fail the same way git reset --hard does than just reporting success and having a jumbled workspace.

Any other wisdom or options to set on git checkout to avoid this will be appreciated.

Wayne

Zoe
  • 27,060
  • 21
  • 118
  • 148
Wayne
  • 2,959
  • 3
  • 30
  • 48
  • Okay, now found the problem. How to fix? Problem is that there are ignored files in subfolders. git properly does the checkout but leaves all the ignored files and if there several directories down, it leaves all the directies to get to them. I tried git clean -f and it still leaves the files. How to clean out non-tracked files when switching between branches? – Wayne Nov 18 '09 at 04:45

2 Answers2

6

You can clean all untracked files using:

git clean -dfx

Be sure there really aren't any untracked files that you want to keep before you run this command!

Dan Moulding
  • 211,373
  • 23
  • 97
  • 98
  • Note, I found that upper case X only cleans out ignored files and leaves any untracked files alone--much safer. The lower case x removes all ignored and untracked files--as you said--dangerous. So your exclamation point was merited! – Wayne Nov 18 '09 at 05:03
  • This works but if you have environment things such as `bower_components`, `node_modules` or `platforms` they'll be removed too. You effectively get exactly what would happen if you git cloned from scratch – Deminetix Aug 25 '15 at 23:37
2

use this to resolve

git clean -f -d -X

This cleans out only files ignored by your .gitignore and all empty directories that contain them.

I now do this in a script before checkout of branches that are from totally different repositories.

This isn't such an issue when switching branches between the same software.

Wayne

Wayne
  • 2,959
  • 3
  • 30
  • 48
  • 2
    In the comment you left to clarify your question, you asked, "How to clean out *non-tracked* files when switching between branches?" The uppercase X option doesn't clean "non-tracked" files, it only cleans ignored files. The lowercase x option cleans "non-tracked" files (including ignored ones). Which is why my answer suggested the lowercase x. :) – Dan Moulding Nov 21 '09 at 15:03