{"thread":{"id":"60058","subject":".gitignore is not enough","startedAt":"2023-08-03T03:23:18Z","lastAt":"2023-08-03T21:53:23Z","messageCount":8,"participants":["Aleem Zaki","Hilco Wijbenga","Johannes Sixt","brian m. carlson","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"480111","messageId":"CA+sf2-+499Nfu00ciJeLwjRmBE7Bb-WZcZuCXY2-JXs88Pwz-w@mail.gmail.com","threadId":"60058","inReplyTo":null,"subject":".gitignore is not enough","fromName":"Aleem Zaki","fromEmail":"aleemzaki@gmail.com","sentAt":"2023-08-03T03:23:03Z","receivedAt":"2023-08-03T03:23:18Z","isPatch":false,"sender":{"key":"aleemzaki@gmail.com","avatar":null},"body":"There are files which one would like to pull from a remote branch but\nnot have git register said person's changes on said files\n\nLet's have a file named:\n.gitpullfromremotebutdonotregistermylocalchanges\n\nOf course, we can think of a better name\n\nBy register I mean detect, like when git status detects changes that\nare not staged for commit\n\nUse case:\n\nOn GitHub, you clone a repo with a default config file (skeleton)\nYou custom the config file with personal tokens and values\nIf the config filename was in .gitpullfromremotebutdonotregistermylocalchanges\nThen the following don't have to be worried about:\n1. The developer (the remote branch maintainer) doesn't have to not\nhave a default config file (skeleton) because it was in .gitignore\n2. Pushing your secrets\n-- \nAnonymous\n"},{"id":"480113","messageId":"CAE1pOi1Zt8i_rVi6dCGVsshhPxa_kV7qQ7SMu6R4nsSiadq7xw@mail.gmail.com","threadId":"60058","inReplyTo":"CA+sf2-+499Nfu00ciJeLwjRmBE7Bb-WZcZuCXY2-JXs88Pwz-w@mail.gmail.com","subject":"Re: .gitignore is not enough","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2023-08-03T05:35:46Z","receivedAt":"2023-08-03T05:36:17Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"I think you might be looking for \"git update-index --assume-unchanged\n\"? See https://www.git-scm.com/docs/git-update-index for more\ndetails.\n\nThis allows you to tell Git to ignore the changes you made to that\n(tracked) file.\n\nOn Wed, Aug 2, 2023 at 10:16 PM Aleem Zaki wrote:\n>\n> There are files which one would like to pull from a remote branch but\n> not have git register said person's changes on said files\n>\n> Let's have a file named:\n> .gitpullfromremotebutdonotregistermylocalchanges\n>\n> Of course, we can think of a better name\n>\n> By register I mean detect, like when git status detects changes that\n> are not staged for commit\n>\n> Use case:\n>\n> On GitHub, you clone a repo with a default config file (skeleton)\n> You custom the config file with personal tokens and values\n> If the config filename was in .gitpullfromremotebutdonotregistermylocalchanges\n> Then the following don't have to be worried about:\n> 1. The developer (the remote branch maintainer) doesn't have to not\n> have a default config file (skeleton) because it was in .gitignore\n> 2. Pushing your secrets\n> --\n> Anonymous\n"},{"id":"480128","messageId":"c2fea20d-af37-8721-5bd8-14bbc3daf937@kdbg.org","threadId":"60058","inReplyTo":"CAE1pOi1Zt8i_rVi6dCGVsshhPxa_kV7qQ7SMu6R4nsSiadq7xw@mail.gmail.com","subject":"Re: .gitignore is not enough","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2023-08-03T17:17:15Z","receivedAt":"2023-08-03T17:17:24Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 03.08.23 um 07:35 schrieb Hilco Wijbenga:\n> I think you might be looking for \"git update-index --assume-unchanged\n> \"? See https://www.git-scm.com/docs/git-update-index for more\n> details.\n\nSorry to tell you that this is a myth that lives on because it is\nrepeated over and over again.\n\n> This allows you to tell Git to ignore the changes you made to that\n> (tracked) file.\n\nNo. --assume-unchanged allows you to make the *promise* to Git that you\nwill not change the file, and consequently Git does not have to check\nwhether the file was changed. If you break the promise (because you\nchange it), you will get what you deserve. For example, you may find\nthat Git overwrites your changes, or commits them nevertheless.\n\nPerhaps a better choice is --skip-worktree, but recent answers on\nStackoverflow point out that even that is not a suitable solution for\n\"please, Git, ignore these changes\".\n\n-- Hannes\n\n"},{"id":"480129","messageId":"CAE1pOi1xtaEo6LtF4VnXetmLYK5VbYU5uq7gGC=PpnVB3MWdag@mail.gmail.com","threadId":"60058","inReplyTo":"c2fea20d-af37-8721-5bd8-14bbc3daf937@kdbg.org","subject":"Re: .gitignore is not enough","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2023-08-03T17:49:38Z","receivedAt":"2023-08-03T17:50:05Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"The promise part, I was aware of. In that sense, my wording was too\nstrong. It's more like \"just trust me\".\n\nSo the \"you will get what you deserve\" makes sense. If the\noriginal/default/skeleton changes for some reason, your local changes\nwill just get overwritten. Nothing surprising there.\n\nBut in what scenario would Git \"commit them nevertheless\"? That one is\na surprise to me and is a bit worrisome.\n\nOn Thu, Aug 3, 2023 at 10:17 AM Johannes Sixt wrote:\n>\n> Am 03.08.23 um 07:35 schrieb Hilco Wijbenga:\n> > I think you might be looking for \"git update-index --assume-unchanged\n> > \"? See https://www.git-scm.com/docs/git-update-index for more\n> > details.\n>\n> Sorry to tell you that this is a myth that lives on because it is\n> repeated over and over again.\n>\n> > This allows you to tell Git to ignore the changes you made to that\n> > (tracked) file.\n>\n> No. --assume-unchanged allows you to make the *promise* to Git that you\n> will not change the file, and consequently Git does not have to check\n> whether the file was changed. If you break the promise (because you\n> change it), you will get what you deserve. For example, you may find\n> that Git overwrites your changes, or commits them nevertheless.\n>\n> Perhaps a better choice is --skip-worktree, but recent answers on\n> Stackoverflow point out that even that is not a suitable solution for\n> \"please, Git, ignore these changes\".\n>\n> -- Hannes\n>\n"},{"id":"480135","messageId":"e453bee1-942f-ea9a-9c50-3cf5d0f9e936@kdbg.org","threadId":"60058","inReplyTo":"CAE1pOi1xtaEo6LtF4VnXetmLYK5VbYU5uq7gGC=PpnVB3MWdag@mail.gmail.com","subject":"Re: .gitignore is not enough","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2023-08-03T20:27:39Z","receivedAt":"2023-08-03T20:27:47Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 03.08.23 um 19:49 schrieb Hilco Wijbenga:\n> The promise part, I was aware of. In that sense, my wording was too\n> strong. It's more like \"just trust me\".\n> \n> So the \"you will get what you deserve\" makes sense. If the\n> original/default/skeleton changes for some reason, your local changes\n> will just get overwritten. Nothing surprising there.\n> \n> But in what scenario would Git \"commit them nevertheless\"? That one is\n> a surprise to me and is a bit worrisome.\n\nI don't know. In my book it is called \"undefined behavior\". Anything can\nhappen, including things that I did not enumerate.\n\n-- Hannes\n\n> \n> On Thu, Aug 3, 2023 at 10:17 AM Johannes Sixt wrote:\n>>\n>> Am 03.08.23 um 07:35 schrieb Hilco Wijbenga:\n>>> I think you might be looking for \"git update-index --assume-unchanged\n>>> \"? See https://www.git-scm.com/docs/git-update-index for more\n>>> details.\n>>\n>> Sorry to tell you that this is a myth that lives on because it is\n>> repeated over and over again.\n>>\n>>> This allows you to tell Git to ignore the changes you made to that\n>>> (tracked) file.\n>>\n>> No. --assume-unchanged allows you to make the *promise* to Git that you\n>> will not change the file, and consequently Git does not have to check\n>> whether the file was changed. If you break the promise (because you\n>> change it), you will get what you deserve. For example, you may find\n>> that Git overwrites your changes, or commits them nevertheless.\n>>\n>> Perhaps a better choice is --skip-worktree, but recent answers on\n>> Stackoverflow point out that even that is not a suitable solution for\n>> \"please, Git, ignore these changes\".\n>>\n>> -- Hannes\n>>\n\n"},{"id":"480137","messageId":"ZMweZHQZL7nnla+2@tapette.crustytoothpaste.net","threadId":"60058","inReplyTo":"c2fea20d-af37-8721-5bd8-14bbc3daf937@kdbg.org","subject":"Re: .gitignore is not enough","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2023-08-03T21:38:44Z","receivedAt":"2023-08-03T21:38:50Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2023-08-03 at 17:17:15, Johannes Sixt wrote:\n> Am 03.08.23 um 07:35 schrieb Hilco Wijbenga:\n> > I think you might be looking for \"git update-index --assume-unchanged\n> > \"? See https://www.git-scm.com/docs/git-update-index for more\n> > details.\n> \n> Sorry to tell you that this is a myth that lives on because it is\n> repeated over and over again.\n\nThis is indeed false.\n\n> > This allows you to tell Git to ignore the changes you made to that\n> > (tracked) file.\n> \n> No. --assume-unchanged allows you to make the *promise* to Git that you\n> will not change the file, and consequently Git does not have to check\n> whether the file was changed. If you break the promise (because you\n> change it), you will get what you deserve. For example, you may find\n> that Git overwrites your changes, or commits them nevertheless.\n> \n> Perhaps a better choice is --skip-worktree, but recent answers on\n> Stackoverflow point out that even that is not a suitable solution for\n> \"please, Git, ignore these changes\".\n\nNeither of these is an acceptable option. Here's an entry from the FAQ,\nwhich I have referred to several times (on StackOverflow and elsewhere):\n\nHow do I ignore changes to a tracked file?\n\n Git doesn't provide a way to do this. The reason is that if Git needs\n to overwrite this file, such as during a checkout, it doesn't know\n whether the changes to the file are precious and should be kept, or\n whether they are irrelevant and can safely be destroyed. Therefore,\n it has to take the safe route and always preserve them.\n\n It's tempting to try to use certain features of `git update-index`,\n namely the assume-unchanged and skip-worktree bits, but these don't\n work properly for this purpose and shouldn't be used this way.\n\n If your goal is to modify a configuration file, it can often be\n helpful to have a file checked into the repository which is a template\n or set of defaults which can then be copied alongside and modified as\n appropriate. This second, modified file is usually ignored to prevent\n accidentally committing it.\n\nThere's no option to do this and you should adopt a different approach.\nProbably 95% of the circumstances I see where people are trying to\nignore tracked files can be done by moving the original file to another\npath and using a script to copy and modify the file to an ignored path.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"480138","messageId":"BAFA1866-33FE-461C-812A-5E4232D40EAA@gmail.com","threadId":"60058","inReplyTo":"ZMweZHQZL7nnla+2@tapette.crustytoothpaste.net","subject":"Re: .gitignore is not enough","fromName":"Aleem Zaki","fromEmail":"aleemzaki@gmail.com","sentAt":"2023-08-03T21:47:53Z","receivedAt":"2023-08-03T21:48:10Z","isPatch":false,"sender":{"key":"aleemzaki@gmail.com","avatar":null},"body":"I understand, I shall copy the empty config and paste into a new ignored file where I then add my personal customizations. \n\nWhat if, however, all git commands besides ‘git pull’ and ‘git fetch’, are able to modify the files in question. Would we then have a potential new git feature?\n\n> On Aug 3, 2023, at 2:38 PM, brian m. carlson wrote:\n> \n> On 2023-08-03 at 17:17:15, Johannes Sixt wrote:\n>>> Am 03.08.23 um 07:35 schrieb Hilco Wijbenga:\n>>> I think you might be looking for \"git update-index --assume-unchanged\n>>> \"? See https://www.git-scm.com/docs/git-update-index for more\n>>> details.\n>> \n>> Sorry to tell you that this is a myth that lives on because it is\n>> repeated over and over again.\n> \n> This is indeed false.\n> \n>>> This allows you to tell Git to ignore the changes you made to that\n>>> (tracked) file.\n>> \n>> No. --assume-unchanged allows you to make the *promise* to Git that you\n>> will not change the file, and consequently Git does not have to check\n>> whether the file was changed. If you break the promise (because you\n>> change it), you will get what you deserve. For example, you may find\n>> that Git overwrites your changes, or commits them nevertheless.\n>> \n>> Perhaps a better choice is --skip-worktree, but recent answers on\n>> Stackoverflow point out that even that is not a suitable solution for\n>> \"please, Git, ignore these changes\".\n> \n> Neither of these is an acceptable option. Here's an entry from the FAQ,\n> which I have referred to several times (on StackOverflow and elsewhere):\n> \n> How do I ignore changes to a tracked file?\n> \n> Git doesn't provide a way to do this. The reason is that if Git needs\n> to overwrite this file, such as during a checkout, it doesn't know\n> whether the changes to the file are precious and should be kept, or\n> whether they are irrelevant and can safely be destroyed. Therefore,\n> it has to take the safe route and always preserve them.\n> \n> It's tempting to try to use certain features of `git update-index`,\n> namely the assume-unchanged and skip-worktree bits, but these don't\n> work properly for this purpose and shouldn't be used this way.\n> \n> If your goal is to modify a configuration file, it can often be\n> helpful to have a file checked into the repository which is a template\n> or set of defaults which can then be copied alongside and modified as\n> appropriate. This second, modified file is usually ignored to prevent\n> accidentally committing it.\n> \n> There's no option to do this and you should adopt a different approach.\n> Probably 95% of the circumstances I see where people are trying to\n> ignore tracked files can be done by moving the original file to another\n> path and using a script to copy and modify the file to an ignored path.\n> -- \n> brian m. carlson (he/him or they/them)\n> Toronto, Ontario, CA\n"},{"id":"480139","messageId":"xmqqsf8z3i9d.fsf@gitster.g","threadId":"60058","inReplyTo":"e453bee1-942f-ea9a-9c50-3cf5d0f9e936@kdbg.org","subject":"Re: .gitignore is not enough","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-08-03T21:53:18Z","receivedAt":"2023-08-03T21:53:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Am 03.08.23 um 19:49 schrieb Hilco Wijbenga:\n>> The promise part, I was aware of. In that sense, my wording was too\n>> strong. It's more like \"just trust me\".\n>> \n>> So the \"you will get what you deserve\" makes sense. If the\n>> original/default/skeleton changes for some reason, your local changes\n>> will just get overwritten. Nothing surprising there.\n>> \n>> But in what scenario would Git \"commit them nevertheless\"? That one is\n>> a surprise to me and is a bit worrisome.\n>\n> I don't know. In my book it is called \"undefined behavior\". Anything can\n> happen, including things that I did not enumerate.\n\nExactly.\n\n\"Is commit affected?\" and \"Can we guarantee that operation X is not\naffected?\" are meaningless questions, as our implementation is not\nfrozen and we reserve the right to take any valid optimization\noppoertunities as long as correctness is not violated.\n\nThe assume unchanged bit allows Git to take advantage of the promise\nthe user has made and choose whichever is more efficient and/or\nconvenient to use between the file in the working tree and the blob\nobject for a given path when that bit is set. When you expect an\nexisting blob object to be used (e.g. the one registered in the\nindex), in _any_ operation (which is defined now or will be invented\nin the future), Git is allowed to instead use the contents of the\ncorresponding working tree file. Or vice versa.\n\nPerhaps you may be creating an archive of some format out of the\ntree of HEAD, and may expect that local changes in the working tree\nwould not have any effect in the result. But instead of having to\nreconstruct the contents of a blob object known to be at path\n\"README\" in the tree by uncompressing the base object and then\nrepeatedly applying delta data read from different parts of a\npackfile, it may be easier/faster to open/read the file in the\nworking tree. And if there is such a promise from the user that the\ncontents of the file will be kept the same as what was in the index\nand the HEAD, Git is allowed to do so. If the contents of the file\nwas different from the blob, the resulting archive will not be an\narchive of the tree of HEAD, but that is \"what you deserve\".\n\n"}]}