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 [mailto:andrew.ardill@xxxxxxxxx] Sent: Monday, 10 December 2012 12:46 PM To: Matthew Ciancio Cc: git@xxxxxxxxxxxxxxx Subject: Re: Feature Request - Hide ignored files before checkout Hi Matt, On 8 December 2012 11:50, Matthew Ciancio <matthew.ciancio16@xxxxxxxxx> 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. Regards, Andrew Ardill -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html