3 ms·

I don't follow. Either you can break your big commit down into pieces that can be applied one by one - then do that using history rewriting (and testing each p

by mafuy 4y ago

I don't follow. Either you can break your big commit down into pieces that can be applied one by one - then do that using history rewriting (and testing each part!). Or that's not possible, e.g. because it's a global architecture change or something that is already atomar. Then there is nothing to bisect anyway - there is nothing that can be done, no matter which tool you use and no matter if you squash or not.

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 ago
  You don't have to squash it all down to one commit. Many people do, but it's a choice they're making.
  - thesz 4y ago
    There 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 ago
      I'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.

3 ms·

I don't follow. Either you can break your big commit down into pieces that can be applied one by one - then do that using history rewriting (and testing each p

by mafuy 4y ago

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 ago
  You don't have to squash it all down to one commit. Many people do, but it's a choice they're making.
  - thesz 4y ago
    There 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 ago
      I'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.