{"thread":{"id":"32291","subject":"Feature Request - Hide ignored files before checkout","startedAt":"2012-12-08T00:50:04Z","lastAt":"2012-12-10T09:47:04Z","messageCount":9,"participants":["Matthew Ciancio","Chris Rorvick","Junio C Hamano","Andrew Ardill","Erik Faye-Lund"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"204601","messageId":"000301cdd4dd$f8554090$e8ffc1b0$@gmail.com","threadId":"32291","inReplyTo":null,"subject":"Feature Request - Hide ignored files before checkout","fromName":"Matthew Ciancio","fromEmail":"matthew.ciancio16@gmail.com","sentAt":"2012-12-08T00:50:04Z","receivedAt":"2012-12-08T00:50:04Z","isPatch":false,"sender":{"key":"matthew.ciancio16@gmail.com","avatar":null},"body":"To whom it may concern,\n\nI am not sure if this is the right place to send this, but I couldn't find\nanything on the web that seemed official, so here goes.\n\nImagine this scenario:\n\n1) You have a Git repo with two branches (branchA and branchB), which are\ncurrently identical.\n2) Checkout to branch.\n3) Create file foo.txt, stage it and commit it.\n4) Create file ignore.txt and add it to the \".gitignore\" file of branchB so\nthat it is successfully ignored by Git.\n5) Checkout to branchA.\n\nProblem: ignore.txt does not \"disappear\" like foo.txt does and is now just\nsitting in branchA (and now any other branch I checkout into).\n\nWhen I first started using Git, I genuinely thought this was a bug, because\nit seems so logical to me that ignore files should hide/reappear just like\ntracked files do, when switching branches.\nI have been told ways of circumventing this (using commits and un-commits OR\nusing stash), but my reason for avoiding commits is: say you have binary/OS\nspecific files which really do not belong in the commit logs (even locally)\nand hence should be ignored. What if you want those files in only one branch\nand not all?\nStashing doesn't seem appropriate either, because it would get messy.\n\nDo you think this warrants a feature request?\n\nIf so, I was thinking that maybe the .gitignore file could have a flag after\neach entry, to indicate whether the file(s)/folder(s) should have this new\nfeature or not (that way it would cater for everyone, but I can't see why\nyou wouldn't want this behaviour). \n\nIf you like this idea and submit this as a feature request, please respond\nwith a link of the official request so that I can follow it, or provide me\nwith a link to submit it myself.\n\nP.S. Here is a forum post I made on StackOverflow about the issue:\nhttp://stackoverflow.com/questions/13761682/gitignore-hide-ignored-files-dur\ning-checkout\n\nKind regards,\nMatt\n"},{"id":"204606","messageId":"CAEUsAPaHJ+N0EnxGuVkRqcmY0fUy+4myMiWtd1_vu1vRL763JQ@mail.gmail.com","threadId":"32291","inReplyTo":"000301cdd4dd$f8554090$e8ffc1b0$@gmail.com","subject":"Re: Feature Request - Hide ignored files before checkout","fromName":"Chris Rorvick","fromEmail":"chris@rorvick.com","sentAt":"2012-12-08T19:21:07Z","receivedAt":"2012-12-08T19:21:07Z","isPatch":false,"sender":{"key":"chris@rorvick.com","avatar":"https://avatars.githubusercontent.com/u/824726?v=4"},"body":"On Fri, Dec 7, 2012 at 6:50 PM, Matthew Ciancio\n<matthew.ciancio16@gmail.com> wrote:\n> Imagine this scenario:\n>\n> 1) You have a Git repo with two branches (branchA and branchB), which are\n> currently identical.\n> 2) Checkout to branch.\n> 3) Create file foo.txt, stage it and commit it.\n> 4) Create file ignore.txt and add it to the \".gitignore\" file of branchB so\n> that it is successfully ignored by Git.\n> 5) Checkout to branchA.\n>\n> Problem: ignore.txt does not \"disappear\" like foo.txt does\n\nWhen you say \"disappear\", do you mean \"deleted from the file system\"\nor something else?\n\n> and is now just\n> sitting in branchA (and now any other branch I checkout into).\n\nIt's not in branchA, it's just no longer ignored because your changes\nto .gitignore were effectively reverted by jumping back to the commit\nthat branchA points to.\n\n> When I first started using Git, I genuinely thought this was a bug, because\n> it seems so logical to me that ignore files should hide/reappear just like\n> tracked files do, when switching branches.\n\n\"hide/reappear\" is the equivalent to saying \"deleted/created\" in the\ncase of a tracked file in your working tree.  But how would Git cause\nan untracked file to reappear?  By definition, it doesn't know\nanything about the file.\n\n> P.S. Here is a forum post I made on StackOverflow about the issue:\n> http://stackoverflow.com/questions/13761682/gitignore-hide-ignored-files-dur\n> ing-checkout\n\nI posted an answer there, too, but I'm not sure I fully understand the\nproblem.  The top-voted answer doesn't make much sense, though.\n\nThanks,\n\nChris\n"},{"id":"204618","messageId":"CAEUsAPaqSQVSNaiJUO3Sfms3Rt2vzsciczXK0impHnXQ52u7mA@mail.gmail.com","threadId":"32291","inReplyTo":"000001cdd5a0$fd23adf0$f76b09d0$@gmail.com","subject":"Re: Feature Request - Hide ignored files before checkout","fromName":"Chris Rorvick","fromEmail":"chris@rorvick.com","sentAt":"2012-12-09T05:54:11Z","receivedAt":"2012-12-09T05:54:11Z","isPatch":false,"sender":{"key":"chris@rorvick.com","avatar":"https://avatars.githubusercontent.com/u/824726?v=4"},"body":"On Sat, Dec 8, 2012 at 6:06 PM, Matthew Ciancio\n<matthew.ciancio16@gmail.com> wrote:\n> Hi Chris,\n>\n> Yes, I don't think I have explained myself well enough.\n>\n> When I say \"disappear\" I do not mean \"get deleted\", I mean: go out of view\n> just like foo.txt does, as it is committed to branchB and not merged into\n> branchA.\n>\n> So I am saying that I think .gitignored files should behave partly like\n> committed and un-merged files, in the sense that they disappear when\n> checking out to a different branch.\n> I don't want to commit these files (which would give me the behaviour I\n> want), because they are binary/OS specific and really do not belong in the\n> repository, BUT I need them to run/build certain committed files.\n>\n> To be concrete: I want ignore.txt to be ignored in branchB and hence\n> disappear (in the same way that foo.txt will), when checking out to branchA.\n> When I checkout back to branchB I want ignore.txt to reappear (in the same\n> way that foo.txt will).\n>\n> I understand why this behaviour is not happening (because my .gitignore\n> files are different between the branches), but I am saying that I would like\n> to have the option to keep my .gitignore'd files local to the branch they\n> are in.\n>\n> E.g. I currently have a branch with all these binary files that are required\n> to run an application on my OS, but when I checkout to another branch I do\n> not need or want those binary files anymore (at least not until I checkout\n> back into the branch I just came from).\n>\n> Please tell me if that still doesn't make sense.\n\nHi Matthew,\n\nCc'ing the list to benefit from the review of others.\n\nNot wanting the files in the repository seems to be in conflict with\nthe desire to have them under its control (i.e., disappear/reappear\nbehavior.)  I understand not wanting to commit dependencies, but why\ndo you need them to disappear?  Why not just put them somewhere where\nthey can be used when needed and left alone when not?\n\nIf you do want this behavior, it seems like you should just commit the\nfiles on the respective branch.  Maybe someone else will have a better\nidea, though.\n\nChris\n"},{"id":"204619","messageId":"000001cdd5e4$b3e98da0$1bbca8e0$@gmail.com","threadId":"32291","inReplyTo":"CAEUsAPaqSQVSNaiJUO3Sfms3Rt2vzsciczXK0impHnXQ52u7mA@mail.gmail.com","subject":"RE: Feature Request - Hide ignored files before checkout","fromName":"Matthew Ciancio","fromEmail":"matthew.ciancio16@gmail.com","sentAt":"2012-12-09T08:10:46Z","receivedAt":"2012-12-09T08:10:46Z","isPatch":false,"sender":{"key":"matthew.ciancio16@gmail.com","avatar":null},"body":"I'm glad we are on the same page now and thanks for bringing in others.\n\n\" Not wanting the files in the repository seems to be in conflict with the\ndesire to have them under its control (i.e., disappear/reappear behavior.) \"\nSorry, when I said I didn't want them in the repository, I meant I wanted\nthem there (in the repository folder), but not within Git commit logs and\nnot being tracked, etc.\nCommitting binary/OS specific files just doesn't sit right with me and I am\nsure many others.\n\n\"... but why do you need them to disappear?  Why not just put them somewhere\nwhere they can be used when needed and left alone when not?\"\nI could do that (keep them in a folder that will be left alone), but in my\nspecific case it would mean the executable files (ignored files placed in\nthis new folder) will not execute because of the change in location and\nhence would require a lot of code change to suit.\n\n>From my perspective I don't see the harm in having this as a new feature\n(via flags in the .gitignore file, if you don't want to make it default\nbehaviour). Is there some reason I don't know about, maybe to do with the\nGit source code?\n\n-----Original Message-----\nFrom: chris.rorvick@gmail.com [mailto:chris.rorvick@gmail.com] On Behalf Of\nChris Rorvick\nSent: Sunday, 9 December 2012 4:54 PM\nTo: Matthew Ciancio\nCc: git@vger.kernel.org\nSubject: Re: Feature Request - Hide ignored files before checkout\n\nOn Sat, Dec 8, 2012 at 6:06 PM, Matthew Ciancio\n<matthew.ciancio16@gmail.com> wrote:\n> Hi Chris,\n>\n> Yes, I don't think I have explained myself well enough.\n>\n> When I say \"disappear\" I do not mean \"get deleted\", I mean: go out of \n> view just like foo.txt does, as it is committed to branchB and not \n> merged into branchA.\n>\n> So I am saying that I think .gitignored files should behave partly \n> like committed and un-merged files, in the sense that they disappear \n> when checking out to a different branch.\n> I don't want to commit these files (which would give me the behaviour \n> I want), because they are binary/OS specific and really do not belong \n> in the repository, BUT I need them to run/build certain committed files.\n>\n> To be concrete: I want ignore.txt to be ignored in branchB and hence \n> disappear (in the same way that foo.txt will), when checking out to\nbranchA.\n> When I checkout back to branchB I want ignore.txt to reappear (in the \n> same way that foo.txt will).\n>\n> I understand why this behaviour is not happening (because my \n> .gitignore files are different between the branches), but I am saying \n> that I would like to have the option to keep my .gitignore'd files \n> local to the branch they are in.\n>\n> E.g. I currently have a branch with all these binary files that are \n> required to run an application on my OS, but when I checkout to \n> another branch I do not need or want those binary files anymore (at \n> least not until I checkout back into the branch I just came from).\n>\n> Please tell me if that still doesn't make sense.\n\nHi Matthew,\n\nCc'ing the list to benefit from the review of others.\n\nNot wanting the files in the repository seems to be in conflict with the\ndesire to have them under its control (i.e., disappear/reappear\nbehavior.)  I understand not wanting to commit dependencies, but why do you\nneed them to disappear?  Why not just put them somewhere where they can be\nused when needed and left alone when not?\n\nIf you do want this behavior, it seems like you should just commit the files\non the respective branch.  Maybe someone else will have a better idea,\nthough.\n\nChris\n"},{"id":"204620","messageId":"7vhanvegvu.fsf@alter.siamese.dyndns.org","threadId":"32291","inReplyTo":"CAEUsAPaHJ+N0EnxGuVkRqcmY0fUy+4myMiWtd1_vu1vRL763JQ@mail.gmail.com","subject":"Re: Feature Request - Hide ignored files before checkout","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-09T09:04:05Z","receivedAt":"2012-12-09T09:04:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris Rorvick <chris@rorvick.com> writes:\n\n> It's not in branchA, it's just no longer ignored because your changes\n> to .gitignore were effectively reverted by jumping back to the commit\n> that branchA points to.\n> ...\n> \"hide/reappear\" is the equivalent to saying \"deleted/created\" in the\n> case of a tracked file in your working tree.  But how would Git cause\n> an untracked file to reappear?  By definition, it doesn't know\n> anything about the file.\n\nNicely explained. To make something simply disappear, you could\nremove it, but that is obviously not enough to make it reappear.  It\nhas to be stashed away somewhere before it gets removed, and in the\ncontext of (any) SCM, that is done by committing.\n\nYou may have Mac and Windows branches, each of which needs to link\nwith vendor supplied object file blackbox.o with the rest of the\nsource.  It is understandable if a project does not want to mix such\nplatform specific black box binaries in the history of the source.\n\nBut that does not necessarily mean the project can totally ignore\nwhat specific black box binary was meant to be used with the rest of\nthe source.\n\nAfter you released the v1.0 of your product for both Macintosh and\nWindows, the vendor may supply updated versions of the blackbox.o\nbinary for these platforms, and you would start working toward v1.1\nof your product using these updated copies of objects.  Then you\nfind problems in the released v1.0 software.  Without keeping track\nof which version of the object was used to build the released v1.0,\nyou cannot diagnose, build and test a maintenance update v1.0.1.\n\nThe project may add new Macintosh (or Windows) developers.  You can\ntell new Macintosh developers to clone and checkout mac branch, and\nin the same e-mail, give them the untracked blackbox.o file for that\nplatform, but you have to rely on human not making mistakes (you may\nmistakenly send Windows version of blackbox.o to him, you may send\nstale Macintosh version, the developer may misplace the new one and\nkeep using the stale one, etc. etc.).\n\nSome people commit blackbox.o on each platform-specific branch, or\nall branches share blackbox-win.o and blackbox-mac.o, only one of\nwhich is used at any given branch, for this exact reason.\n\nThe project, for licensing reasons, may not have rights to\ndistribute such a blackbox object file along with its sources, but\nthe vendor of the blackbox object may allow individual developer to\ndownload and link it from vendor's site.  In such a case, the\nproject would not want to (and is not allowed to) commit such object\nfile.  One approach I have seen used in such a case is to arrange\nthe build procedure so that these individual developers can drop\nsuch an external object next to the project directory, and refer to\nit as ../blackbox.o when linking.\n\nSo \"these files are moved away from the working tree upon checking\nanother branch out, and moved back into the working tree upon\nchecking out this branch\" is pretty much outside the scope of any\nSCM.  It is not very interesting, as it is not necessary to solve\nany real world problem.\n\nOf course, the users can do whatever moving/copying/renaming of\nuntracked files in their post-checkout hook to be run when a new\nbranch is checked out.\n"},{"id":"204634","messageId":"000301cdd65d$ce311c40$6a9354c0$@gmail.com","threadId":"32291","inReplyTo":"7vhanvegvu.fsf@alter.siamese.dyndns.org","subject":"RE: Feature Request - Hide ignored files before checkout","fromName":"Matthew Ciancio","fromEmail":"matthew.ciancio16@gmail.com","sentAt":"2012-12-09T22:37:39Z","receivedAt":"2012-12-09T22:37:39Z","isPatch":false,"sender":{"key":"matthew.ciancio16@gmail.com","avatar":null},"body":"I appreciate your involvement, Mr Hamano.\n\nYou have made me realise that my intentions were flawed from the beginning,\nbecause I had been misusing the branch feature.\n\nThank you for your time.\n\n-----Original Message-----\nFrom: Junio C Hamano [mailto:gitster@pobox.com] \nSent: Sunday, 9 December 2012 8:04 PM\nTo: Chris Rorvick\nCc: Matthew Ciancio; git@vger.kernel.org\nSubject: Re: Feature Request - Hide ignored files before checkout\n\nChris Rorvick <chris@rorvick.com> writes:\n\n> It's not in branchA, it's just no longer ignored because your changes \n> to .gitignore were effectively reverted by jumping back to the commit \n> that branchA points to.\n> ...\n> \"hide/reappear\" is the equivalent to saying \"deleted/created\" in the \n> case of a tracked file in your working tree.  But how would Git cause \n> an untracked file to reappear?  By definition, it doesn't know \n> anything about the file.\n\nNicely explained. To make something simply disappear, you could remove it,\nbut that is obviously not enough to make it reappear.  It has to be stashed\naway somewhere before it gets removed, and in the context of (any) SCM, that\nis done by committing.\n\nYou may have Mac and Windows branches, each of which needs to link with\nvendor supplied object file blackbox.o with the rest of the source.  It is\nunderstandable if a project does not want to mix such platform specific\nblack box binaries in the history of the source.\n\nBut that does not necessarily mean the project can totally ignore what\nspecific black box binary was meant to be used with the rest of the source.\n\nAfter you released the v1.0 of your product for both Macintosh and Windows,\nthe vendor may supply updated versions of the blackbox.o binary for these\nplatforms, and you would start working toward v1.1 of your product using\nthese updated copies of objects.  Then you find problems in the released\nv1.0 software.  Without keeping track of which version of the object was\nused to build the released v1.0, you cannot diagnose, build and test a\nmaintenance update v1.0.1.\n\nThe project may add new Macintosh (or Windows) developers.  You can tell new\nMacintosh developers to clone and checkout mac branch, and in the same\ne-mail, give them the untracked blackbox.o file for that platform, but you\nhave to rely on human not making mistakes (you may mistakenly send Windows\nversion of blackbox.o to him, you may send stale Macintosh version, the\ndeveloper may misplace the new one and keep using the stale one, etc. etc.).\n\nSome people commit blackbox.o on each platform-specific branch, or all\nbranches share blackbox-win.o and blackbox-mac.o, only one of which is used\nat any given branch, for this exact reason.\n\nThe project, for licensing reasons, may not have rights to distribute such a\nblackbox object file along with its sources, but the vendor of the blackbox\nobject may allow individual developer to download and link it from vendor's\nsite.  In such a case, the project would not want to (and is not allowed to)\ncommit such object file.  One approach I have seen used in such a case is to\narrange the build procedure so that these individual developers can drop\nsuch an external object next to the project directory, and refer to it as\n../blackbox.o when linking.\n\nSo \"these files are moved away from the working tree upon checking another\nbranch out, and moved back into the working tree upon checking out this\nbranch\" is pretty much outside the scope of any SCM.  It is not very\ninteresting, as it is not necessary to solve any real world problem.\n\nOf course, the users can do whatever moving/copying/renaming of untracked\nfiles in their post-checkout hook to be run when a new branch is checked\nout.\n"},{"id":"204637","messageId":"CAH5451m-JcgLtvVER1UgvsFzemb=otG3XttR4j2s=eFnPrPyEQ@mail.gmail.com","threadId":"32291","inReplyTo":"000301cdd4dd$f8554090$e8ffc1b0$@gmail.com","subject":"Re: Feature Request - Hide ignored files before checkout","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-12-10T01:46:05Z","receivedAt":"2012-12-10T01:46:05Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"Hi Matt,\n\nOn 8 December 2012 11:50, Matthew Ciancio <matthew.ciancio16@gmail.com> wrote:\n> Problem: ignore.txt does not \"disappear\" like foo.txt does and is now just\n> sitting in branchA (and now any other branch I checkout into).\n>\n> When I first started using Git, I genuinely thought this was a bug, because\n> it seems so logical to me that ignore files should hide/reappear just like\n> tracked files do, when switching branches.\n\nLet me address this by asking a few questions; *why* do files\nhide/reappear, what is the mechanism behind that and does it really\nmake sense to apply it to ignored files.\n\nFor each commit, git stores a snapshot of your files. When we switch\nbranches we are telling git to restore the previously saved snapshot\nso we can work with those files. This means resetting the working\ndirectory so that it looks like what we had committed; git will delete\nfiles that were part of the current checked out snapshot but not the\nnew one, and create files that need to be created. As a convenience to\nusers, files that are not tracked are left 'as-is' when switching\nbranches.\n\nSo we see that in order to hide/reappear a file it has to be tracked\nin a snapshot, and so has to be committed *somewhere*. An ignored file\nis by definition not included in commits, and furthermore you hope to\nkeep these files out of your commit history.\n\n> I have been told ways of circumventing this (using commits and un-commits OR\n> using stash), but my reason for avoiding commits is: say you have binary/OS\n> specific files which really do not belong in the commit logs (even locally)\n> and hence should be ignored. What if you want those files in only one branch\n> and not all?\n> Stashing doesn't seem appropriate either, because it would get messy.\n\nI am not sure how viable a suggestion this is, but perhaps you can\nhave two separate repositories, one tracking your standard branches,\nand another tracking the ignored files. These repositories could be\nkept in sync through submodules or some similar mechanism. This could\nalso allow you to, for example, publish the histories of these\nindependently, for example releasing the non-ignored repository\npublicly.\nI haven't heard of anyone doing this, but if you need to keep the\nhistory clean it might be a way of achieving it.\nI also don't know what the implications of checking out two\nrepositories into the same tree might be, or even if git would allow\nit in general (maybe if you ignored everything belonging to the other\nrepository?) In any case, this solution could quickly become messy,\nbut if carefully controlled might solve your problem. Then again,\nmaybe you can achieve what you want using more 'traditional' git\nworkflows.\n\nRegards,\n\nAndrew Ardill\n"},{"id":"204638","messageId":"000001cdd67a$39be9d40$ad3bd7c0$@gmail.com","threadId":"32291","inReplyTo":"CAH5451m-JcgLtvVER1UgvsFzemb=otG3XttR4j2s=eFnPrPyEQ@mail.gmail.com","subject":"RE: Feature Request - Hide ignored files before checkout","fromName":"Matthew Ciancio","fromEmail":"matthew.ciancio16@gmail.com","sentAt":"2012-12-10T02:01:05Z","receivedAt":"2012-12-10T02:01:05Z","isPatch":false,"sender":{"key":"matthew.ciancio16@gmail.com","avatar":null},"body":"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.\n\nI have overcome the problem by re-organising my repository and \"... using more 'traditional' git workflows.\".\n\n-----Original Message-----\nFrom: Andrew Ardill [mailto:andrew.ardill@gmail.com] \nSent: Monday, 10 December 2012 12:46 PM\nTo: Matthew Ciancio\nCc: git@vger.kernel.org\nSubject: Re: Feature Request - Hide ignored files before checkout\n\nHi Matt,\n\nOn 8 December 2012 11:50, Matthew Ciancio <matthew.ciancio16@gmail.com> wrote:\n> Problem: ignore.txt does not \"disappear\" like foo.txt does and is now \n> just sitting in branchA (and now any other branch I checkout into).\n>\n> When I first started using Git, I genuinely thought this was a bug, \n> because it seems so logical to me that ignore files should \n> hide/reappear just like tracked files do, when switching branches.\n\nLet 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.\n\nFor 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.\n\nSo 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.\n\n> I have been told ways of circumventing this (using commits and \n> un-commits OR using stash), but my reason for avoiding commits is: say \n> you have binary/OS specific files which really do not belong in the \n> commit logs (even locally) and hence should be ignored. What if you \n> want those files in only one branch and not all?\n> Stashing doesn't seem appropriate either, because it would get messy.\n\nI 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.\nI haven't heard of anyone doing this, but if you need to keep the history clean it might be a way of achieving it.\nI 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\nrepository?) 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.\n\nRegards,\n\nAndrew Ardill\n"},{"id":"204644","messageId":"CABPQNSb_ovfJ3oO0rEYd5GXU37Xvk-3mhEtX07BX1OCtoFOExA@mail.gmail.com","threadId":"32291","inReplyTo":"000001cdd67a$39be9d40$ad3bd7c0$@gmail.com","subject":"Re: Feature Request - Hide ignored files before checkout","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2012-12-10T09:47:04Z","receivedAt":"2012-12-10T09:47:04Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Mon, Dec 10, 2012 at 3:01 AM, Matthew Ciancio\n<matthew.ciancio16@gmail.com> wrote:\n> 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.\n>\n\nI have played around with the idea of backing up files deleted by\ngit-clean in the object database, maintained by a reflog (similar to\ngit-stash). I did this to protect my code against my fat fingers, but\nperhaps this could also have been useful in your case?\n\nhttps://github.com/kusma/git/tree/work/clean-backup\n"}]}