Thanks for explaining that Andrew. I guess that was my intention: to have an 
"ignored file snapshot", but I can see now that it goes against Git's 
definitions and is not really needed.

I have overcome the problem by re-organising my repository and "... using more 
'traditional' git workflows.".

-----Original Message-----
From: Andrew Ardill [] 
Sent: Monday, 10 December 2012 12:46 PM
To: Matthew Ciancio
Subject: Re: Feature Request - Hide ignored files before checkout

Hi Matt,

On 8 December 2012 11:50, Matthew Ciancio <> wrote:
> Problem: ignore.txt does not "disappear" like foo.txt does and is now 
> just sitting in branchA (and now any other branch I checkout into).
> When I first started using Git, I genuinely thought this was a bug, 
> because it seems so logical to me that ignore files should 
> hide/reappear just like tracked files do, when switching branches.

Let me address this by asking a few questions; *why* do files hide/reappear, 
what is the mechanism behind that and does it really make sense to apply it to 
ignored files.

For each commit, git stores a snapshot of your files. When we switch branches 
we are telling git to restore the previously saved snapshot so we can work with 
those files. This means resetting the working directory so that it looks like 
what we had committed; git will delete files that were part of the current 
checked out snapshot but not the new one, and create files that need to be 
created. As a convenience to users, files that are not tracked are left 'as-is' 
when switching branches.

So we see that in order to hide/reappear a file it has to be tracked in a 
snapshot, and so has to be committed *somewhere*. An ignored file is by 
definition not included in commits, and furthermore you hope to keep these 
files out of your commit history.

> I have been told ways of circumventing this (using commits and 
> un-commits OR using stash), but my reason for avoiding commits is: say 
> you have binary/OS specific files which really do not belong in the 
> commit logs (even locally) and hence should be ignored. What if you 
> want those files in only one branch and not all?
> Stashing doesn't seem appropriate either, because it would get messy.

I am not sure how viable a suggestion this is, but perhaps you can have two 
separate repositories, one tracking your standard branches, and another 
tracking the ignored files. These repositories could be kept in sync through 
submodules or some similar mechanism. This could also allow you to, for 
example, publish the histories of these independently, for example releasing 
the non-ignored repository publicly.
I haven't heard of anyone doing this, but if you need to keep the history clean 
it might be a way of achieving it.
I also don't know what the implications of checking out two repositories into 
the same tree might be, or even if git would allow it in general (maybe if you 
ignored everything belonging to the other
repository?) In any case, this solution could quickly become messy, but if 
carefully controlled might solve your problem. Then again, maybe you can 
achieve what you want using more 'traditional' git workflows.


Andrew Ardill

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to