Although this is such a small topic, this issue has taken away non-trivial amount of our time…
TL;DR I’ve seen quite a few pull requests that include unintended changes in .rviz files. How are people avoiding this to happen?
The file records a lot of states of the RViz window including the size of the main window, orientation of the view, open/close status of each menu etc, all of which are very nice IMO. It’s just the pull requester verifies the change using the same .rviz file, changing the size of windows, views etc. that may or may not be essential to the pull request s/he’s planning to open, and commit all the files changed including .rviz.
I can think of some easy workaround but these might be far from ideal…
Add *.rviz to .gitignore -> When you want to commit a change to .rviz, it won’t show up in commitable file list.
Change *.rviz to non-writable -> When you need to change it, you need admin, meaning you may run RViz as a root. I’m not sure about any side-effect…
I’d suggest you go with your first proposed solution. Files captured by gitignore rules can still be managed by git. For most people, the incidental changes they make will properly be ignored. If someone has a “real” change to the .rviz file that needs to be added, they can run git add -f <path to file>
to force git to add the file despite the gitignore rules.
This is nice as it’s a source control solution to a source control problem. More generally, this solves the problem of “I need to distribute this file, but everyone’s customizations to this file should not be carried back upstream.”
Regarding the second solution, ROS uses a healthy does of environment variables under the hood. Running ROS applications as root requires a bit of extra setup and usually causes more headaches than it’s worth.
As a third alternative, in some of my own projects, I include the .rviz files in our repositories as templates. Teammates are instructed to copy the file from the repository to the /home/USER/.rviz/ directory. Any changes they make get saved to that copy instead of the git-controlled file. This adds an extra step if you need to distribute changes to the .rviz file, but we haven’t had the need to do that very frequently.
Just a note, AFAIK this is not how it works. Ignored files don’t show up as “untracked”, but once you add them with git add -f, any subsequent changes are shown regardless of .gitignore like for any other file in the repo.
You’re totally right. I got a bit mixed up on how that worked.
One option is to run git update-index --skip-worktree <path to file>. The downside to this is that it only affects the local workspace. You’d have to ask everyone on the team to run this locally when they clone the repository. (documentation)
Looks like there may not actually be a simple way to express this intent on the remote.
This is not always a viable solution, but we avoid changes to rviz configuration files by always trying to start rviz via launch files. We have an rviz.launch file that points to a custom configuration file when starting the node. That custom configuration file is under version control. If we mess with the rviz layout after launching and then kill the launch command, and rviz with it, the rviz configuration file changes are not saved. This results in a clean repository.
For the rviz launch file we try to write it such that we can include it from other launch files or run it stand-alone after launching other parts of our system.