.gitignore is not enough

.gitignore is not enough

[Aleem Zaki]

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

Re: .gitignore is not enough

[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.

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:
>
> 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

Re: .gitignore is not enough

[Johannes Sixt]

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

Re: .gitignore is not enough

[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.

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
>

Re: .gitignore is not enough

[Johannes Sixt]

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.

-- Hannes

> 
> 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
>>

Re: .gitignore is not enough

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: .gitignore is not enough

[Aleem Zaki]

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?

> 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

Re: .gitignore is not enough

[Junio C Hamano]

Johannes Sixt <j6t@kdbg.org> writes:

> 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".