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
