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