{"thread":{"id":"8593","subject":"Any way to ignore a change to a tracked file when committing/merging?","startedAt":"2007-06-13T15:47:33Z","lastAt":"2007-06-13T19:57:58Z","messageCount":10,"participants":["David Watson","Pierre Habouzit","Nicolas Pitre","Robin Rosenberg","Andy Parkins","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"44956","messageId":"A30E217A-084E-4019-949F-5918EAA6368E@mimvista.com","threadId":"8593","inReplyTo":null,"subject":"Any way to ignore a change to a tracked file when committing/merging?","fromName":"David Watson","fromEmail":"dwatson@mimvista.com","sentAt":"2007-06-13T15:47:33Z","receivedAt":"2007-06-13T15:47:33Z","isPatch":false,"sender":{"key":"dwatson@mimvista.com","avatar":null},"body":"I've got a problem, or maybe annoyance is more the proper term, that  \nI haven't seen solved by any SCM system (at least not to my  \nknowledge). Basically, I may make some changes, e.g. to a Makefile or  \nsomesuch, that I want to ignore when looking at what's changed from  \nthe repository. The only problem is, the file I've modified is  \nalready under version control, so .gitignore doesn't do anything.\n\nNow, I can commit it, so it will stop bugging me, but then when I  \npush out it will include that change, unless I back it out. This is a  \nchange that I don't want propagated anywhere else, because it's  \nspecific to my machine or development sandbox.\n\nIs there any way to do this? I'd really love to use git-commit -a in  \nthis situation, and I could hack up a script to undo my change, run  \ngit-commit -a, and reapply the change, but makes me a bit squirmy. If  \nI could put something in a .git config file to say \"commit 237ab  \nshould not be propagated under any circumstances\", that would be  \nfantastic.\n\n-Dave Watson\n"},{"id":"44965","messageId":"20070613163312.GJ5311@artemis.intersec.eu","threadId":"8593","inReplyTo":"A30E217A-084E-4019-949F-5918EAA6368E@mimvista.com","subject":"Re: Any way to ignore a change to a tracked file when committing/merging?","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-13T16:33:12Z","receivedAt":"2007-06-13T16:33:12Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Wed, Jun 13, 2007 at 11:47:33AM -0400, David Watson wrote:\n> I've got a problem, or maybe annoyance is more the proper term, that I \n> haven't seen solved by any SCM system (at least not to my knowledge). \n> Basically, I may make some changes, e.g. to a Makefile or somesuch, that \n> I want to ignore when looking at what's changed from the repository. The \n> only problem is, the file I've modified is already under version control, \n> so .gitignore doesn't do anything.\n> \n> Now, I can commit it, so it will stop bugging me, but then when I push \n> out it will include that change, unless I back it out. This is a change \n> that I don't want propagated anywhere else, because it's specific to my \n> machine or development sandbox.\n> \n> Is there any way to do this? I'd really love to use git-commit -a in this \n> situation, and I could hack up a script to undo my change, run git-commit \n> -a, and reapply the change, but makes me a bit squirmy. If I could put \n> something in a .git config file to say \"commit 237ab should not be \n> propagated under any circumstances\", that would be fantastic.\n\n  please read the thread [ pull into dirty working tree ] that is just\nabout this, and like errr 2 threads before yours.\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"44973","messageId":"alpine.LFD.0.99.0706131318390.21061@xanadu.home","threadId":"8593","inReplyTo":"A30E217A-084E-4019-949F-5918EAA6368E@mimvista.com","subject":"Re: Any way to ignore a change to a tracked file when committing/merging?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-06-13T17:21:10Z","receivedAt":"2007-06-13T17:21:10Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 13 Jun 2007, David Watson wrote:\n\n> I've got a problem, or maybe annoyance is more the proper term, that I haven't\n> seen solved by any SCM system (at least not to my knowledge). Basically, I may\n> make some changes, e.g. to a Makefile or somesuch, that I want to ignore when\n> looking at what's changed from the repository. The only problem is, the file\n> I've modified is already under version control, so .gitignore doesn't do\n> anything.\n> \n> Now, I can commit it, so it will stop bugging me, but then when I push out it\n> will include that change, unless I back it out. This is a change that I don't\n> want propagated anywhere else, because it's specific to my machine or\n> development sandbox.\n> \n> Is there any way to do this? I'd really love to use git-commit -a in this\n> situation, and I could hack up a script to undo my change, run git-commit -a,\n> and reapply the change, but makes me a bit squirmy. If I could put something\n> in a .git config file to say \"commit 237ab should not be propagated under any\n> circumstances\", that would be fantastic.\n\nWhy don't you just use git-commit _without_ -a ?\n\nThe whole purpose behind not specifying -a with git-commit is exactly \nfor your usage example.\n\n\nNicolas\n"},{"id":"44978","messageId":"477C424C-009F-46BF-85D4-A0D777FE3CEC@mimvista.com","threadId":"8593","inReplyTo":"alpine.LFD.0.99.0706131318390.21061@xanadu.home","subject":"Re: Any way to ignore a change to a tracked file when committing/merging?","fromName":"David Watson","fromEmail":"dwatson@mimvista.com","sentAt":"2007-06-13T17:41:42Z","receivedAt":"2007-06-13T17:41:42Z","isPatch":false,"sender":{"key":"dwatson@mimvista.com","avatar":null},"body":"Because git-commit -a is nice to use, especially if I really want to  \ncheck in all the files, *except a particular set that is always the  \nsame*. Having to specify the files every time gets old pretty quick.\n\nIf I could do this:\n\n$ git-commit -a --exclude=somefile\n\nthat would be very useful. Or even, if I could set a file in my .git  \nfolder that would be an exclude list, then I could run something like\n\n$ git-commit -a --use-excludes\n\nI suppose the answer is to create the patch myself. Seems like this  \nwould also be a useful feature for git-status, git-ls-files (when  \nused with --modified), and probably some others that I haven't  \nthought of yet.\n\n-Dave Watson\n\nOn Jun 13, 2007, at 1:21 PM, Nicolas Pitre wrote:\n\n> On Wed, 13 Jun 2007, David Watson wrote:\n>\n>> I've got a problem, or maybe annoyance is more the proper term,  \n>> that I haven't\n>> seen solved by any SCM system (at least not to my knowledge).  \n>> Basically, I may\n>> make some changes, e.g. to a Makefile or somesuch, that I want to  \n>> ignore when\n>> looking at what's changed from the repository. The only problem  \n>> is, the file\n>> I've modified is already under version control, so .gitignore  \n>> doesn't do\n>> anything.\n>>\n>> Now, I can commit it, so it will stop bugging me, but then when I  \n>> push out it\n>> will include that change, unless I back it out. This is a change  \n>> that I don't\n>> want propagated anywhere else, because it's specific to my machine or\n>> development sandbox.\n>>\n>> Is there any way to do this? I'd really love to use git-commit -a  \n>> in this\n>> situation, and I could hack up a script to undo my change, run git- \n>> commit -a,\n>> and reapply the change, but makes me a bit squirmy. If I could put  \n>> something\n>> in a .git config file to say \"commit 237ab should not be  \n>> propagated under any\n>> circumstances\", that would be fantastic.\n>\n> Why don't you just use git-commit _without_ -a ?\n>\n> The whole purpose behind not specifying -a with git-commit is exactly\n> for your usage example.\n>\n>\n> Nicolas\n"},{"id":"44977","messageId":"alpine.LFD.0.99.0706131349430.1697@xanadu.home","threadId":"8593","inReplyTo":"477C424C-009F-46BF-85D4-A0D777FE3CEC@mimvista.com","subject":"Re: Any way to ignore a change to a tracked file when committing/merging?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-06-13T17:54:50Z","receivedAt":"2007-06-13T17:54:50Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 13 Jun 2007, David Watson wrote:\n\n> Because git-commit -a is nice to use, especially if I really want to check in\n> all the files, *except a particular set that is always the same*. Having to\n> specify the files every time gets old pretty quick.\n> \n> If I could do this:\n> \n> $ git-commit -a --exclude=somefile\n> \n> that would be very useful. Or even, if I could set a file in my .git folder\n> that would be an exclude list, then I could run something like\n> \n> $ git-commit -a --use-excludes\n> \n> I suppose the answer is to create the patch myself.\n\nWell, before that I'd suggest you have a look at the git-add man page, \nespecially the -u flag and the core.excludesfile config option.\n\n\nNicolas\n"},{"id":"44979","messageId":"6D50717E-7FB2-48EE-9B56-42B658ACAD10@mimvista.com","threadId":"8593","inReplyTo":"alpine.LFD.0.99.0706131349430.1697@xanadu.home","subject":"Re: Any way to ignore a change to a tracked file when committing/merging?","fromName":"David Watson","fromEmail":"dwatson@mimvista.com","sentAt":"2007-06-13T18:09:24Z","receivedAt":"2007-06-13T18:09:24Z","isPatch":false,"sender":{"key":"dwatson@mimvista.com","avatar":null},"body":"It appears that only applies to untracked files. I am specifically  \ninterested in ignoring changes to files that are already tracked,  \nunless I'm misunderstanding what you're suggesting. I just built the  \nmost recent git from repo.or.cz/git, and did the following:\n\n* edit the file I want to \"ignore\"\ngit-status shows this file as modified\n\n* edit .git/config, set core.excludesfile to myexcludes, containing  \nthe name of the file I want\n* git add -u\n* git-status\nshows the file I edited as ready to be committed.\n\nDave Watson\n\nOn Jun 13, 2007, at 1:54 PM, Nicolas Pitre wrote:\n\n> On Wed, 13 Jun 2007, David Watson wrote:\n>\n>> Because git-commit -a is nice to use, especially if I really want  \n>> to check in\n>> all the files, *except a particular set that is always the same*.  \n>> Having to\n>> specify the files every time gets old pretty quick.\n>>\n>> If I could do this:\n>>\n>> $ git-commit -a --exclude=somefile\n>>\n>> that would be very useful. Or even, if I could set a file in  \n>> my .git folder\n>> that would be an exclude list, then I could run something like\n>>\n>> $ git-commit -a --use-excludes\n>>\n>> I suppose the answer is to create the patch myself.\n>\n> Well, before that I'd suggest you have a look at the git-add man page,\n> especially the -u flag and the core.excludesfile config option.\n>\n>\n> Nicolas\n"},{"id":"44991","messageId":"alpine.LFD.0.99.0706131417320.1697@xanadu.home","threadId":"8593","inReplyTo":"6D50717E-7FB2-48EE-9B56-42B658ACAD10@mimvista.com","subject":"Re: Any way to ignore a change to a tracked file when committing/merging?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-06-13T18:19:24Z","receivedAt":"2007-06-13T18:19:24Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 13 Jun 2007, David Watson wrote:\n\n> It appears that only applies to untracked files. I am specifically interested\n> in ignoring changes to files that are already tracked, unless I'm\n> misunderstanding what you're suggesting. I just built the most recent git from\n> repo.or.cz/git, and did the following:\n> \n> * edit the file I want to \"ignore\"\n> git-status shows this file as modified\n> \n> * edit .git/config, set core.excludesfile to myexcludes, containing the name\n> of the file I want\n> * git add -u\n> * git-status\n> shows the file I edited as ready to be committed.\n\nI suppose that the behavior of git-add could be modified to honnor the \nexclude pattern even for already tracked files.  Such change would make \nsense to me.\n\n\nNicolas\n"},{"id":"44982","messageId":"200706132030.55972.robin.rosenberg.lists@dewire.com","threadId":"8593","inReplyTo":"A30E217A-084E-4019-949F-5918EAA6368E@mimvista.com","subject":"Re: Any way to ignore a change to a tracked file when committing/merging?","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-06-13T18:30:55Z","receivedAt":"2007-06-13T18:30:55Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"onsdag 13 juni 2007 skrev David Watson:\n> I've got a problem, or maybe annoyance is more the proper term, that  \n> I haven't seen solved by any SCM system (at least not to my  \n> knowledge). Basically, I may make some changes, e.g. to a Makefile or  \n> somesuch, that I want to ignore when looking at what's changed from  \n> the repository. The only problem is, the file I've modified is  \n> already under version control, so .gitignore doesn't do anything.\n> \n> Now, I can commit it, so it will stop bugging me, but then when I  \n> push out it will include that change, unless I back it out. This is a  \n> change that I don't want propagated anywhere else, because it's  \n> specific to my machine or development sandbox.\n> \n> Is there any way to do this? I'd really love to use git-commit -a in  \n> this situation, and I could hack up a script to undo my change, run  \n> git-commit -a, and reapply the change, but makes me a bit squirmy. If  \n> I could put something in a .git config file to say \"commit 237ab  \n> should not be propagated under any circumstances\", that would be  \n> fantastic.\n\ngit update-index --assume-unchanged <path>\n\nThen commit -a like you are used to.\n\n-- robin\n"},{"id":"44992","messageId":"200706132034.29934.andyparkins@gmail.com","threadId":"8593","inReplyTo":"A30E217A-084E-4019-949F-5918EAA6368E@mimvista.com","subject":"Re: Any way to ignore a change to a tracked file when committing/merging?","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-06-13T19:34:28Z","receivedAt":"2007-06-13T19:34:28Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007, June 13, David Watson wrote:\n> I've got a problem, or maybe annoyance is more the proper term, that\n> I haven't seen solved by any SCM system (at least not to my\n> knowledge). Basically, I may make some changes, e.g. to a Makefile or\n> somesuch, that I want to ignore when looking at what's changed from\n\nSo you want to tell git to track a file and then have it not track \nchanges to that file?  Sounds crazy to me.  Don't put files in the \nrepository that you don't want tracking.\n\nWhat you want is an out-of-tree file for that sort of thing.  Why can't \nyou just do\n\n#!/usr/bin/make\n-include Makefile.local\n\nRather than messing around with not tracking tracked files?\n\ngit does exactly that in it's own build process with a config.mak file, \nwhich lets you specify, say, an install directory that is obviously \nonly valid for you.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"44994","messageId":"7vwsy7d3uh.fsf@assigned-by-dhcp.pobox.com","threadId":"8593","inReplyTo":"200706132034.29934.andyparkins@gmail.com","subject":"Re: Any way to ignore a change to a tracked file when committing/merging?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-13T19:57:58Z","receivedAt":"2007-06-13T19:57:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins <andyparkins@gmail.com> writes:\n\n> On Wednesday 2007, June 13, David Watson wrote:\n>> I've got a problem, or maybe annoyance is more the proper term, that\n>> I haven't seen solved by any SCM system (at least not to my\n>> knowledge). Basically, I may make some changes, e.g. to a Makefile or\n>> somesuch, that I want to ignore when looking at what's changed from\n>\n> So you want to tell git to track a file and then have it not track \n> changes to that file?  Sounds crazy to me.  Don't put files in the \n> repository that you don't want tracking.\n\nActually, that is a sign that either the upstream project is\nbroken, and/or the user's workflow is broken.\n\nTaking an example closer to home, if we tell tell users \"in\nconfig.mk file you can suit your local needs\" and at the same\ntime add config.mk to the official repository, that would be\ncrazy.  The changes to that file is _supposed_ to be local and\nthe other side will never be interested in getting updates to\nthat file.  So if David is dealing with such a situation, then\nthe problem is in the project organization.\n\nOn the other hand, it is usual to see a comment in the Makefile\nthat says \"# No user tweakable part below this line\", with\nexpectations that users will muck with make variable definitions\nin the earlier parts of the Makefile to suit the local\nfilesystem layout and such.\n\nThe changes users will make to such a file fall into one of two\ncategories:\n\n (1) Local configuration changes to adjust to the user's\n     particular installation.\n\n (2) Fixes, improvements and enhancements to the generic part\n     (\"below that line\").\n\nOther people, especially the \"upstream\" people, are never\ninterested in ever seeing patches of the former kind, while the\nlatter are of general use and you would want to feed themback.\n\nYou would need to separete out these two kinds at SOME stage\nwhen you need to make changes of both kinds.  You can do that at\npatch submission time, cleaning up the series, if you are\nfeeding the changes via patches.\n\nIf you are communicating with the other side via pull/push, then\nyou would need to have two histories that cleanly separates the\ntwo.  Probably a good workflow is:\n\n - The tracking branch remotes/origin/master; this holds what is\n   'pristine';\n   \n - Keep 'master' branch for only the changes for general\n   consumption.\n\n - Have a separate 'local' branch, that is forked from 'master'\n   branch of yours.  Local configuration changes will go to this\n   branch, never to 'master'.\n\nYou would never publish 'local' as it contains the local\nconfiguration changes that are of no interest to others, but the\nchanges you may want to give back to outside will be readily\navailable in 'master'.\n\nIf I _were_ doing this, I would further use a topic branch that\nforked from pristine to hold only the local changes, and use\n'local' only as an integration branch between that local\nconfiguration topic and 'master' (i.e. no commits will be made\nto 'local' directly -- everything will come from either separate\ntopics or 'master').\n"}]}