3 ms·
that's not a valid argument. How do you identify "the lot"?
by Mazzen 6y ago
that's not a valid argument. How do you identify "the lot"?
- magicalhippo 6y agoBy the ticket/issue number?
- deleted 6y ago[deleted]
- gmfawcett 6y agoThere's an obvious upper bound. If you can't identify the last in-prod version that worked, and the first in-prod version that failed, then you have bigger problems than deciding whether to squash your commits.
- twic 6y agoBy story number, by author, by timestamp, by looking for merge commits, by reading the commit messages - by common sense, basically. If someone has just pushed broken code to master, they usually know exactly what they've just pushed. This doesn't seem like a real problem to me.
- falcolas 6y agolast_prod_tag < the_lot < current_prod_tag
- blandflakes 6y agoAnd if the merge of their commits interleaves with other commits from... teammates?
- falcolas 6y agoThanks to the complexity of how components integrate, even seemingly disjointed components, their commits are going to matter when it comes to troubleshooting an issue. This gets a bit more murkey with mono-repos, but even microservices can combine to create complex production issues.
- blandflakes 6y agoThis sort of sidesteps the issue, IMO, of how hard it is to isolate a problem. Yeah sometimes things collide, but pretty often in my experience there has been one change that needs reverting or patching, not six changes that interleaved. Or rather, interleaving them at best increases the difficulty of the blame game.