{"thread":{"id":"44407","subject":"Git issue","startedAt":"2016-11-01T10:29:06Z","lastAt":"2016-11-07T22:34:43Z","messageCount":9,"participants":["Halde, Faiz","Jeff King","Junio C Hamano","Philip Oakley","Jacob Keller","Jakub Narębski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"305225","messageId":"BY2PR0601MB16400EAC3E9683841907F4B2A2A10@BY2PR0601MB1640.namprd06.prod.outlook.com","threadId":"44407","inReplyTo":null,"subject":"Git issue","fromName":"Halde, Faiz","fromEmail":"fhalde@paypal.com","sentAt":"2016-11-01T10:28:57Z","receivedAt":"2016-11-01T10:29:06Z","isPatch":false,"sender":{"key":"fhalde@paypal.com","avatar":null},"body":"Hello Git\n\nNot sure if this is a feature or a bug, but here it is.\n\nI frequently use the following command to ignore changes done in a file\n\ngit update-index --assume-unchanged somefile\n\nNow when I do a pull from my remote branch and say the file 'somefile' was changed locally and in remote, git will abort the merge saying I need to commit my changes of 'somefile'.\n\nBut isn't the whole point of the above command to ignore the changes within the file?\n\nThanks\nFaiz Halde \n"},{"id":"305237","messageId":"20161101174526.e2tilsriz2fqaru3@sigill.intra.peff.net","threadId":"44407","inReplyTo":"BY2PR0601MB16400EAC3E9683841907F4B2A2A10@BY2PR0601MB1640.namprd06.prod.outlook.com","subject":"Re: Git issue","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-11-01T17:45:26Z","receivedAt":"2016-11-01T17:45:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 01, 2016 at 10:28:57AM +0000, Halde, Faiz wrote:\n\n> I frequently use the following command to ignore changes done in a file\n> \n> git update-index --assume-unchanged somefile\n> \n> Now when I do a pull from my remote branch and say the file 'somefile'\n> was changed locally and in remote, git will abort the merge saying I\n> need to commit my changes of 'somefile'.\n> \n> But isn't the whole point of the above command to ignore the changes\n> within the file?\n\nNo. The purpose of --assume-unchanged is to promise git that you will\nnot change the file, so that it may skip checking the file contents in\nsome cases as an optimization.\n\nFrom \"git help update-index\":\n\n      --[no-]assume-unchanged\n\t   When this flag is specified, the object names recorded for\n\t   the paths are not updated. Instead, this option sets/unsets\n\t   the \"assume unchanged\" bit for the paths. When the \"assume\n\t   unchanged\" bit is on, the user promises not to change the\n\t   file and allows Git to assume that the working tree file\n\t   matches what is recorded in the index. If you want to change\n\t   the working tree file, you need to unset the bit to tell Git.\n\t   This is sometimes helpful when working with a big project on\n\t   a filesystem that has very slow lstat(2) system call (e.g.\n\t   cifs).\n\n\t   Git will fail (gracefully) in case it needs to modify this\n\t   file in the index e.g. when merging in a commit; thus, in\n\t   case the assumed-untracked file is changed upstream, you will\n\t   need to handle the situation manually.\n\n-Peff\n"},{"id":"305238","messageId":"xmqqy413oysp.fsf@gitster.mtv.corp.google.com","threadId":"44407","inReplyTo":"20161101174526.e2tilsriz2fqaru3@sigill.intra.peff.net","subject":"Re: Git issue","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-11-01T18:11:34Z","receivedAt":"2016-11-01T18:11:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Tue, Nov 01, 2016 at 10:28:57AM +0000, Halde, Faiz wrote:\n>\n>> I frequently use the following command to ignore changes done in a file\n>> \n>> git update-index --assume-unchanged somefile\n>> \n>> Now when I do a pull from my remote branch and say the file 'somefile'\n>> was changed locally and in remote, git will abort the merge saying I\n>> need to commit my changes of 'somefile'.\n>> \n>> But isn't the whole point of the above command to ignore the changes\n>> within the file?\n>\n> No. The purpose of --assume-unchanged is to promise git that you will\n> not change the file, so that it may skip checking the file contents in\n> some cases as an optimization.\n\nThat's correct.  \n\nThe next anticipated question is \"then how would I tell Git to\nignore changes done to a file locally by me?\", whose short answer is\n\"You don't\", of course.\n\nPeople may however wonder, if Git can make things more automatic if\nthe user is willing to tell her intention of what should happen to\n\"somefile\" in the example above when an operation requested cannot\nproceed while ignoring the local changes.  For example, \"ignore my\nchange and overwrite as needed\" could be such an instruction (and it\nis obvious what should happen in that case when \"git pull\" was\ndone--just clobber it with the version from the other side).\n\nAs I do not think of other sensible alternative behaviour, and I do\nnot think Git should make it easy to lose local changes when the\nuser is doing things like \"pull\" [*1*], it leads to the longer\nanswer to the question, which is again \"You don't\" ;-).\n\n\n[Footnote]\n\n*1* Things like \"git checkout [<tree>] [--] <path>\", \"git rm -f\" and\n    \"git reset --hard\" are ways to explicit request nuking the local\n    changes, and presence of these commands do not contradict with\n    \"do not make it easy to lose local changes\", of course.\n\n"},{"id":"305259","messageId":"7CE3166CFD244DAABF554451E8B0800F@PhilipOakley","threadId":"44407","inReplyTo":"20161101174526.e2tilsriz2fqaru3@sigill.intra.peff.net","subject":"Re: Git issue","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2016-11-01T20:50:30Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jeff King\" <peff@peff.net>\n> On Tue, Nov 01, 2016 at 10:28:57AM +0000, Halde, Faiz wrote:\n>\n>> I frequently use the following command to ignore changes done in a file\n>>\n>> git update-index --assume-unchanged somefile\n>>\n>> Now when I do a pull from my remote branch and say the file 'somefile'\n>> was changed locally and in remote, git will abort the merge saying I\n>> need to commit my changes of 'somefile'.\n>>\n>> But isn't the whole point of the above command to ignore the changes\n>> within the file?\n>\n> No. The purpose of --assume-unchanged is to promise git that you will\n> not change the file, so that it may skip checking the file contents in\n> some cases as an optimization.\n\nTrue. However...\n\n>\n> From \"git help update-index\":\n>\n>      --[no-]assume-unchanged\n>    When this flag is specified, the object names recorded for\n>    the paths are not updated. Instead, this option sets/unsets\n>    the \"assume unchanged\" bit for the paths. When the \"assume\n>    unchanged\" bit is on, the user promises not to change the\n>    file and allows Git to assume that the working tree file\n>    matches what is recorded in the index. If you want to change\n>    the working tree file, you need to unset the bit to tell Git.\n>    This is sometimes helpful when working with a big project on\n>    a filesystem that has very slow lstat(2) system call (e.g.\n>    cifs).\n>\n>    Git will fail (gracefully) in case it needs to modify this\n>    file in the index e.g. when merging in a commit; thus, in\n>    case the assumed-untracked file is changed upstream, you will\n>    need to handle the situation manually.\n>\n\nThe whole section (including the ones above this quote) are often confused \nbetween the promises of the user, and the alleged promises of Git. Even in \nthe quote above the \"Instead\" probably shouldn't be there.\n\nGiven the number of misrepresentations (on the web) of what the bit does, \nand the ongoing misunderstandings of users it does feel like the man page \narticle could be refreshed to be more assertive about the users promise, and \nGit's cautions.\n\nMy quick rough working on a more assertive update..\n-- >8 --\n----------------------  \nDocumentation/git-update-index.txt ----------------------\nindex 7386c93..4ec1711 100644\n@@ -84,12 +84,12 @@ OPTIONS\n         Set the execute permissions on the updated files.\n\n --[no-]assume-unchanged::\n  When this flag is specified, the object names recorded\n- for the paths are not updated.  Instead, this option\n+ for the paths are not updated.  This option\n  sets/unsets the \"assume unchanged\" bit for the\n  paths.  When the \"assume unchanged\" bit is on, the user\n- promises not to change the file and allows Git to assume\n+ *promises* not to change the file and allows Git to assume\n  that the working tree file matches what is recorded in\n  the index.  If you want to change the working tree file,\n  you need to unset the bit to tell Git.  This is\n  sometimes helpful when working with a big project on a\n@@ -300,19 +300,25 @@ $ git ls-files -s\n\n Using ``assume unchanged'' bit\n ------------------------------\n\n-Many operations in Git depend on your filesystem to have an\n+Many operations in Git depend on your filesystem having a fast and\n efficient `lstat(2)` implementation, so that `st_mtime`\n information for working tree files can be cheaply checked to see\n if the file contents have changed from the version recorded in\n the index file.  Unfortunately, some filesystems have\n inefficient `lstat(2)`.  If your filesystem is one of them, you\n-can set \"assume unchanged\" bit to paths you have not changed to\n-cause Git not to do this check.  Note that setting this bit on a\n-path does not mean Git will check the contents of the file to\n-see if it has changed -- it makes Git to omit any checking and\n-assume it has *not* changed.  When you make changes to working\n+can set \"assume unchanged\" bit to *paths you have not changed* to\n+cause Git not to do this check.\n+\n+Note that setting this bit on a\n+path does not mean Git will never check the contents of the file to\n+see if it has changed. Though normally it makes Git to omit any checking to\n+assume it has not changed.\n+Commands which may overwrite local changes (pull/merge etc) are\n+likely to check if the contents have changed\n+\n+If you make desired changes to working\n tree files, you have to explicitly tell Git about it by dropping\n \"assume unchanged\" bit, either before or after you modify them.\n\n In order to set \"assume unchanged\" bit, use `--assume-unchanged`\n---\nPhilip \n\n"},{"id":"305263","messageId":"20161101210310.sqrhvviry7iyyjrm@sigill.intra.peff.net","threadId":"44407","inReplyTo":"7CE3166CFD244DAABF554451E8B0800F@PhilipOakley","subject":"Re: Git issue","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-11-01T21:03:10Z","receivedAt":"2016-11-01T21:03:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 01, 2016 at 08:50:23PM -0000, Philip Oakley wrote:\n\n> > From \"git help update-index\":\n> > \n> >      --[no-]assume-unchanged\n> >    When this flag is specified, the object names recorded for\n> >    the paths are not updated. Instead, this option sets/unsets\n> >    the \"assume unchanged\" bit for the paths. When the \"assume\n> >    unchanged\" bit is on, the user promises not to change the\n> >    file and allows Git to assume that the working tree file\n> >    matches what is recorded in the index. If you want to change\n> >    the working tree file, you need to unset the bit to tell Git.\n> >    This is sometimes helpful when working with a big project on\n> >    a filesystem that has very slow lstat(2) system call (e.g.\n> >    cifs).\n> > \n> >    Git will fail (gracefully) in case it needs to modify this\n> >    file in the index e.g. when merging in a commit; thus, in\n> >    case the assumed-untracked file is changed upstream, you will\n> >    need to handle the situation manually.\n> > \n> \n> The whole section (including the ones above this quote) are often confused\n> between the promises of the user, and the alleged promises of Git. Even in\n> the quote above the \"Instead\" probably shouldn't be there.\n\nI think the \"Instead\" is \"we are not doing the usual update-index thing\nof reading the new data from disk; instead, we are _just_ setting the\nbit\". Perhaps that can be spelled out more clearly, but I think just\ndropping \"Instead\" is a step backwards.\n\n> Given the number of misrepresentations (on the web) of what the bit does,\n> and the ongoing misunderstandings of users it does feel like the man page\n> article could be refreshed to be more assertive about the users promise, and\n> Git's cautions.\n\nI dunno. I know this has long been a source of confusion, but I\nspecifically dug in the docs to see what we had, and I thought what I\nquoted above was pretty clear. That has \"only\" been around for about 2\nyears, and is fighting against other mis-advice on the Internet, though.\nSo I'm not sure if it is badly worded, or if people simply do not see\nit.\n\n-Peff\n"},{"id":"305264","messageId":"20161101210448.4692-1-philipoakley@iee.org","threadId":"44407","inReplyTo":"7CE3166CFD244DAABF554451E8B0800F@PhilipOakley","subject":"[PATCH] doc: update-index --assume-unchanged","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-11-01T21:04:48Z","receivedAt":"2016-11-01T21:05:00Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Be more assertive about the User promise, and Git's defensiveness\nof file changes.\n\nSigned-off-by: Philip Oakley <philipoakley@iee.org>\n---\nHere is a full patch for \nhttps://public-inbox.org/git/7CE3166CFD244DAABF554451E8B0800F@PhilipOakley/\n\n---\n Documentation/git-update-index.txt | 22 ++++++++++++++--------\n 1 file changed, 14 insertions(+), 8 deletions(-)\n\ndiff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt\nindex 7386c93..4ec1711 100644\n--- a/Documentation/git-update-index.txt\n+++ b/Documentation/git-update-index.txt\n@@ -85,10 +85,10 @@ OPTIONS\n \n --[no-]assume-unchanged::\n \tWhen this flag is specified, the object names recorded\n-\tfor the paths are not updated.  Instead, this option\n+\tfor the paths are not updated.  This option\n \tsets/unsets the \"assume unchanged\" bit for the\n \tpaths.  When the \"assume unchanged\" bit is on, the user\n-\tpromises not to change the file and allows Git to assume\n+\t*promises* not to change the file and allows Git to assume\n \tthat the working tree file matches what is recorded in\n \tthe index.  If you want to change the working tree file,\n \tyou need to unset the bit to tell Git.  This is\n@@ -301,17 +301,23 @@ $ git ls-files -s\n Using ``assume unchanged'' bit\n ------------------------------\n \n-Many operations in Git depend on your filesystem to have an\n+Many operations in Git depend on your filesystem having a fast and\n efficient `lstat(2)` implementation, so that `st_mtime`\n information for working tree files can be cheaply checked to see\n if the file contents have changed from the version recorded in\n the index file.  Unfortunately, some filesystems have\n inefficient `lstat(2)`.  If your filesystem is one of them, you\n-can set \"assume unchanged\" bit to paths you have not changed to\n-cause Git not to do this check.  Note that setting this bit on a\n-path does not mean Git will check the contents of the file to\n-see if it has changed -- it makes Git to omit any checking and\n-assume it has *not* changed.  When you make changes to working\n+can set \"assume unchanged\" bit to *paths you have not changed* to\n+cause Git not to do this check.\n+\n+Note that setting this bit on a\n+path does not mean Git will never check the contents of the file to\n+see if it has changed. Though normally it makes Git to omit any checking to\n+assume it has not changed.\n+Commands which may overwrite local changes (pull/merge etc) are\n+likely to check if the contents have changed\n+\n+If you make desired changes to working\n tree files, you have to explicitly tell Git about it by dropping\n \"assume unchanged\" bit, either before or after you modify them.\n \n-- \n2.9.0.windows.1.323.g0305acf\n\n"},{"id":"305267","messageId":"xmqq8tt2opw0.fsf@gitster.mtv.corp.google.com","threadId":"44407","inReplyTo":"20161101210310.sqrhvviry7iyyjrm@sigill.intra.peff.net","subject":"Re: Git issue","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-11-01T21:23:59Z","receivedAt":"2016-11-01T21:24:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Tue, Nov 01, 2016 at 08:50:23PM -0000, Philip Oakley wrote:\n>\n>> > From \"git help update-index\":\n>> > \n>> >      --[no-]assume-unchanged\n>> >    When this flag is specified, the object names recorded for\n>> >    the paths are not updated. Instead, this option sets/unsets\n>> >    the \"assume unchanged\" bit for the paths. ...\n>\n> I think the \"Instead\" is \"we are not doing the usual update-index thing\n> of reading the new data from disk; instead, we are _just_ setting the\n> bit\". Perhaps that can be spelled out more clearly, but I think just\n> dropping \"Instead\" is a step backwards.\n\nI tend to agree; the biggest problem with this part of the\ndescription I think is that it starts by saying what it does not do,\nwhich may help people who expect the command to do its usual thing\nbut otherwise is a secondary information.  How about ripping it out\nand moving it after the primary description, i.e.\n\n\tSet or unset the \"assume unchanged\" bit for the paths,\n\twithout changing the object names recorded for them, in the\n\tindex.\n\n>> Given the number of misrepresentations (on the web) of what the bit does,\n>> and the ongoing misunderstandings of users it does feel like the man page\n>> article could be refreshed to be more assertive about the users promise, and\n>> Git's cautions.\n>\n> I dunno. I know this has long been a source of confusion, but I\n> specifically dug in the docs to see what we had, and I thought what I\n> quoted above was pretty clear. That has \"only\" been around for about 2\n> years, and is fighting against other mis-advice on the Internet, though.\n> So I'm not sure if it is badly worded, or if people simply do not see\n> it.\n\nI share the same reaction, and I find that the update in ccadb25f73\n(\"doc: make clear --assume-unchanged's user contract\", 2014-12-06)\nthat introduced the \"the user promises not to change and allows Git\nto assume\" is sufficiently clear.\n\n"},{"id":"305390","messageId":"CA+P7+xo9AAEcNGp5ugHuXivqdv+9rMuTkDdxQd0siGHyyvwU_Q@mail.gmail.com","threadId":"44407","inReplyTo":"xmqq8tt2opw0.fsf@gitster.mtv.corp.google.com","subject":"Re: Git issue","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-11-04T04:52:00Z","receivedAt":"2016-11-04T04:52:27Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Tue, Nov 1, 2016 at 2:23 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jeff King <peff@peff.net> writes:\n>\n>> On Tue, Nov 01, 2016 at 08:50:23PM -0000, Philip Oakley wrote:\n>>\n>>> > From \"git help update-index\":\n>>> >\n>>> >      --[no-]assume-unchanged\n>>> >    When this flag is specified, the object names recorded for\n>>> >    the paths are not updated. Instead, this option sets/unsets\n>>> >    the \"assume unchanged\" bit for the paths. ...\n>>\n>> I think the \"Instead\" is \"we are not doing the usual update-index thing\n>> of reading the new data from disk; instead, we are _just_ setting the\n>> bit\". Perhaps that can be spelled out more clearly, but I think just\n>> dropping \"Instead\" is a step backwards.\n>\n> I tend to agree; the biggest problem with this part of the\n> description I think is that it starts by saying what it does not do,\n> which may help people who expect the command to do its usual thing\n> but otherwise is a secondary information.  How about ripping it out\n> and moving it after the primary description, i.e.\n>\n>         Set or unset the \"assume unchanged\" bit for the paths,\n>         without changing the object names recorded for them, in the\n>         index.\n>\n>>> Given the number of misrepresentations (on the web) of what the bit does,\n>>> and the ongoing misunderstandings of users it does feel like the man page\n>>> article could be refreshed to be more assertive about the users promise, and\n>>> Git's cautions.\n>>\n>> I dunno. I know this has long been a source of confusion, but I\n>> specifically dug in the docs to see what we had, and I thought what I\n>> quoted above was pretty clear. That has \"only\" been around for about 2\n>> years, and is fighting against other mis-advice on the Internet, though.\n>> So I'm not sure if it is badly worded, or if people simply do not see\n>> it.\n>\n> I share the same reaction, and I find that the update in ccadb25f73\n> (\"doc: make clear --assume-unchanged's user contract\", 2014-12-06)\n> that introduced the \"the user promises not to change and allows Git\n> to assume\" is sufficiently clear.\n>\n\nThis is some what of a tangent, but....\n\nOne of the primary pieces of advice I've seen that encourages its use\nwas to set it for a submodule after a repository switched to using\nsubmodules. The reasoning being that users were often running \"git\ncommit -a\" and accidentally including changes to their submodule\nwithout realizing it because they were not used to keeping the\nsubmodule up to date.\n\nI saw advice for this and it mostly appeared to work, but I wonder if\nthere is a better solution. I failed to train people to simply stop\ncommitting everything with \"git add .\" or \"git commit -a\" as this was\nsomething they were too used to from using previous version control\nsystems.\n\nIs there an alternative that would prevent \"add everything\" from\nadding these files so that users wouldn't commit rewinds to\nsubmodules?\n\nThanks,\nJake\n"},{"id":"305519","messageId":"9784a23f-2f44-33c7-5055-c6d66e779471@gmail.com","threadId":"44407","inReplyTo":"xmqqy413oysp.fsf@gitster.mtv.corp.google.com","subject":"Re: Git issue - ignoring changes to tracked file with assume-unchanged","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-11-07T22:34:34Z","receivedAt":"2016-11-07T22:34:43Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 01.11.2016 o 19:11, Junio C Hamano pisze:\n> Jeff King <peff@peff.net> writes:\n>> On Tue, Nov 01, 2016 at 10:28:57AM +0000, Halde, Faiz wrote:\n>>\n>>> I frequently use the following command to ignore changes done in a file\n>>>\n>>> git update-index --assume-unchanged somefile\n>>>\n>>> Now when I do a pull from my remote branch and say the file 'somefile'\n>>> was changed locally and in remote, git will abort the merge saying I\n>>> need to commit my changes of 'somefile'.\n>>>\n>>> But isn't the whole point of the above command to ignore the changes\n>>> within the file?\n>>\n>> No. The purpose of --assume-unchanged is to promise git that you will\n>> not change the file, so that it may skip checking the file contents in\n>> some cases as an optimization.\n> \n> That's correct.  \n> \n> The next anticipated question is \"then how would I tell Git to\n> ignore changes done to a file locally by me?\", whose short answer is\n> \"You don't\", of course.\n\nWell, you can always use --skip-worktree.  It is a better fit than using\n--assume-unchanged, because at least you wouldn't loose your precious\nlocal changes (which happened to me).\n\nOTOH it doesn't solve your issue of --skip-worktree / --assume-unchanged\nblocking operation (pull in your case, stash is what I noticed problem\nwith when using --skip-worktree).\n\nBut --skip-worktree is still workaround...\n\n-- \nJakub Narębski\n\n"}]}