{"thread":{"id":"5333","subject":"git refuses to switch to older branches","startedAt":"2006-08-19T20:25:58Z","lastAt":"2006-09-08T22:00:53Z","messageCount":15,"participants":["Martin Waitz","Jakub Narebski","Junio C Hamano","Petr Baudis","Alex Riesen","Johannes Schindelin","Josef Weidendorfer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"25625","messageId":"20060819202558.GE30022@admingilde.org","threadId":"5333","inReplyTo":null,"subject":"git refuses to switch to older branches","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2006-08-19T20:25:58Z","receivedAt":"2006-08-19T20:25:58Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nnow that gitweb.cgi is autogenerated, git refuses to switch to old\nbranches unless force is applied:\n\n\tfatal: Untracked working tree file 'gitweb/gitweb.cgi' would\n\tbe overwritten by merge.\n\nThis safety measure is quite useful normally, but for files that are\nexplicitly marked as to-be-ignored it should not be neccessary.\n\nBut all the code that handles .gitignore is only used by ls-files now.\nDoes it make sense to add exclude handling to unpack-trees.c, too?\n\n-- \nMartin Waitz\n"},{"id":"25630","messageId":"ec80sl$i25$2@sea.gmane.org","threadId":"5333","inReplyTo":"20060819202558.GE30022@admingilde.org","subject":"Re: git refuses to switch to older branches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-19T21:47:09Z","receivedAt":"2006-08-19T21:47:09Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Martin Waitz wrote:\n\n> now that gitweb.cgi is autogenerated, git refuses to switch to old\n> branches unless force is applied:\n> \n>       fatal: Untracked working tree file 'gitweb/gitweb.cgi' would\n>       be overwritten by merge.\n> \n> This safety measure is quite useful normally, but for files that are\n> explicitly marked as to-be-ignored it should not be neccessary.\n> \n> But all the code that handles .gitignore is only used by ls-files now.\n> Does it make sense to add exclude handling to unpack-trees.c, too?\n\nI think it is \"better to be annoying but safe\" idea of git. You can always\ndo \"git checkout <branch> gitweb/gitweb.cgi\" and \"git checkout <branch>\",\nand not use -f.\n\nOr add gitweb.cgi to .gitignore in the old branch.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"25632","messageId":"7vac601hbb.fsf@assigned-by-dhcp.cox.net","threadId":"5333","inReplyTo":"20060819202558.GE30022@admingilde.org","subject":"Re: git refuses to switch to older branches","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-19T22:39:20Z","receivedAt":"2006-08-19T22:39:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Waitz <tali@admingilde.org> writes:\n\n> This safety measure is quite useful normally, but for files that are\n> explicitly marked as to-be-ignored it should not be neccessary.\n>\n> But all the code that handles .gitignore is only used by ls-files now.\n> Does it make sense to add exclude handling to unpack-trees.c, too?\n\nIn principle, I am not opposed to the idea of making read-tree\ntake the ignore information into consideration.\n\nBut I would suggest you to be _extremely_ careful if you want to\ntry this.  I do not have an example offhand, but I would not be\nsurprised at all if there is a valid use case where it is useful\nto have a pattern that matches a tracked file in .gitignore\nfile.\n"},{"id":"25633","messageId":"7v3bbs1h8c.fsf@assigned-by-dhcp.cox.net","threadId":"5333","inReplyTo":"ec80sl$i25$2@sea.gmane.org","subject":"Re: git refuses to switch to older branches","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-19T22:41:07Z","receivedAt":"2006-08-19T22:41:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> Martin Waitz wrote:\n>\n>> now that gitweb.cgi is autogenerated, git refuses to switch to old\n>> branches unless force is applied:\n>> \n>>       fatal: Untracked working tree file 'gitweb/gitweb.cgi' would\n>>       be overwritten by merge.\n>> \n>> This safety measure is quite useful normally, but for files that are\n>> explicitly marked as to-be-ignored it should not be neccessary.\n>> \n>> But all the code that handles .gitignore is only used by ls-files now.\n>> Does it make sense to add exclude handling to unpack-trees.c, too?\n>\n> I think it is \"better to be annoying but safe\" idea of git. You can always\n> do \"git checkout <branch> gitweb/gitweb.cgi\" and \"git checkout <branch>\",\n> and not use -f.\n\nI think you are talking backwards.  Newer branch have .cgi\ngenerated and older branch has it tracked.  After you have built\nin a newer branch, checking out an older branch without -f\noption would play it safe not to clobber .cgi which is\nannoying.  So workaround you would want to suggest is TO USE -f.\n\n> Or add gitweb.cgi to .gitignore in the old branch.\n\nAnd this \"adding something to old one\" is nonsense ;-).\n"},{"id":"25634","messageId":"20060819224457.GB23891@pasky.or.cz","threadId":"5333","inReplyTo":"7vac601hbb.fsf@assigned-by-dhcp.cox.net","subject":"Re: git refuses to switch to older branches","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-08-19T22:44:57Z","receivedAt":"2006-08-19T22:44:57Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Aug 20, 2006 at 12:39:20AM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> said that...\n> But I would suggest you to be _extremely_ careful if you want to\n> try this.  I do not have an example offhand, but I would not be\n> surprised at all if there is a valid use case where it is useful\n> to have a pattern that matches a tracked file in .gitignore\n> file.\n\n  *.o and binary blobs of closed-source software.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"25635","messageId":"ec84gg$p2l$1@sea.gmane.org","threadId":"5333","inReplyTo":"7v3bbs1h8c.fsf@assigned-by-dhcp.cox.net","subject":"Re: git refuses to switch to older branches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-19T22:48:56Z","receivedAt":"2006-08-19T22:48:56Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Jakub Narebski <jnareb@gmail.com> writes:\n> \n>> Martin Waitz wrote:\n>>\n>>> now that gitweb.cgi is autogenerated, git refuses to switch to old\n>>> branches unless force is applied:\n>>> \n>>>       fatal: Untracked working tree file 'gitweb/gitweb.cgi' would\n>>>       be overwritten by merge.\n>>> \n>>> This safety measure is quite useful normally, but for files that are\n>>> explicitly marked as to-be-ignored it should not be neccessary.\n>>> \n>>> But all the code that handles .gitignore is only used by ls-files now.\n>>> Does it make sense to add exclude handling to unpack-trees.c, too?\n>>\n>> I think it is \"better to be annoying but safe\" idea of git. You can always\n>> do \"git checkout <branch> gitweb/gitweb.cgi\" and \"git checkout <branch>\",\n>> and not use -f.\n> \n> I think you are talking backwards.  Newer branch have .cgi\n> generated and older branch has it tracked.  After you have built\n> in a newer branch, checking out an older branch without -f\n> option would play it safe not to clobber .cgi which is\n> annoying.  So workaround you would want to suggest is TO USE -f.\n\nIf I remember correctly that is what I did when \"master\" (and I had switch\nto master to do \"git pull origin\") didn't contain gitweb.cgi -> gitweb.perl\nrename. My proposed solution first overwrites generated gitweb.cgi by\ntracked file (i'm not sure if this is feature or bug that git-checkout\nwith file specified (path limit specified?) doesn't need -f, and then\nyou can do git-checkout full branch without -f.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"25636","messageId":"7vy7tkyyu9.fsf@assigned-by-dhcp.cox.net","threadId":"5333","inReplyTo":"ec84gg$p2l$1@sea.gmane.org","subject":"Re: git refuses to switch to older branches","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-20T01:34:22Z","receivedAt":"2006-08-20T01:34:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> ... I'm not sure if this is feature or bug that git-checkout\n> with file specified (path limit specified?) doesn't need -f\n\nThis is definitely a feature we deliberately added long after\ngit-checkout was initially written, in reponse to specific\nrequests from users.  Back then the only way to revert to index\nor HEAD was to \"checkout-index -f -q -u -a\" or \"reset --hard\"\nand it was cumbersome to revert only a single path.\n\nI have been wondering if we wanted to be able to say:\n\n\tgit checkout HEAD gitweb/\n\nto revert everything under named hierarchy, but we haven't heard\nuser requests for this.  This is way more dangerous than my\nliking so personally I am happy that we do not have it.\n"},{"id":"25638","messageId":"20060820072612.GA6003@steel.home","threadId":"5333","inReplyTo":"7vac601hbb.fsf@assigned-by-dhcp.cox.net","subject":"Re: git refuses to switch to older branches","fromName":"Alex Riesen","fromEmail":"fork0@t-online.de","sentAt":"2006-08-20T07:26:12Z","receivedAt":"2006-08-20T07:26:12Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Junio C Hamano, Sun, Aug 20, 2006 00:39:20 +0200:\n> Martin Waitz <tali@admingilde.org> writes:\n> \n> > This safety measure is quite useful normally, but for files that are\n> > explicitly marked as to-be-ignored it should not be neccessary.\n> >\n> > But all the code that handles .gitignore is only used by ls-files now.\n> > Does it make sense to add exclude handling to unpack-trees.c, too?\n> \n> In principle, I am not opposed to the idea of making read-tree\n> take the ignore information into consideration.\n> \n> But I would suggest you to be _extremely_ careful if you want to\n\nIt should be optional. And off by default, people already have got\nscripts depending on this behaviour (well, I have).\n\n> try this.  I do not have an example offhand, but I would not be\n> surprised at all if there is a valid use case where it is useful\n> to have a pattern that matches a tracked file in .gitignore\n> file.\n> \n\nIgnored directory and but some files/subdirectories in it are tracked,\nbecause this is temporary or externally changed data (I have both\nexamples).\n"},{"id":"25641","messageId":"20060820121935.GF30022@admingilde.org","threadId":"5333","inReplyTo":"20060820072612.GA6003@steel.home","subject":"Re: git refuses to switch to older branches","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2006-08-20T12:19:35Z","receivedAt":"2006-08-20T12:19:35Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Sun, Aug 20, 2006 at 09:26:12AM +0200, Alex Riesen wrote:\n> Junio C Hamano, Sun, Aug 20, 2006 00:39:20 +0200:\n> > Martin Waitz <tali@admingilde.org> writes:\n> > \n> > > This safety measure is quite useful normally, but for files that are\n> > > explicitly marked as to-be-ignored it should not be neccessary.\n> > >\n> > > But all the code that handles .gitignore is only used by ls-files now.\n> > > Does it make sense to add exclude handling to unpack-trees.c, too?\n> > \n> > In principle, I am not opposed to the idea of making read-tree\n> > take the ignore information into consideration.\n> > \n> > But I would suggest you to be _extremely_ careful if you want to\n> \n> It should be optional. And off by default, people already have got\n> scripts depending on this behaviour (well, I have).\n\nbut having this sort of behaviour optional is bad, I think.\nSome people will depend on one semantic and others on the other.\nAnd then get bite if they want to share their scripts.\nWe have to find _one_ semantic that always works.\n\n> > try this.  I do not have an example offhand, but I would not be\n> > surprised at all if there is a valid use case where it is useful\n> > to have a pattern that matches a tracked file in .gitignore\n> > file.\n> \n> Ignored directory and but some files/subdirectories in it are tracked,\n> because this is temporary or externally changed data (I have both\n> examples).\n\nbut do you have non-tracked files in the ignored directory that you\nreally care about, i.e. which must not be overridden by a tracked file\nwith the same name?\n\n-- \nMartin Waitz\n"},{"id":"25642","messageId":"20060820122128.GG30022@admingilde.org","threadId":"5333","inReplyTo":"20060819224457.GB23891@pasky.or.cz","subject":"Re: git refuses to switch to older branches","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2006-08-20T12:21:28Z","receivedAt":"2006-08-20T12:21:28Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Sun, Aug 20, 2006 at 12:44:57AM +0200, Petr Baudis wrote:\n> Dear diary, on Sun, Aug 20, 2006 at 12:39:20AM CEST, I got a letter\n> where Junio C Hamano <junkio@cox.net> said that...\n> > But I would suggest you to be _extremely_ careful if you want to\n> > try this.  I do not have an example offhand, but I would not be\n> > surprised at all if there is a valid use case where it is useful\n> > to have a pattern that matches a tracked file in .gitignore\n> > file.\n> \n>   *.o and binary blobs of closed-source software.\n\nbut if you want to switch from one branch which has the .o file\nbuilt from source to another branch which has the .o file tracked\nin binary form, wouldn't you want to remove the generated file\nin order to store the tracked one from the new branch?\n\n-- \nMartin Waitz\n"},{"id":"25643","messageId":"Pine.LNX.4.63.0608201447470.28360@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5333","inReplyTo":"20060820122128.GG30022@admingilde.org","subject":"Re: git refuses to switch to older branches","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-08-20T12:48:34Z","receivedAt":"2006-08-20T12:48:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 20 Aug 2006, Martin Waitz wrote:\n\n> On Sun, Aug 20, 2006 at 12:44:57AM +0200, Petr Baudis wrote:\n> > Dear diary, on Sun, Aug 20, 2006 at 12:39:20AM CEST, I got a letter\n> > where Junio C Hamano <junkio@cox.net> said that...\n> > > But I would suggest you to be _extremely_ careful if you want to\n> > > try this.  I do not have an example offhand, but I would not be\n> > > surprised at all if there is a valid use case where it is useful\n> > > to have a pattern that matches a tracked file in .gitignore\n> > > file.\n> > \n> >   *.o and binary blobs of closed-source software.\n> \n> but if you want to switch from one branch which has the .o file\n> built from source to another branch which has the .o file tracked\n> in binary form, wouldn't you want to remove the generated file\n> in order to store the tracked one from the new branch?\n\nNot necessarily. Sometimes you have files in your working directory, which \nare not in your repository, you know?\n\nCiao,\nDscho\n"},{"id":"25652","messageId":"20060820181511.GH30022@admingilde.org","threadId":"5333","inReplyTo":"Pine.LNX.4.63.0608201447470.28360@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git refuses to switch to older branches","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2006-08-20T18:15:11Z","receivedAt":"2006-08-20T18:15:11Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Sun, Aug 20, 2006 at 02:48:34PM +0200, Johannes Schindelin wrote:\n> On Sun, 20 Aug 2006, Martin Waitz wrote:\n> > On Sun, Aug 20, 2006 at 12:44:57AM +0200, Petr Baudis wrote:\n> > > Dear diary, on Sun, Aug 20, 2006 at 12:39:20AM CEST, I got a letter\n> > > where Junio C Hamano <junkio@cox.net> said that...\n> > > > But I would suggest you to be _extremely_ careful if you want to\n> > > > try this.  I do not have an example offhand, but I would not be\n> > > > surprised at all if there is a valid use case where it is useful\n> > > > to have a pattern that matches a tracked file in .gitignore\n> > > > file.\n> > > \n> > >   *.o and binary blobs of closed-source software.\n> > \n> > but if you want to switch from one branch which has the .o file\n> > built from source to another branch which has the .o file tracked\n> > in binary form, wouldn't you want to remove the generated file\n> > in order to store the tracked one from the new branch?\n> \n> Not necessarily. Sometimes you have files in your working directory, which \n> are not in your repository, you know?\n\nSure. But we are only talking about files which are explicitly\nignored in one branch and are tracked in another branch.\n\nPerhaps it makes sense to check that the file is _not_ ignored in the\nother branch (in which it is tracked).\nWould such a check make everybody happy?\n\nIs there an easy way to check if some file is marked as ignored in\nan other branch?\n\n\n-- \nMartin Waitz\n"},{"id":"25656","messageId":"Pine.LNX.4.63.0608202044480.28360@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5333","inReplyTo":"20060820181511.GH30022@admingilde.org","subject":"Re: git refuses to switch to older branches","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-08-20T18:46:01Z","receivedAt":"2006-08-20T18:46:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 20 Aug 2006, Martin Waitz wrote:\n\n> hoi :)\n> \n> On Sun, Aug 20, 2006 at 02:48:34PM +0200, Johannes Schindelin wrote:\n> > On Sun, 20 Aug 2006, Martin Waitz wrote:\n> > > On Sun, Aug 20, 2006 at 12:44:57AM +0200, Petr Baudis wrote:\n> > > > Dear diary, on Sun, Aug 20, 2006 at 12:39:20AM CEST, I got a letter\n> > > > where Junio C Hamano <junkio@cox.net> said that...\n> > > > > But I would suggest you to be _extremely_ careful if you want to\n> > > > > try this.  I do not have an example offhand, but I would not be\n> > > > > surprised at all if there is a valid use case where it is useful\n> > > > > to have a pattern that matches a tracked file in .gitignore\n> > > > > file.\n> > > > \n> > > >   *.o and binary blobs of closed-source software.\n> > > \n> > > but if you want to switch from one branch which has the .o file\n> > > built from source to another branch which has the .o file tracked\n> > > in binary form, wouldn't you want to remove the generated file\n> > > in order to store the tracked one from the new branch?\n> > \n> > Not necessarily. Sometimes you have files in your working directory, which \n> > are not in your repository, you know?\n> \n> Sure. But we are only talking about files which are explicitly\n> ignored in one branch and are tracked in another branch.\n> \n> Perhaps it makes sense to check that the file is _not_ ignored in the\n> other branch (in which it is tracked).\n> Would such a check make everybody happy?\n\nActually, I am very happy with the strict checking, and that I can \noverride it with \"-f\".\n\nCiao,\nDscho\n"},{"id":"25658","messageId":"200608202111.33470.Josef.Weidendorfer@gmx.de","threadId":"5333","inReplyTo":"Pine.LNX.4.63.0608201447470.28360@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git refuses to switch to older branches","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-08-20T19:11:33Z","receivedAt":"2006-08-20T19:11:33Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Sunday 20 August 2006 14:48, you wrote:\n> Not necessarily. Sometimes you have files in your working directory, which \n> are not in your repository, you know?\n\nYet, I think it is quite inconvenient the way it is now. The same happens if\nyou track a generated file by accident, and remove it later from tracking.\n\nThe real problem is that there are two reasons to put a file into .gitignore:\nYou do not want to have it tracked and polluting git-status because\n(1) it is temporary and generated\n(2) it is private and not supposed to be in the repository\n\nTo distinguish these cases, we could introduce a per-repository configuration\nfile .git/nevertouch . Comments?\n\nJosef\n"},{"id":"26603","messageId":"20060908220053.GA6011@steel.home","threadId":"5333","inReplyTo":"20060820121935.GF30022@admingilde.org","subject":"Re: git refuses to switch to older branches","fromName":"Alex Riesen","fromEmail":"fork0@t-online.de","sentAt":"2006-09-08T22:00:53Z","receivedAt":"2006-09-08T22:00:53Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Sorry for the answer long overdue, I was on vacation, and quite off\nof the internet.\n\nMartin Waitz, Sun, Aug 20, 2006 14:19:35 +0200:\n> On Sun, Aug 20, 2006 at 09:26:12AM +0200, Alex Riesen wrote:\n> > Junio C Hamano, Sun, Aug 20, 2006 00:39:20 +0200:\n> > > Martin Waitz <tali@admingilde.org> writes:\n> > > \n> > > > This safety measure is quite useful normally, but for files that are\n> > > > explicitly marked as to-be-ignored it should not be neccessary.\n> > > >\n> > > > But all the code that handles .gitignore is only used by ls-files now.\n> > > > Does it make sense to add exclude handling to unpack-trees.c, too?\n> > > \n> > > In principle, I am not opposed to the idea of making read-tree\n> > > take the ignore information into consideration.\n> > > \n> > > But I would suggest you to be _extremely_ careful if you want to\n> > \n> > It should be optional. And off by default, people already have got\n> > scripts depending on this behaviour (well, I have).\n> \n> but having this sort of behaviour optional is bad, I think.\n> Some people will depend on one semantic and others on the other.\n> And then get bite if they want to share their scripts.\n\nSo at least give the people who got there first a chance to have\ntheir scripts working. Why break them?\n\n> We have to find _one_ semantic that always works.\n\nWell, the current semantics always work.\n\n> > > try this.  I do not have an example offhand, but I would not be\n> > > surprised at all if there is a valid use case where it is useful\n> > > to have a pattern that matches a tracked file in .gitignore\n> > > file.\n> > \n> > Ignored directory and but some files/subdirectories in it are tracked,\n> > because this is temporary or externally changed data (I have both\n> > examples).\n> \n> but do you have non-tracked files in the ignored directory that you\n> really care about, i.e. which must not be overridden by a tracked file\n> with the same name?\n> \n\nI don't, but I can easily imagine someone has: a file contained some\nbuild-local configuration, which developer later decided to start\ntracking. Like config.mak in git.\n"}]}