3 ms·
When commit is squashed and rebased upon main branch there is no pieces to bisect. Having private branches also does not always work. For example, there was a
by thesz 4y ago
When commit is squashed and rebased upon main branch there is no pieces to bisect.
Having private branches also does not always work. For example, there was a purge of unnecessary branches in our main repository. If I use a fork of main repository (and I do), my private branches are also not readily available to the team.
- int_19h 4y agoYou don't have to squash it all down to one commit. Many people do, but it's a choice they're making.
- thesz 4y agoThere are protocols to merge and squashing was required in two of four github-based teams I've worked with. The choice is done for you. It is not yours or theirs often enough.
- int_19h 4y agoI've seen that, and even successfully fought against it once. I've also been on teams that don't treat it as a religious issue in the first place, and people rebase or merge from their private forks as they see fit. Personally, I think that the only bar that is necessary is that commit history should remain readable - which is subjective, but that's why we have code reviews. In any case, this is not an issue with the tool, but rather with the religion that formed around it, which is often the case with software tooling. One thing that helps a lot with a pragmatic consensus is to ensure that all members of the team have personal experience debugging old code that they didn't write or previously review.