Re: [PATCH v3 3/4] doc: dissuade users from trying to ignore tracked files

From: Jakub Narebski <jnareb@gmail.com>
Date: Nov 3, 2019, 15:46 UTC
Message-ID: <86bltthsjj.fsf@gmail.com>
In-Reply-To: <001501d591ba$1d190060$574b0120$@nexbridge.com>

<rsbecker@nexbridge.com> writes:

Show 10 quoted lines

> On November 2, 2019 3:26 PM, brian m. carlson wrote:
>> It is quite common for users to want to ignore the changes to a file that Git
>> tracks.  Common scenarios for this case are IDE settings and configuration
>> files, which should generally not be tracked and possibly generated from
>> tracked files using a templating mechanism.
>> 
>> However, users learn about the assume-unchanged and skip-worktree bits
>> and try to use them to do this anyway.  This is problematic, because when
>> these bits are set, many operations behave as the user expects, but they
>> usually do not help when git checkout needs to replace a file.

[...]

Show 9 quoted lines

> Just noodling about a potential solution. If we assume the use case that
> files are modified by an IDE that have no real relevance, but should not
> interfere with other git operations including checkout...
>
> What if we introduce something like .gitignore.changes, with the same syntax
> as .gitignore. The difference is files listed in this file will not show in
> `git status` (or could show as "changes ignored" with an option to enable
> that. The only way to have the changes considered would be `git add -f`, so
> `git add .` and `git commit -a` would not pick up the changes.

[...]

I think it would be better and easier to add new attribute and use .gitattributes instead of a new .gitignore.changes (and its per-repository, per-user and system-wide version).

> If this idea seems reasonable, it might make a nice small project for
> someone, possibly me, if I could unentangle from my current hellish $DAYJOB
> project.

I wish you luck.

The fact that it was nod done yet may mean that there are some annoying corner-cases in the concept, or that it is not commonly useful... or maybe that is the problem that needs reframing.

Best,

-- 
Jakub Narębski