<rsbecker@xxxxxxxxxxxxx> writes: > 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. [...] > 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
