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:gits...@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 <ch...@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. -- 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
