Chris Rorvick <> 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.
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