Re:git-appraise – Distributed Code Review for Git
by OkayPhysicist on Friday August 11, 2023 @12:44PM
(#37090759)
Or just don't squash. There's no need. In fact, if you're doing a review process like this, it would be active vandalism to to squash, since there is a big difference between "code said x, commented on by reviewer, changed to y" vs "code says y".
[ Parent
| on HN ]
Re:git-appraise – Distributed Code Review for Git
by globular-toast on Friday August 11, 2023 @01:42PM
(#37091527)
If you don't squash then you're essentially dedicating the history to code reviews because it won't be much use for anything else. If you leave broken commits on the main branch then it becomes really hard to bisect to find regressions. And that's the only reason for keeping history really.
Re:git-appraise – Distributed Code Review for Git
by OkayPhysicist on Friday August 11, 2023 @02:15PM
(#37091959)
git bisect --first-parent
Solves that issue entirely. Let branches hold their history, let the release/main branch hold the history of stable builds.
Re:git-appraise – Distributed Code Review for Git
by globular-toast on Friday August 11, 2023 @05:43PM
(#37094422)
If branches were rebased and then merged with `--no-ff` that could work.