threads / discuss / 60058

.gitignore is not enough

Subject: .gitignore is not enough

## tl;dr

8 messages between Aug 3, 2023 and Aug 3, 2023.

replies: 7people: 5as markdown or json

Aleem Zaki· Aug 3, 2023, 03:23 UTC · lore

There are files which one would like to pull from a remote branch but not have git register said person's changes on said files

Let's have a file named: .gitpullfromremotebutdonotregistermylocalchanges

Of course, we can think of a better name

By register I mean detect, like when git status detects changes that are not staged for commit

Use case:
On GitHub, you clone a repo with a default config file (skeleton)
You custom the config file with personal tokens and values
If the config filename was in .gitpullfromremotebutdonotregistermylocalchanges
Then the following don't have to be worried about:
1. The developer (the remote branch maintainer) doesn't have to not
have a default config file (skeleton) because it was in .gitignore
2. Pushing your secrets
-- 
Anonymous
Hilco Wijbenga· Aug 3, 2023, 05:35 UTC · re: Aleem Zaki · lore

Re: .gitignore is not enough

I think you might be looking for "git update-index --assume-unchanged <file>"? See https://www.git-scm.com/docs/git-update-index for more details.

This allows you to tell Git to ignore the changes you made to that (tracked) file.

On Wed, Aug 2, 2023 at 10:16 PM Aleem Zaki <aleemzaki@gmail.com> wrote:
Show 23 quoted lines
>
> There are files which one would like to pull from a remote branch but
> not have git register said person's changes on said files
>
> Let's have a file named:
> .gitpullfromremotebutdonotregistermylocalchanges
>
> Of course, we can think of a better name
>
> By register I mean detect, like when git status detects changes that
> are not staged for commit
>
> Use case:
>
> On GitHub, you clone a repo with a default config file (skeleton)
> You custom the config file with personal tokens and values
> If the config filename was in .gitpullfromremotebutdonotregistermylocalchanges
> Then the following don't have to be worried about:
> 1. The developer (the remote branch maintainer) doesn't have to not
> have a default config file (skeleton) because it was in .gitignore
> 2. Pushing your secrets
> --
> Anonymous
Johannes Sixt· Aug 3, 2023, 17:17 UTC · re: Hilco Wijbenga · lore

Re: .gitignore is not enough

Am 03.08.23 um 07:35 schrieb Hilco Wijbenga:
> I think you might be looking for "git update-index --assume-unchanged
> <file>"? See https://www.git-scm.com/docs/git-update-index for more
> details.

Sorry to tell you that this is a myth that lives on because it is repeated over and over again.

> This allows you to tell Git to ignore the changes you made to that
> (tracked) file.

No. --assume-unchanged allows you to make the *promise* to Git that you will not change the file, and consequently Git does not have to check whether the file was changed. If you break the promise (because you change it), you will get what you deserve. For example, you may find that Git overwrites your changes, or commits them nevertheless.

Perhaps a better choice is --skip-worktree, but recent answers on Stackoverflow point out that even that is not a suitable solution for "please, Git, ignore these changes".

-- Hannes
Hilco Wijbenga· Aug 3, 2023, 17:49 UTC · re: Johannes Sixt · lore

Re: .gitignore is not enough

The promise part, I was aware of. In that sense, my wording was too strong. It's more like "just trust me".

So the "you will get what you deserve" makes sense. If the original/default/skeleton changes for some reason, your local changes will just get overwritten. Nothing surprising there.

But in what scenario would Git "commit them nevertheless"? That one is a surprise to me and is a bit worrisome.

On Thu, Aug 3, 2023 at 10:17 AM Johannes Sixt <j6t@kdbg.org> wrote:
Show 24 quoted lines
>
> Am 03.08.23 um 07:35 schrieb Hilco Wijbenga:
> > I think you might be looking for "git update-index --assume-unchanged
> > <file>"? See https://www.git-scm.com/docs/git-update-index for more
> > details.
>
> Sorry to tell you that this is a myth that lives on because it is
> repeated over and over again.
>
> > This allows you to tell Git to ignore the changes you made to that
> > (tracked) file.
>
> No. --assume-unchanged allows you to make the *promise* to Git that you
> will not change the file, and consequently Git does not have to check
> whether the file was changed. If you break the promise (because you
> change it), you will get what you deserve. For example, you may find
> that Git overwrites your changes, or commits them nevertheless.
>
> Perhaps a better choice is --skip-worktree, but recent answers on
> Stackoverflow point out that even that is not a suitable solution for
> "please, Git, ignore these changes".
>
> -- Hannes
>
Johannes Sixt· Aug 3, 2023, 20:27 UTC · re: Hilco Wijbenga · lore

