Allow merge commits in GH pull requests

[khwilliamson]

It is our policy from perlgit:

For larger sets of commits that only make sense together, or that would
benefit from a summary of the set's purpose, you should use a merge
commit.

Yet there is no way to conveniently do that. I have intended to do that myself, and there is that large green button staring me in the face which makes me forget all about my earlier plan. @bram-perl researched this and found this:

https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-merging-for-pull-requests

I haven't checked if this would meet our needs, but something needs to be done. An alternative would be to disable the current button if the p.r. had more than X number of commits. I think X was 3 or 6 when the topic was talked about some years ago.

[bram-perl]

To extend slightly (and to use the words in the GitHub docs): what might be a suitable configuration:

• Enforce "linear commit history", at the very least for blead (non linear commit history just leads to a mess. And it should be an exception so if it's really needed then it should not be easy to do in my opinion)
• Enable the "allow merge commits" option

[khwilliamson]

In the meantime, I added the Use merge commit label, which I will add to sequences of commits that I think would benefit from what I believe is called "semi-linear" history. These should be applied as described in perlgit.

[jkeenan]

In the meantime, I added the Use merge commit label, which I will add to sequences of commits that I think would benefit from what I believe is called "semi-linear" history. These should be applied as described in perlgit.

Could you add a few (n < 12) words of description to that label?

Also, do we need to modify documentation in places like pod/perlhack.pod, pod/perlgit.pod, etc.?

[khwilliamson]

The limit is 100 chars for label descriptions. Now added

We may want to modify documentation, but not until this issue garners some discussion from people who have the power to make the kinds of changes requested.

[jkeenan]

The limit is 100 chars for label descriptions. Now added

We may want to modify documentation, but not until this issue garners some discussion from people who have the power to make the kinds of changes requested.

Thanks.

[bulk88]

I prefer the absolute flat linear git history. Bisect Automated or manual, would Would be much harder the way other projects have dozens of branches merging into one. Then it becomes impossible to socially blame Or technically blame which commit or which branch made a mistake looking backwards From the future. What if both Intermediate commits were completely valid and correct at the time in isolatìon, at their sha1s, at That moment in their 2 separate commit history.

On the other hand, It's pretty easy to tell 10 commits in a row by one Author are probably one PR thread or 1 RT thread, After further research, but that takes another 10 minutes to do the archeology to know whether it's just one author who had a lot of free time that month, and made separate and unrelated features/improvement branches originaly, or were they truly one group/branch of improvements and were discussed by the community as one thing originally.

SVN Perforce era recorded automatically. What were branches/ticket nums/NNTP GUIDs in the commit message bodies.

RT era, I and some other authors would have to first reserve a ticket number, then put it in a bunch of commit message bodies for "the branch" for organizational reasons.

Github era, branch info/concept being stored in the git log is basically gone. You can only learn that information by reversing engineering from the GH ticket system.

In very rare cases in GH era reverse engineering from the ticket system won't help you. That doesn't help if someone with a commit bit pushed very small trivial non controversial commits that not even troll Perl developers would protest, and they had no peer review or a ticket number.

Or the 2nd commit bit holder, with a different name from author, merged and flattened a "corrected" branch, with a head SHA1 that was either author 1's alternate named corrected branch, that wasnt the SHA1 in the GH ticket, because Author 1 made a second Corrected branch on his private GH instead of doing a force push to the original GH PR tracked branch.

I would like to see some sort of automatic message body rewriting tool that inserts the original GH PR numbers into every commit in a "logical" branch, Sort of like the "signed off by" feature that nobody ever uses in GIT.

I would really really would not like to ever see circles, ovals, and figure 8s, and spider webs , and matrixs in my git log GUI app (tortoisegit) regarding Perl P5P CORE repo.

I believe it would also make my GIT blame GUI to start asking me if I want to go down the left or right side of a diverge over and over.

Bitrot happens through commits, not cellular biological means, or natural mechanical engineering material properties degradation.

Figuring out why the P5P C code is the way it is with Git blame is an important tool that not enough people do, before starting to write new C code.