Editing root-owned files by opening an editor as root is generally considered to be an anti-pattern. There is sudoedit as an option, but that also works with VSCode (and has the same limitations roughly.) The better option is probably just not editing root-owned files directly except in an emergency; there's usually better approaches to deploying system-wide changes.

What would be the better approach to handle bunch of files in /etc/ without making the process reluctant?

I don't want to git push/pull on every minor edit that I might revert the next minute.

This also involves, directory listing that is only root accessible.

Generally, I think most people agree that directly editing live configuration files on systems is not the ideal way to manage systems. As for what to do instead, it strongly depends. On test or development systems, I suspect most people wouldn't bat an eye to just running Vim as root, but there are some other options:

- Use configuration management systems to provision configuration changes: Ansible, SaltStack, Chef, etc. (And yeah, when testing on development or test set ups/VMs, you might first try stuff with vim directly. But if you are pretty sure you know what you want, you can also just do it in the configuration management system, test it, and provision it.) -- This may seem overkill for local configuration but it's pretty handy.

- If possible, make use of features of your tools to require less root access. For example, in Nix there are various ways to move the Nix configuration for the system out of /etc/nixos and into a user directory, or some hybrid of the two. Maybe some services can be made rootless: either running as "user" services, or even under a rootless container.

- Make use of permissions or ACLs to give write access to a non-root user or group. Then you don't need to be root to edit or provision the files.