Idea: exclude generated files from `stg edit -d`
Whether we like it of not, generated files are often under version control. StGit itself has Cargo.lock in git.
I'm a heavy user of stg edit -d, it helps me produce good patched that only have the intended changes. Unfortunately, changes to generated files often dominate the diff file, so I have to navigate around them.
I suggest that we add an option that would exclude certain files from stg edit -d. Those files should remain unchanged once stg edit -d finishes. It's up to the user to regenerate them.
The simplest approach would be to use a set of shell patterns (e.g. "configure", "*.lock", "Cargo.nix"). The global configuration could have the default patterns. It should be possible to suppress the default.
A more sophisticated approach would be to have something like .gitignore hierarchy for "non-editable" files in the sources. It would be hard to introduce a new standard. But we could check if there is an existing proposal with some traction.
Some ideas how to do it with git: https://stackoverflow.com/questions/10415100/exclude-file-from-git-diff
Yeah GH does it great in PR Files view.
For clarification, @proski, when you use stg edit -d do you modify the diff? Or just use it as a reference?
I ask because excluding files from a diff being used purely as a reference seems easier than having to deal with an incomplete diff that is nonetheless intended to be applied after edit.
I do edit files occasionally. These are the ways I use stg edit -d:
- Writing or improving commit description while looking at the commit
- Removing chunks that don't belong to the commit, e.g. accidental edits
- Renaming newly added identifiers
- Renaming newly added files (amazing feature, BTW)
I don't ever add diffs for new files in stg edit -d, which could be a concern.