41–44 of 44 posts
Earlier quoted context omitted.
Git doesn't do that. People needlessly destroying history do that. Git will happily let you merge branches and preserve the history there. GP seems to like that history being in PRs only on github instead. I don't get why, that just seems worse to me.
Off-topic, but what does GP stand for? I know OP usually means Original Poster, but I'm not familiar with GP.
Earlier quoted context omitted.
> Because they’re broken and their only purpose is to fix up the original change, so it’s functionally the same change. Do you restrict yourself to 1 non-broken commit per PR? I don't, and nor does anyone I've worked with. If there were even 2 non-broken commits in the PR, then bisecting with the original history lands you on a diff half the size that bisecting with squashed history would, which is a significant win.…
> Do you restrict yourself to 1 non-broken commit per PR? No. To the extent that I can however I do restrict myself to only non-broken commits. > If there were even 2 non-broken commits in the PR, then bisecting with the original history lands you on a diff half the size that bisecting with squashed history would, which is a significant win It is not a significant win when the bisecting session keeps landing me in yo…
Skipping a commit that doesn't build is trivial (especially if you're automating your bisects).
> And splitting out fixups doesn’t save anything (let alone “half the size”), most commonly those fixups are just modifying content the previous commits were touching already, so you’re increasing the total diff size you have to evaluate.
If you feel the need to rebase to squash one-liner fixups into the commits they fix then that's a more subtle tradeoff and there are reasonable arguments. But squashing your whole PR for the sake of that is massive overkill, and the costs outweigh the benefits.
Earlier quoted context omitted.
> Do you restrict yourself to 1 non-broken commit per PR? No. To the extent that I can however I do restrict myself to only non-broken commits. > If there were even 2 non-broken commits in the PR, then bisecting with the original history lands you on a diff half the size that bisecting with squashed history would, which is a significant win It is not a significant win when the bisecting session keeps landing me in yo…
> It is not a significant win when the bisecting session keeps landing me in your broken commits that I have to waste time evaluating and skipping. Skipping a commit that doesn't build is trivial (especially if you're automating your bisects). > And splitting out fixups doesn’t save anything (let alone “half the size”), most commonly those fixups are just modifying content the previous commits were touching already,…
A broken commit usually compiles, if you don’t even compile before committing you should go back to school.
> If you feel the need to rebase to squash one-liner fixups into the commits they fix then that's a more subtle tradeoff and there are reasonable arguments. But squashing your whole PR for the sake of that
It would really have helped if you’d stated upfront that you can’t read.
Earlier quoted context omitted.
The why is that most people when given the merge option don’t clean up their history so you end up with tons of garbage fix up commits.
That is an issue of ignorance, not laziness. It’s not obvious at all to an average developer that only uses `add/commit/merge/fetch/push/pull/rebase/restore/reset` that they can manipulate their change history.