{"thread":{"id":"27951","subject":"gitignore design","startedAt":"2011-07-29T10:20:32Z","lastAt":"2011-07-30T16:01:24Z","messageCount":20,"participants":["llucianf","Ferry Huberts","Jakub Narebski","Johannes Sixt","Philip Oakley","Nguyen Thai Ngoc Duy","Piotr Krukowiecki","Clemens Buchacher"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"172323","messageId":"1311934832699-6632987.post@n2.nabble.com","threadId":"27951","inReplyTo":null,"subject":"gitignore design","fromName":"llucianf","fromEmail":"llucianf@gmail.com","sentAt":"2011-07-29T10:20:32Z","receivedAt":"2011-07-29T10:20:32Z","isPatch":false,"sender":{"key":"llucianf@gmail.com","avatar":null},"body":"why gitignore doesnt simply work like in cvs where if you put something in\nthe ignore file, those stuff are simply ignored from that point without\nhaving to remove them from repo?\n\n\n--\nView this message in context: http://git.661346.n2.nabble.com/gitignore-design-tp6632987p6632987.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"172324","messageId":"4E329EDB.6040007@hupie.com","threadId":"27951","inReplyTo":"1311934832699-6632987.post@n2.nabble.com","subject":"Re: gitignore design","fromName":"Ferry Huberts","fromEmail":"mailings@hupie.com","sentAt":"2011-07-29T11:51:55Z","receivedAt":"2011-07-29T11:51:55Z","isPatch":false,"sender":{"key":"mailings@hupie.com","avatar":"https://gravatar.com/avatar/ca355376c0713475e17ae413a49f6b98bcbc54cd8364cab7113c53107fb839bb?d=mp&s=160"},"body":"On 07/29/2011 12:20 PM, llucianf wrote:\n> why gitignore doesnt simply work like in cvs where if you put something in\n> the ignore file, those stuff are simply ignored from that point without\n> having to remove them from repo?\n> \n\nbecause when it's in the repo you obviously want to track it...\ntracking trumps ignoring\n\n\nif you now suddenly do not want to track it anymore you have to remove\nit and ignore it.\n\n\n-- \nFerry Huberts\n"},{"id":"172332","messageId":"1311940877783-6633274.post@n2.nabble.com","threadId":"27951","inReplyTo":"4E329EDB.6040007@hupie.com","subject":"Re: gitignore design","fromName":"llucianf","fromEmail":"llucianf@gmail.com","sentAt":"2011-07-29T12:01:17Z","receivedAt":"2011-07-29T12:01:17Z","isPatch":false,"sender":{"key":"llucianf@gmail.com","avatar":null},"body":"sorry but this is not always the case. there are plenty of cases (project\nfiles is most common example) in which i need files in repo but i do not\nneed git to track them. so why i cant just simply enumerate those project\nfiles into .gitignore and 'persuade'  git to simply forget about them?\n\n\n--\nView this message in context: http://git.661346.n2.nabble.com/gitignore-design-tp6632987p6633274.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"172333","messageId":"4E32A2D2.9060007@hupie.com","threadId":"27951","inReplyTo":"1311940877783-6633274.post@n2.nabble.com","subject":"Re: gitignore design","fromName":"Ferry Huberts","fromEmail":"mailings@hupie.com","sentAt":"2011-07-29T12:08:50Z","receivedAt":"2011-07-29T12:08:50Z","isPatch":false,"sender":{"key":"mailings@hupie.com","avatar":"https://gravatar.com/avatar/ca355376c0713475e17ae413a49f6b98bcbc54cd8364cab7113c53107fb839bb?d=mp&s=160"},"body":"On 07/29/2011 02:01 PM, llucianf wrote:\n> sorry but this is not always the case. there are plenty of cases (project\n> files is most common example) in which i need files in repo but i do not\n> need git to track them. so why i cant just simply enumerate those project\n\nthis is a contradiction: you want them tracked (they're in the repo) but\nyou do not want them tracked.\n\nyou can't have it both ways.\n\ngit works this way.\n\n git != cvs\n\n-- \nFerry Huberts\n"},{"id":"172334","messageId":"1311941774976-6633332.post@n2.nabble.com","threadId":"27951","inReplyTo":"4E32A2D2.9060007@hupie.com","subject":"Re: gitignore design","fromName":"llucianf","fromEmail":"llucianf@gmail.com","sentAt":"2011-07-29T12:16:14Z","receivedAt":"2011-07-29T12:16:14Z","isPatch":false,"sender":{"key":"llucianf@gmail.com","avatar":null},"body":"is not a contradiction. i need project files into repo so whenever i clone\nthe project on diff machine i need them there.\nbut during development i dont need them to be 'taken into account' by git. \nthe purpose of this topic is for me to understand why git dont use the\nsimple cvs approach on this matter.\nwhy i cant just enumerate some files into .gitignore file and have git\nsimply ignore them without removing them from repo?\n\n--\nView this message in context: http://git.661346.n2.nabble.com/gitignore-design-tp6632987p6633332.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"172335","messageId":"m339hps2is.fsf@localhost.localdomain","threadId":"27951","inReplyTo":"1311940877783-6633274.post@n2.nabble.com","subject":"Re: gitignore design","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-07-29T12:19:51Z","receivedAt":"2011-07-29T12:19:51Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"llucianf <llucianf@gmail.com> writes:\n> Ferry Huberts <mailings@hupie.com> writes:\n> > On 07/29/2011 12:20 PM, llucianf wrote:\n\n> > > why gitignore doesnt simply work like in cvs where if you put something in\n> > > the ignore file, those stuff are simply ignored from that point without\n> > > having to remove them from repo?\n\nAre you sure that cvsignore file makes CVS to ignore changes in\n_tracked_ files (in repository)?  CVS manual says:\n\n  Ignoring files via cvsignore\n  ============================\n\n     There are certain file names that frequently occur inside your\n  working copy, but that you don't want to put under CVS control.\n  Examples are all the object files that you get while you compile your\n  sources.  Normally, when you run `cvs update', it prints a line for\n  each file it encounters that it doesn't know about.\n\nTracked files (in repository) are by definition not unknown to version\ncontrol system, be it CVS or Git.\n \n> > because when it's in the repo you obviously want to track it...\n> > tracking trumps ignoring\n> > \n> > if you now suddenly do not want to track it anymore you have to remove\n> > it and ignore it.\n>\n> sorry but this is not always the case.\n\nBut it is _usually_ the case, and that is why gitignore works as it\ndoes, being only about _untracked_ files.\n\n>                                        there are plenty of cases (project\n> files is most common example) in which i need files in repo but i do not\n> need git to track them. so why i cant just simply enumerate those project\n> files into .gitignore and 'persuade'  git to simply forget about them?\n\nFor that you can use 'assume-unachanged' mechanism (note: it is local\nto repository).  The gitignore(7) manpage says:\n\n  NOTES\n     The purpose of gitignore files is to ensure that certain files not tracked\n     by git remain untracked.\n\n     To ignore uncommitted changes in a file that is already tracked, use\n     `git update-index --assume-unchanged <file>`.\n\n\nOr just don't use 'git commit -a' and commit with dirty tree.\n\n-- \nJakub Narębski\n"},{"id":"172336","messageId":"m3y5zhqnlv.fsf@localhost.localdomain","threadId":"27951","inReplyTo":"1311941774976-6633332.post@n2.nabble.com","subject":"Re: gitignore design","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-07-29T12:27:13Z","receivedAt":"2011-07-29T12:27:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"llucianf <llucianf@gmail.com> writes:\n\n> is not a contradiction. i need project files into repo so whenever i clone\n> the project on diff machine i need them there.\n> but during development i dont need them to be 'taken into account' by git. \n\nThe usual solution is to put _template_ under version control (for\nexample <projfile>.sample), and have build system create initial\ncustom version during first build.  Local project file is untracked\nand ignored, and project file template is tracked.\n\n> the purpose of this topic is for me to understand why git dont use the\n> simple cvs approach on this matter.\n\nAre you sure that is how CVS does it?  Because from what I read in CVS\nmanual, CVS and Git approach to ignore files are the same wrt. already\ntracked files.\n\n> why i cant just enumerate some files into .gitignore file and have git\n> simply ignore them without removing them from repo?\n\nThere is assume-unchanged mechanism... which is _explicitely_\nmentioned in \"Notes\" section of gitignore(7) manpage.  RTFM, please.\n\n-- \nJakub Narębski\n"},{"id":"172337","messageId":"1311943481799-6633412.post@n2.nabble.com","threadId":"27951","inReplyTo":"m3y5zhqnlv.fsf@localhost.localdomain","subject":"Re: gitignore design","fromName":"llucianf","fromEmail":"llucianf@gmail.com","sentAt":"2011-07-29T12:44:41Z","receivedAt":"2011-07-29T12:44:41Z","isPatch":false,"sender":{"key":"llucianf@gmail.com","avatar":null},"body":"im sure cvs doesnt require you to remove files from repo in order to ignore\nthem. i used cvs for years and its ingonre policy is simple and effective.\nyou just put the files/patterns into ignore file and things happen aka they\nare ignored.\nwith this very intelligent git this simple thing is not so simple. of course\nthere are workarounds (like the template example you gave) but they are\nclumsy.\nim just trying to understand why git ignore mechanism cant just read the\n.gitignore file and obey to those ignore rules without asking you to do\nfancy voodoo operations such removing those files from repo.\n\n\n--\nView this message in context: http://git.661346.n2.nabble.com/gitignore-design-tp6632987p6633412.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"172338","messageId":"m3tya5qm86.fsf@localhost.localdomain","threadId":"27951","inReplyTo":"1311943481799-6633412.post@n2.nabble.com","subject":"Re: gitignore design","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-07-29T12:57:02Z","receivedAt":"2011-07-29T12:57:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"llucianf <llucianf@gmail.com> writes:\n\n> im sure cvs doesnt require you to remove files from repo in order to ignore\n> them. i used cvs for years and its ingonre policy is simple and effective.\n> you just put the files/patterns into ignore file and things happen aka they\n> are ignored.\n\n_Untracked_ files are ignored.  Tracked files are not, even with CVS.\n\n  $ echo file2.txt >>.cvsignore\n  $ echo \"3 line\"  >>file2.txt\n\nNow 'cvs status' shows file as \n\n  File: file2.txt         Status: Locally Modified\n\nand 'cvs diff' shows changes.\n\nCVS 1.11.19\n\n[And damn, how hard it was to check this in CVS as compared to\n checking similar things with Git].\n\n> with this very intelligent git this simple thing is not so simple. of course\n> there are workarounds (like the template example you gave) but they are\n> clumsy.\n\nThey are correct and better solutions than ignoring changes.\n\nIgnoring changes to tracked files is much more rare than having broad\nignore file, and tracking some files that match ignore patterns (but\nnote that you must use \"git add --force\" to add/track ignored file).\n\n> im just trying to understand why git ignore mechanism cant just read the\n> .gitignore file and obey to those ignore rules without asking you to do\n> fancy voodoo operations such removing those files from repo.\n\nPlease read carefully: I mentioned 'ASSUME-UNCHANGED' mechanism in\nboth of my posts, haven't I?\n\n-- \nJakub Narębski\n"},{"id":"172339","messageId":"4E32AE7C.70004@viscovery.net","threadId":"27951","inReplyTo":"m339hps2is.fsf@localhost.localdomain","subject":"Re: gitignore design","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2011-07-29T12:58:36Z","receivedAt":"2011-07-29T12:58:36Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 7/29/2011 14:19, schrieb Jakub Narebski:\n> For that you can use 'assume-unachanged' mechanism (note: it is local\n> to repository).  The gitignore(7) manpage says:\n> \n>   NOTES\n>      The purpose of gitignore files is to ensure that certain files not tracked\n>      by git remain untracked.\n> \n>      To ignore uncommitted changes in a file that is already tracked, use\n>      `git update-index --assume-unchanged <file>`.\n\nThis statement in our documentation is *wrong*!! Please do not suggest it\nfor cases like the OP's!\n\nSee the discussion of assume-unchanged in git-update-index: This bit\nactually means that git may assume that the file was not changed, and it\ncan take the worktree's data when it otherwise would have to unpack the\nindex's data. IOW, using it for the purposes that the OP would need is\n*dangerous*.\n\n-- Hannes\n"},{"id":"172341","messageId":"m3pqktql6s.fsf@localhost.localdomain","threadId":"27951","inReplyTo":"4E32AE7C.70004@viscovery.net","subject":"Re: gitignore design","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-07-29T13:19:44Z","receivedAt":"2011-07-29T13:19:44Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Sixt <j.sixt@viscovery.net> writes:\n> Am 7/29/2011 14:19, schrieb Jakub Narebski:\n> > For that you can use 'assume-unachanged' mechanism (note: it is local\n> > to repository).  The gitignore(7) manpage says:\n> > \n> >   NOTES\n> >      The purpose of gitignore files is to ensure that certain files not tracked\n> >      by git remain untracked.\n> > \n> >      To ignore uncommitted changes in a file that is already tracked, use\n> >      `git update-index --assume-unchanged <file>`.\n> \n> This statement in our documentation is *wrong*!! Please do not suggest it\n> for cases like the OP's!\n> \n> See the discussion of assume-unchanged in git-update-index: This bit\n> actually means that git may assume that the file was not changed, and it\n> can take the worktree's data when it otherwise would have to unpack the\n> index's data. IOW, using it for the purposes that the OP would need is\n> *dangerous*.\n\nAre you sure?  It seems to work as I thought it would.\n\n  $ git init\n  Initialized empty Git repository in /tmp/jnareb/test/.git/\n  [master!test]$ echo foo >foo\n  [master!test]$ echo bar >bar\n  [master!test]$ echo bar >.gitignore\n  [master!test]$ git add .\n  [master!test]$ git commit -m Initial\n  [master (root-commit) 522267b] Initial\n   2 files changed, 2 insertions(+), 0 deletions(-)\n   create mode 100644 .gitignore\n   create mode 100644 foo\n  [master!test]$ git add -f bar\n  [master!test]$ git commit -m 'Add bar (ignored)'\n  [master a708f70] Add bar (ignored)\n   1 files changed, 1 insertions(+), 0 deletions(-)\n   create mode 100644 bar\n  [master!test]$ echo foo >>foo\n  [master!test]$ echo bar >>bar\n  [master!test]$ git status -s\n   M bar\n   M foo\n  [master!test]$ git update-index --assume-unchanged bar\n  [master!test]$ git status -s\n   M foo\n  [master!test]$ git commit -a -m \"assume-unchanged bar, both changed\"\n  [master ec74f8e] assume-unchanged bar, both changed\n   1 files changed, 1 insertions(+), 0 deletions(-)\n  [master!test]$ git status -s\n  [master!test]$ git show\n  commit ec74f8e3f3f819bba22453324d7659fe8dd253e8\n  Author: Jakub Narebski <jnareb@gmail.com>\n  Date:   Fri Jul 29 44 2011 +0200\n  \n      assume-unchanged bar, both changed\n  \n  diff --git a/foo b/foo\n  index 257cc56..0d55bed 100644\n  --- a/foo\n  +++ b/foo\n  @@ -1 +1,2 @@\n   foo\n  +foo\n\nNotice that change to 'bar' didn't get comitted.\n\n-- \nJakub Narębski\n"},{"id":"172343","messageId":"4E32B637.1030201@viscovery.net","threadId":"27951","inReplyTo":"m3pqktql6s.fsf@localhost.localdomain","subject":"Re: gitignore design","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2011-07-29T13:31:35Z","receivedAt":"2011-07-29T13:31:35Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 7/29/2011 15:19, schrieb Jakub Narebski:\n> Are you sure?  It seems to work as I thought it would.\n> [...]\n> Notice that change to 'bar' didn't get comitted.\n\nOf course, it didn't get committed, you promised not to change it, so why\nshould git commit it?\n\nHowever, your example does not show the dangerous part. git-commit is not\ndangerous. But you might run into trouble when git has to merge content\ninto the worktree or index; in this case, git may decide to just read the\nfile instead of to unpack an object - assuming that the content on disk is\nidentical to the unpacked object (it will do so because with\n--assume-unchanged you promised not to change the file). If you broke your\npromise, you get to what you deserve ;)\n\nNo code reference, sorry, because I'm just parrotting what I've read\nelsewhere on the list, for example,\nhttp://thread.gmane.org/gmane.comp.version-control.git/146082/focus=146353\n\n-- Hannes\n"},{"id":"172345","messageId":"4E32BD2C.4090508@hupie.com","threadId":"27951","inReplyTo":"m3tya5qm86.fsf@localhost.localdomain","subject":"Re: gitignore design","fromName":"Ferry Huberts","fromEmail":"mailings@hupie.com","sentAt":"2011-07-29T14:01:16Z","receivedAt":"2011-07-29T14:01:16Z","isPatch":false,"sender":{"key":"mailings@hupie.com","avatar":"https://gravatar.com/avatar/ca355376c0713475e17ae413a49f6b98bcbc54cd8364cab7113c53107fb839bb?d=mp&s=160"},"body":"On 07/29/2011 02:57 PM, Jakub Narebski wrote:\n> llucianf <llucianf@gmail.com> writes:\n> \n>> im sure cvs doesnt require you to remove files from repo in order to ignore\n>> them. i used cvs for years and its ingonre policy is simple and effective.\n>> you just put the files/patterns into ignore file and things happen aka they\n>> are ignored.\n> \n> _Untracked_ files are ignored.  Tracked files are not, even with CVS.\n\n\nyeah llucianf, you could have checked this yourself...\n\n\nthe way it works now is safer: if someone by accident puts a tracked\nfile in an ignore file then the file is still not ignored.\nyou actually _want_ to see the file changes since you are after all\ntracking the file.\n\ngit takes a safe route here.\n\nhaving the file ignored while it is still in the repo can lead to very\nvery strange situation.\n\nsuppose someone puts a complicated ignore pattern in an ignore file that\nhas a mistake in it. then 'real' files might be ignored by the pattern\nby git will still see the changes.\n\nbut to come back to cvs: cvs appears to do the same as git does so your\ncomplaint is unfounded.\n\n> \n>   $ echo file2.txt >>.cvsignore\n>   $ echo \"3 line\"  >>file2.txt\n> \n> Now 'cvs status' shows file as \n> \n>   File: file2.txt         Status: Locally Modified\n> \n> and 'cvs diff' shows changes.\n> \n> CVS 1.11.19\n> \n> [And damn, how hard it was to check this in CVS as compared to\n>  checking similar things with Git].\n> \n>> with this very intelligent git this simple thing is not so simple. of course\n>> there are workarounds (like the template example you gave) but they are\n>> clumsy.\n> \n> They are correct and better solutions than ignoring changes.\n> \n> Ignoring changes to tracked files is much more rare than having broad\n> ignore file, and tracking some files that match ignore patterns (but\n> note that you must use \"git add --force\" to add/track ignored file).\n> \n>> im just trying to understand why git ignore mechanism cant just read the\n>> .gitignore file and obey to those ignore rules without asking you to do\n>> fancy voodoo operations such removing those files from repo.\n> \n> Please read carefully: I mentioned 'ASSUME-UNCHANGED' mechanism in\n> both of my posts, haven't I?\n> \n\n\n-- \nFerry Huberts\n"},{"id":"172350","messageId":"295478CF936A4310941CE2001892A2DA@PhilipOakley","threadId":"27951","inReplyTo":"1311934832699-6632987.post@n2.nabble.com","subject":"Re: gitignore design","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2011-07-29T16:44:41Z","receivedAt":"2011-07-29T16:44:41Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"The answer is that you can use\n   git add --force <filename>\nto force git to take a copy of the current version of that file and place it \nin the staging area, despite it being in the ignore list.\n\n Being *in* the staging area means that that specific version will be copied \ninto each commit until you ask git to remove that copy (with git rm \n<filename> from the staging area, or update that copy, or whatever.\n\nThis depends on how (i.e. the options) you add files before a commit, or do \nthe commit itself, etc. For example the 'git add -A .' option will notice \nall the changes, including any updates to your <filename> (which may not be \nwhat you want).\n\nGit is flexible enough to do what you need. It can be hard to see the effect \nof all the options especially if someone has shown you a 'magic' command, \nbut hasn't fully explained the consequences. Many things are only obvious in \nretrospect.\n\nPhilip Oakley\nScotland\n----- Original Message ----- \nFrom: \"llucianf\" <llucianf@gmail.com>\nTo: <git@vger.kernel.org>\nSent: Friday, July 29, 2011 11:20 AM\nSubject: gitignore design\n\n\n> why gitignore doesnt simply work like in cvs where if you put something in\n> the ignore file, those stuff are simply ignored from that point without\n> having to remove them from repo?\n>\n>\n> --\n> View this message in context: \n> http://git.661346.n2.nabble.com/gitignore-design-tp6632987p6632987.html\n> Sent from the git mailing list archive at Nabble.com.\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n> ______________________________________________________________________\n> This email has been scanned by the MessageLabs Email Security System.\n> For more information please visit http://www.messagelabs.com/email\n> ______________________________________________________________________\n>\n>\n> -----\n> No virus found in this message.\n> Checked by AVG - www.avg.com\n> Version: 10.0.1390 / Virus Database: 1518/3793 - Release Date: 07/28/11\n> \n"},{"id":"172361","messageId":"201107292339.51753.jnareb@gmail.com","threadId":"27951","inReplyTo":"4E32B637.1030201@viscovery.net","subject":"Re: gitignore design","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-07-29T21:39:51Z","receivedAt":"2011-07-29T21:39:51Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, 29 Jul 2011, Johannes Sixt napisał:\n> Am 7/29/2011 15:19, schrieb Jakub Narebski:\n\n> > Are you sure?  It seems to work as I thought it would.\n> > [...]\n> > Notice that change to 'bar' didn't get comitted.\n> \n> Of course, it didn't get committed, you promised not to change it, so why\n> should git commit it?\n> \n> However, your example does not show the dangerous part. git-commit is not\n> dangerous. But you might run into trouble when git has to merge content\n> into the worktree or index; in this case, git may decide to just read the\n> file instead of to unpack an object - assuming that the content on disk is\n> identical to the unpacked object (it will do so because with\n> --assume-unchanged you promised not to change the file). If you broke your\n> promise, you get to what you deserve ;)\n\nTrue, it is *assume-unchanged*, not ignore-changes bit; though the latter\nwould be also possible to implement, I think... but having some file not\nchanging and marking it as such for better performance is saner use case\nthan tracking some file but not really tracking it.\n \n> No code reference, sorry, because I'm just parrotting what I've read\n> elsewhere on the list, for example,\n> http://thread.gmane.org/gmane.comp.version-control.git/146082/focus=146353\n\nWell, there is hint that there might be problems, but not really says\nthat they are, and where (if one is lying about assume unchanged by changing\nassume-unchanged file).\n\n-- \nJakub Narębski\nPoland\n"},{"id":"172367","messageId":"CACsJy8CurvKd_=hdRQyjjzWLvKF0jbWOQhbLSsmk1BqB_dK3og@mail.gmail.com","threadId":"27951","inReplyTo":"201107292339.51753.jnareb@gmail.com","subject":"Re: gitignore design","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-07-30T03:10:16Z","receivedAt":"2011-07-30T03:10:16Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"2011/7/30 Jakub Narebski <jnareb@gmail.com>\n> True, it is *assume-unchanged*, not ignore-changes bit; though the latter\n> would be also possible to implement, I think... but having some file not\n> changing and marking it as such for better performance is saner use case\n> than tracking some file but not really tracking it.\n\nIf you just want to ignore some files (or paths), then adding\n--exclude option to diff machinery may be a better option.\n--assume-unchanged is too low-level, and not really convenient to use.\n\n> > No code reference, sorry, because I'm just parrotting what I've read\n> > elsewhere on the list, for example,\n> > http://thread.gmane.org/gmane.comp.version-control.git/146082/focus=146353\n>\n> Well, there is hint that there might be problems, but not really says\n> that they are, and where (if one is lying about assume unchanged by changing\n> assume-unchanged file).\n\nThere were problems in the past. See aecda37 (do not overwrite files\nmarked \"assume unchanged\" - 2010-05-01)\n\nThe only place that relies on checking files uptodate (which can be\nfaked by assume-unchanged bit) before overwriting them is\nunpack-trees.c, verify_update_1(). With that fix in place, I think\nassume-unchanged bit is safe now. However, as long as we don't\nexplicitly state that we will not carelessly overwrite\nassume-unchanged files, there are still chances that some\noptimizations in future may make it dangerous again.\n--\nDuy\n"},{"id":"172369","messageId":"CAA01Cspv4yShnKBKFFrf8K1tbARahyYf7KZPqbiDFrvFsX9hwg@mail.gmail.com","threadId":"27951","inReplyTo":"CACsJy8CurvKd_=hdRQyjjzWLvKF0jbWOQhbLSsmk1BqB_dK3og@mail.gmail.com","subject":"Re: gitignore design","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2011-07-30T06:45:21Z","receivedAt":"2011-07-30T06:45:21Z","isPatch":false,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"On Sat, Jul 30, 2011 at 5:10 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:\n> 2011/7/30 Jakub Narebski <jnareb@gmail.com>\n>> True, it is *assume-unchanged*, not ignore-changes bit; though the latter\n>> would be also possible to implement, I think... but having some file not\n>> changing and marking it as such for better performance is saner use case\n>> than tracking some file but not really tracking it.\n>\n> If you just want to ignore some files (or paths), then adding\n> --exclude option to diff machinery may be a better option.\n> --assume-unchanged is too low-level, and not really convenient to use.\n\nI want to have \"exclude tracked\" feature too, for the same reason as\nllucianf wrote. I have project files which are\ntracked but when I use them locally they might get changed (if I\nmodify some options).\n\nThe template project files are some solution, but they need changes to\nthe build process, which might not always be possible. Also, with\ntemplates you won't have updates (like new project options) in your\nlocal copy automatically.\n\nThe project files are updated very rarely so handling updates should\nnot be a big problem.\n\nI think the \"exclude tracked\" option might work like this (all of this\nwith \"unless asked explicitly\" assumption):\n- diff, stat do not show differences\n- add, commit do not add changes\n- stash do not stash changes\n- merge tries to merge changes from upstream. If there's a conflict\nyou'll have to resolve it. OR\n- merge does not touch your locally unchanged files if they have\nchanges - if upstream have changes you'll have to make your local\nchanges disappear (copy file, checkout orig file, merge, analyze what\nchanged, copy your local changed file back)\n- checkout (different branch) - probably same as merge\n\n\n>> > No code reference, sorry, because I'm just parrotting what I've read\n>> > elsewhere on the list, for example,\n>> > http://thread.gmane.org/gmane.comp.version-control.git/146082/focus=146353\n>>\n>> Well, there is hint that there might be problems, but not really says\n>> that they are, and where (if one is lying about assume unchanged by changing\n>> assume-unchanged file).\n>\n> There were problems in the past. See aecda37 (do not overwrite files\n> marked \"assume unchanged\" - 2010-05-01)\n>\n> The only place that relies on checking files uptodate (which can be\n> faked by assume-unchanged bit) before overwriting them is\n> unpack-trees.c, verify_update_1(). With that fix in place, I think\n> assume-unchanged bit is safe now. However, as long as we don't\n> explicitly state that we will not carelessly overwrite\n> assume-unchanged files, there are still chances that some\n> optimizations in future may make it dangerous again.\n\nI was using assume-unchanged for some time but stopped after some\nweird problems during updates. I'm not sure if this was caused by this\nor by sparse-checkout (and I use git-svn too). Anyway, after stopping\nusing assume-unchanged and sparse-checkout mysterious problems\ndisappeared.\n\n\n-- \nPiotr Krukowiecki\n"},{"id":"172385","messageId":"CACsJy8DcFJUK91cJm3EmHn8BMyA78gzu_pMtqJ0z9oO1RF+suw@mail.gmail.com","threadId":"27951","inReplyTo":"CAA01Cspv4yShnKBKFFrf8K1tbARahyYf7KZPqbiDFrvFsX9hwg@mail.gmail.com","subject":"Re: gitignore design","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-07-30T13:22:14Z","receivedAt":"2011-07-30T13:22:14Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Jul 30, 2011 at 1:45 PM, Piotr Krukowiecki\n<piotr.krukowiecki@gmail.com> wrote:\n> I was using assume-unchanged for some time but stopped after some\n> weird problems during updates. I'm not sure if this was caused by this\n> or by sparse-checkout (and I use git-svn too). Anyway, after stopping\n> using assume-unchanged and sparse-checkout mysterious problems\n> disappeared.\n\nI'm interested in the problems you had (even better if you found a way\nto reproduce).\n-- \nDuy\n"},{"id":"172400","messageId":"CAA01Csq4L6ceGcjDJEsz5xyNeS+3q+Cb5txto0nPDzjqT1+zXw@mail.gmail.com","threadId":"27951","inReplyTo":"CACsJy8DcFJUK91cJm3EmHn8BMyA78gzu_pMtqJ0z9oO1RF+suw@mail.gmail.com","subject":"Re: gitignore design","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2011-07-30T15:52:00Z","receivedAt":"2011-07-30T15:52:00Z","isPatch":false,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"On Sat, Jul 30, 2011 at 3:22 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:\n> On Sat, Jul 30, 2011 at 1:45 PM, Piotr Krukowiecki\n> <piotr.krukowiecki@gmail.com> wrote:\n>> I was using assume-unchanged for some time but stopped after some\n>> weird problems during updates. I'm not sure if this was caused by this\n>> or by sparse-checkout (and I use git-svn too). Anyway, after stopping\n>> using assume-unchanged and sparse-checkout mysterious problems\n>> disappeared.\n>\n> I'm interested in the problems you had (even better if you found a way\n> to reproduce).\n\nSorry, but that was some time ago and I don't remember details.\nI could try using it again (which one are you interested in, sparse-checkout or\nassume-unchanged?) and report back if I find any problems.\n\n\n-- \nPiotr Krukowiecki\n"},{"id":"172401","messageId":"20110730160124.GA7545@toss.lan","threadId":"27951","inReplyTo":"CACsJy8DcFJUK91cJm3EmHn8BMyA78gzu_pMtqJ0z9oO1RF+suw@mail.gmail.com","subject":"Re: gitignore design","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2011-07-30T16:01:24Z","receivedAt":"2011-07-30T16:01:24Z","isPatch":false,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"On Sat, Jul 30, 2011 at 08:22:14PM +0700, Nguyen Thai Ngoc Duy wrote:\n> On Sat, Jul 30, 2011 at 1:45 PM, Piotr Krukowiecki\n> <piotr.krukowiecki@gmail.com> wrote:\n> > I was using assume-unchanged for some time but stopped after some\n> > weird problems during updates. I'm not sure if this was caused by this\n> > or by sparse-checkout (and I use git-svn too). Anyway, after stopping\n> > using assume-unchanged and sparse-checkout mysterious problems\n> > disappeared.\n> \n> I'm interested in the problems you had (even better if you found a way\n> to reproduce).\n\nHi, Same here.\n\nConcerning the OP's question, I've also written this FAQ entry,\nwhich explains two methods to deal with the problem:\n\n https://git.wiki.kernel.org/index.php/GitFaq#How_do_I_tell_git_to_ignore_tracked_files.3F\n\nIt also mentions assume-unchanged and sparse checkout as a third\noption, but it warns that these features were not designed for that\npurpose. Apart from the bug fixed in aecda37 I have never had a\nproblem with them myself. But it's not a particularly convenient\nsolution in any case.\n\nAs far as a possible 'exclude untracked' mechanism is concerned, I\nam not sure that is a good thing to have. It's like saying \"I want\nto track changes to those files, but I do not want to commit\nchanges by default (e.g. commit -a, add -u etc.).\" That may sound\nreasonable at first, but I think the desire to ignore changes to\ntracked files usually indicates a design problem. And it can almost\nalways be solved using either option (a) or (b) from the FAQ entry\nabove.\n\nOn the other hand, such a feature bears some risk.  The repository\nis not guaranteed to be in a certain state, even if git status is\nempty.  You could still have ignored changes somewhere. And it's\nall too easy to forget about those. I know I always forget about\nthe rules I have in my .git/info/exclude.\n\nMaybe I should not be trying to protect users from shooting\nthemselves in the foot. But I would be very curious to hear from\nthe OP why options (a) or (b) above are not a solution for his use\ncase, before adding yet another \"dangerous\" mechanism to git.\n\nClemens\n"}]}