Re: .gitignore is not enough

Am 03.08.23 um 19:49 schrieb Hilco Wijbenga:
Show 9 quoted lines
> The promise part, I was aware of. In that sense, my wording was too
> strong. It's more like "just trust me".
> 
> So the "you will get what you deserve" makes sense. If the
> original/default/skeleton changes for some reason, your local changes
> will just get overwritten. Nothing surprising there.
> 
> But in what scenario would Git "commit them nevertheless"? That one is
> a surprise to me and is a bit worrisome.

I don't know. In my book it is called "undefined behavior". Anything can happen, including things that I did not enumerate.

-- Hannes
Show 26 quoted lines
> 
> On Thu, Aug 3, 2023 at 10:17 AM Johannes Sixt <j6t@kdbg.org> wrote:
>>
>> Am 03.08.23 um 07:35 schrieb Hilco Wijbenga:
>>> I think you might be looking for "git update-index --assume-unchanged
>>> <file>"? See https://www.git-scm.com/docs/git-update-index for more
>>> details.
>>
>> Sorry to tell you that this is a myth that lives on because it is
>> repeated over and over again.
>>
>>> This allows you to tell Git to ignore the changes you made to that
>>> (tracked) file.
>>
>> No. --assume-unchanged allows you to make the *promise* to Git that you
>> will not change the file, and consequently Git does not have to check
>> whether the file was changed. If you break the promise (because you
>> change it), you will get what you deserve. For example, you may find
>> that Git overwrites your changes, or commits them nevertheless.
>>
>> Perhaps a better choice is --skip-worktree, but recent answers on
>> Stackoverflow point out that even that is not a suitable solution for
>> "please, Git, ignore these changes".
>>
>> -- Hannes
>>
Junio C Hamano· Aug 3, 2023, 21:53 UTC · re: Johannes Sixt · lore

Re: .gitignore is not enough

Johannes Sixt <j6t@kdbg.org> writes:
Show 13 quoted lines
> Am 03.08.23 um 19:49 schrieb Hilco Wijbenga:
>> The promise part, I was aware of. In that sense, my wording was too
>> strong. It's more like "just trust me".
>> 
>> So the "you will get what you deserve" makes sense. If the
>> original/default/skeleton changes for some reason, your local changes
>> will just get overwritten. Nothing surprising there.
>> 
>> But in what scenario would Git "commit them nevertheless"? That one is
>> a surprise to me and is a bit worrisome.
>
> I don't know. In my book it is called "undefined behavior". Anything can
> happen, including things that I did not enumerate.
Exactly.

"Is commit affected?" and "Can we guarantee that operation X is not affected?" are meaningless questions, as our implementation is not frozen and we reserve the right to take any valid optimization oppoertunities as long as correctness is not violated.

The assume unchanged bit allows Git to take advantage of the promise the user has made and choose whichever is more efficient and/or convenient to use between the file in the working tree and the blob object for a given path when that bit is set. When you expect an existing blob object to be used (e.g. the one registered in the index), in _any_ operation (which is defined now or will be invented in the future), Git is allowed to instead use the contents of the corresponding working tree file. Or vice versa.

Perhaps you may be creating an archive of some format out of the tree of HEAD, and may expect that local changes in the working tree would not have any effect in the result. But instead of having to reconstruct the contents of a blob object known to be at path "README" in the tree by uncompressing the base object and then repeatedly applying delta data read from different parts of a packfile, it may be easier/faster to open/read the file in the working tree. And if there is such a promise from the user that the contents of the file will be kept the same as what was in the index and the HEAD, Git is allowed to do so. If the contents of the file was different from the blob, the resulting archive will not be an archive of the tree of HEAD, but that is "what you deserve".

brian m. carlson· Aug 3, 2023, 21:38 UTC · re: Johannes Sixt · lore

Re: .gitignore is not enough

