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

[<rsbecker@nexbridge.com>]

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.
> 
> There is no sensible behavior in this case, because sometimes the data is
> precious, such as certain configuration files, and sometimes it is
irrelevant
> data that the user would be happy to discard.
> 
> Since this is not a supported configuration and users are prone to misuse
the
> existing features for unintended purposes, causing general sadness and
> confusion, let's document the existing behavior and the pitfalls in the
> documentation for git update-index so that users know they should explore
> alternate solutions.
> 
> In additon, let's provide a recommended solution to dealing with the
> common case of configuration files, since there are well-known approaches
> used successfully in many environments.

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. From checkout's
perspective, the file would be considered unmodified so if a change is
incoming for that path, checkout replaces it instead of rejecting the
checkout, otherwise the file is untouched. Pull would act similarly. Branch
switching would be permitted without stashing the files - they would remain
unchanged unless the switch modified the files.

OTOH, this is a change that is most relevant to IDE users, so JGit would
have to implement it as well to really get any real benefit.

This does have some benefit in post-install situations as well as the IDE
use-case, but for that I might want to consider finer granularity, like some
way to identify regions of files being ignored. This being a pretty deep
rabbit hole we'd end up following.

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.

Just my few coins of thought.

Randall