I swear, I didn't come up with that myself, I read that somewhere else, but of course I don't have a source anymore 🙈 Maybe some git developer is a huge fan of wordplays?
- Posts
- 10
- Comments
- 12
- Joined
- 3 yr. ago
- Posts
- 10
- Comments
- 12
- Joined
- 3 yr. ago
Programming @kbin.social git bisect and the importance of a clean history
Programming @kbin.social Avoid mocking repositories by using in-memory implementations
Programming @kbin.social Upgrading GitHub.com to MySQL 8.0
Linux @kbin.social Making the shell history more useful by using shell variables
Programming @kbin.social Code comments are (mostly) a violation of DRY
Linux @kbin.social Automatic command execution on file changes with entr
Linux @kbin.social Execute commands for multiple files using fish
Programming @kbin.social Keep All Commits Green
Programming @kbin.social Demystifying Containers - Part I: Kernel Space
Linux @kbin.social Finding used values of XML attributes using the command line
I agree that some stuff is easier when not squashing commits, but for the teams I've been working with I've felt that the pros of squashing outweigh the cons, but of course YMMV.
But I didn't know about
git bisect skip, thanks for the tip! But sincere question: What happens if there are e.g. three adjacent broken commits? If I have skip all three of those and the error was introduced in one of them, then git cannot tell me which commit introduced the error, right?