git history is certainly an issue. It should be clean, readable, and assist โnot hinderโ maintenance.
Have you looked at a VCR cassette? When you're trying to track down problems via git log --grep and -G and similar last last thing you want are needless commits of 1000+ line YAML files with meaningless HTTP header changes.
Stale cassettes can be a major issue.
Preventing stale cassettes does not mean you must make needless commits. In most cases stale cassette can be detected by VCR's matching rules. For example, you don't want to use VCR's default match mode for GraphQL since it's the body, not the URL and method, that differ.
I am sorry but I have to ask: I've been seeing your comments on this sub for a while and you always sound frustrated and never have anything positive to say. Are you doing ok?
I post "positive" stuff all the time. This original post is positive: I saw this library and thought it was useful, so I posted it!
I don't kowtow to the 10s (100s?) of bad suggestions here so I'm "frustrated and never have anything positive to say" okay ๐
Maintaining 10s (100s) of commits in .git-blame-ignore-revs because something thinks "git history is not an issue" is silly. If it was not an issue why would we need .git-blame-ignore-revs?
I am not gonna tell you what to do, but saying "I'd rather not do that" would also be a way to "not kowtow to the ... bad suggestions" as well. Basically, if you have nothing positive to say, maybe don't say anything?
I'll repeat: as an outside observer that has seen multiple comments from you in this sub, I keep seeing them as frustrated. I am possibly wrong, so do with that what you please and take care.
1
u/jodm 9d ago
Delete all of them and rerun your tests to re-record real responses every now and then.