3 ms·
> Being able to present missteps/demonstrate specific commits where something didn't work (without another developer having to write the scenario) has utility
by tux1968 3y ago
> Being able to present missteps/demonstrate specific commits where something didn't work (without another developer having to write the scenario) has utility that I have leveraged
Fortunately, you're able to include anything you think is relevant. If you think a change is worthy of inclusion, include it. But there are clearly things that are just silly mistakes that provide no such value, and cleaning those up as a courtesy for the person who has to review your code, just makes sense.
- Supermancho 3y ago> But there are clearly things that are just silly mistakes that provide no such value, and cleaning those up as a courtesy for the person who has to review your code, just makes sense. Maybe nobody cares about your missteps, true. What about less senior developers? Is there a learning opportunity both ways? Yes. The history pepper doesn't matter either way. There's a little value to think about that in the workflow I described, so we don't toss it (not that anyone can make you expose it).
- tux1968 3y ago> The history pepper doesn't matter either way. Having a clean history, where every commit is capable of being compiled, is quite nice. This will keep your CI happy and allow you to more easily use git bisect to determine when a bug was introduced to the codebase. > There's a little value to think about that in the workflow I described Sure. Git is flexible and doesn't require you to follow the workflow for which it was originally designed.