The delang is using merge instead of rebase/squash

Martin Nowak via Digitalmars-d digitalmars-d at puremagic.com
Mon Mar 20 11:22:34 PDT 2017


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.


More information about the Digitalmars-d mailing list