Hi Sean, Thanks for the feedback. I had not considered that the IDEs the teams are using might already have that functionality built in. I thought I had hit the nail on the head, but I agree there appears to be an alternative available. I will pursue those configurations with the team. I am curious if you think there is a class of files, under the paradigm I outlined; that need to be tracked initially but then ignored for regular workflows? Just curious at this point if this was discussed / considered previously. Thanks, Ward > > On Mar 22, 2023, at 5:10 AM, Sean Allred <allred.sean@xxxxxxxxx> wrote: > > > Ward Hopeman <ward.hopeman@xxxxxxxxxxxxxx> writes: >> Request: Create an Ignore section that allows for minimal IDE >> inclusion without impacting IDE settings for local users. >> >> Reason for the request: Most engineering teams share some IDE >> settings when working on code. More often than not, local IDE changes >> force engineers to resort to using "git update-index --skip-worktree >> <file>” to avoid the IDE settings files from showing up. It would be >> nice to be able to identify IDE files that you want in the repository >> but not necessarily track all changes as most of them are not desired >> when individuals make those changes for local setup. But teams like to >> track and have available generic shareable configurations like tabs to >> space and line length etc. By making it a user configurable section of >> ignore it allows for future IDEs to be listed without impacting the >> way it works for common IDEs today. > > It sounds like you are rather after 'public' vs 'private' IDE settings, > which would be a feature of the IDE -- not of Git -- and it seems a far > simpler model. Public settings are checked-in, private settings are not, > and private settings override public settings. > > This is used by Visual Studio (IIRC) and possible in other tools (Emacs > I know for sure, though I can't imagine VS Code doesn't have this > concept by now). It's even the model used by Git itself for some things > (.gitignore vs. .git/info/exclude vs. core.excludesfile). > > Are these alternative approaches not an option? > > -- > Sean Allred
