On Monday, 20 March 2017 at 12:25:22 UTC, deadalnix wrote:
In addition there are a bunch of practical issues with this way of doing things. First there is no given that any intermediate state is sound, or even builds at all. That makes it very hard to bissect anything.
You bissect on master and there is one merge commit per PR, no intermediate states involved.
There are also a lot of errands and correction that are made during review that are not that interesting to keep in the project history. Knowing that someone did thing the A way and then changed it the B way after review is more noise than useful infos in the general case, and in the rare case when someone actually wants to know, the github PR is still out there (on that note, yes GH PR kind fo sucks, but that's another topic).
That's a conflict of interest. As said, GH's interface is targetted toward pushing review fixes as new commits, rather than ammending changes. And yes those commits mostly provide little information, but they're also on a separate branch.
Using auto-squash before merging https://github.com/dlang-bots/dlang-bot/issues/64#issuecomment-284155249 made sense but isn't offered by GH's API and thus requires quite some work.
Just squashing everything to a single commit and putting that on master (as done by GH's squash+rebase) doesn't preserve all information in git.
Also smells like it might cause automation troubles at some point.
