Re: Feature Request - Hide ignored files before checkout

[Andrew Ardill <andrew.ardill@gmail.com>]

Hi Matt,

On 8 December 2012 11:50, Matthew Ciancio <matthew.ciancio16@gmail.com> 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