RE: Feature Request - Hide ignored files before checkout

["Matthew Ciancio" <matthew.ciancio16@gmail.com>]

I appreciate your involvement, Mr Hamano.

You have made me realise that my intentions were flawed from the beginning,
because I had been misusing the branch feature.

Thank you for your time.

-----Original Message-----
From: Junio C Hamano [mailto:gitster@pobox.com] 
Sent: Sunday, 9 December 2012 8:04 PM
To: Chris Rorvick
Cc: Matthew Ciancio; git@vger.kernel.org
Subject: Re: Feature Request - Hide ignored files before checkout

Chris Rorvick <chris@rorvick.com> writes:

> It's not in branchA, it's just no longer ignored because your changes 
> to .gitignore were effectively reverted by jumping back to the commit 
> that branchA points to.
> ...
> "hide/reappear" is the equivalent to saying "deleted/created" in the 
> case of a tracked file in your working tree.  But how would Git cause 
> an untracked file to reappear?  By definition, it doesn't know 
> anything about the file.

Nicely explained. To make something simply disappear, you could remove it,
but that is obviously not enough to make it reappear.  It has to be stashed
away somewhere before it gets removed, and in the context of (any) SCM, that
is done by committing.

You may have Mac and Windows branches, each of which needs to link with
vendor supplied object file blackbox.o with the rest of the source.  It is
understandable if a project does not want to mix such platform specific
black box binaries in the history of the source.

But that does not necessarily mean the project can totally ignore what
specific black box binary was meant to be used with the rest of the source.

After you released the v1.0 of your product for both Macintosh and Windows,
the vendor may supply updated versions of the blackbox.o binary for these
platforms, and you would start working toward v1.1 of your product using
these updated copies of objects.  Then you find problems in the released
v1.0 software.  Without keeping track of which version of the object was
used to build the released v1.0, you cannot diagnose, build and test a
maintenance update v1.0.1.

The project may add new Macintosh (or Windows) developers.  You can tell new
Macintosh developers to clone and checkout mac branch, and in the same
e-mail, give them the untracked blackbox.o file for that platform, but you
have to rely on human not making mistakes (you may mistakenly send Windows
version of blackbox.o to him, you may send stale Macintosh version, the
developer may misplace the new one and keep using the stale one, etc. etc.).

Some people commit blackbox.o on each platform-specific branch, or all
branches share blackbox-win.o and blackbox-mac.o, only one of which is used
at any given branch, for this exact reason.

The project, for licensing reasons, may not have rights to distribute such a
blackbox object file along with its sources, but the vendor of the blackbox
object may allow individual developer to download and link it from vendor's
site.  In such a case, the project would not want to (and is not allowed to)
commit such object file.  One approach I have seen used in such a case is to
arrange the build procedure so that these individual developers can drop
such an external object next to the project directory, and refer to it as
../blackbox.o when linking.

So "these files are moved away from the working tree upon checking another
branch out, and moved back into the working tree upon checking out this
branch" is pretty much outside the scope of any SCM.  It is not very
interesting, as it is not necessary to solve any real world problem.

Of course, the users can do whatever moving/copying/renaming of untracked
files in their post-checkout hook to be run when a new branch is checked
out.