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