On 2023-08-03 at 17:17:15, Johannes Sixt wrote:
Show 7 quoted lines
> Am 03.08.23 um 07:35 schrieb Hilco Wijbenga:
> > I think you might be looking for "git update-index --assume-unchanged
> > <file>"? See https://www.git-scm.com/docs/git-update-index for more
> > details.
> 
> Sorry to tell you that this is a myth that lives on because it is
> repeated over and over again.
This is indeed false.
Show 12 quoted lines
> > This allows you to tell Git to ignore the changes you made to that
> > (tracked) file.
> 
> No. --assume-unchanged allows you to make the *promise* to Git that you
> will not change the file, and consequently Git does not have to check
> whether the file was changed. If you break the promise (because you
> change it), you will get what you deserve. For example, you may find
> that Git overwrites your changes, or commits them nevertheless.
> 
> Perhaps a better choice is --skip-worktree, but recent answers on
> Stackoverflow point out that even that is not a suitable solution for
> "please, Git, ignore these changes".

Neither of these is an acceptable option. Here's an entry from the FAQ, which I have referred to several times (on StackOverflow and elsewhere):

How do I ignore changes to a tracked file?
  Git doesn't provide a way to do this.  The reason is that if Git needs
  to overwrite this file, such as during a checkout, it doesn't know
  whether the changes to the file are precious and should be kept, or
  whether they are irrelevant and can safely be destroyed.  Therefore,
  it has to take the safe route and always preserve them.
  It's tempting to try to use certain features of `git update-index`,
  namely the assume-unchanged and skip-worktree bits, but these don't
  work properly for this purpose and shouldn't be used this way.
  If your goal is to modify a configuration file, it can often be
  helpful to have a file checked into the repository which is a template
  or set of defaults which can then be copied alongside and modified as
  appropriate.  This second, modified file is usually ignored to prevent
  accidentally committing it.

There's no option to do this and you should adopt a different approach. Probably 95% of the circumstances I see where people are trying to ignore tracked files can be done by moving the original file to another path and using a script to copy and modify the file to an ignored path.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
Aleem Zaki· Aug 3, 2023, 21:47 UTC · re: brian m. carlson · lore

Re: .gitignore is not enough

I understand, I shall copy the empty config and paste into a new ignored file where I then add my personal customizations. 
What 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?
Show 54 quoted lines
> On Aug 3, 2023, at 2:38 PM, brian m. carlson <sandals@crustytoothpaste.net> wrote:
> 
> On 2023-08-03 at 17:17:15, Johannes Sixt wrote:
>>> Am 03.08.23 um 07:35 schrieb Hilco Wijbenga:
>>> I think you might be looking for "git update-index --assume-unchanged
>>> <file>"? See https://www.git-scm.com/docs/git-update-index for more
>>> details.
>> 
>> Sorry to tell you that this is a myth that lives on because it is
>> repeated over and over again.
> 
> This is indeed false.
> 
>>> This allows you to tell Git to ignore the changes you made to that
>>> (tracked) file.
>> 
>> No. --assume-unchanged allows you to make the *promise* to Git that you
>> will not change the file, and consequently Git does not have to check
>> whether the file was changed. If you break the promise (because you
>> change it), you will get what you deserve. For example, you may find
>> that Git overwrites your changes, or commits them nevertheless.
>> 
>> Perhaps a better choice is --skip-worktree, but recent answers on
>> Stackoverflow point out that even that is not a suitable solution for
>> "please, Git, ignore these changes".
> 
> Neither of these is an acceptable option.  Here's an entry from the FAQ,
> which I have referred to several times (on StackOverflow and elsewhere):
> 
> How do I ignore changes to a tracked file?
> 
>  Git doesn't provide a way to do this.  The reason is that if Git needs
>  to overwrite this file, such as during a checkout, it doesn't know
>  whether the changes to the file are precious and should be kept, or
>  whether they are irrelevant and can safely be destroyed.  Therefore,
>  it has to take the safe route and always preserve them.
> 
>  It's tempting to try to use certain features of `git update-index`,
>  namely the assume-unchanged and skip-worktree bits, but these don't
>  work properly for this purpose and shouldn't be used this way.
> 
>  If your goal is to modify a configuration file, it can often be
>  helpful to have a file checked into the repository which is a template
>  or set of defaults which can then be copied alongside and modified as
>  appropriate.  This second, modified file is usually ignored to prevent
>  accidentally committing it.
> 
> There's no option to do this and you should adopt a different approach.
> Probably 95% of the circumstances I see where people are trying to
> ignore tracked files can be done by moving the original file to another
> path and using a script to copy and modify the file to an ignored path.
> -- 
> brian m. carlson (he/him or they/them)
> Toronto, Ontario, CA

← back to recent threads