Hi,
Am Sonntag, den 10.05.2020, 09:43 +0100 schrieb Neil C Smith:
> On Sat, 9 May 2020 at 22:46, Matthias Bläsing <
> [email protected]> wrote:
> > I suggest to disable the squash-and-merge und rebase-and-merge
> > buttons:
>
> I'm -0 to -1 on this change. It has the potential to increase the
> headache for contributions, committers and release managers. Is it
> really necessary?
>From my POV yes - else I would have not written the mail. Yes it is
more work, so what? Testing, Evaluating is still more.
> What exactly are the problems and concerns here? I understand the
> immediate issue, and GitHub behaviour isn't ideal (it looks like
> they're actually working on improvements to it). But what exactly
> are
> the ramifications for us?
My problem is
1. the original behaviour _removes_ author information from the commit
- for me this alone is a huge problem
2. the new behaviour replaces authorship claims. To be frank this is
even more messed up. The committer is _not_ the author, even if he
squashed and merges.
> After the discussion on the test PR, I tried to find if this issue
> had
> been raised elsewhere around ASF. I didn't find anything specific,
> but did find quite a few infra issues from projects requesting that
> Squash and Merge be their *only* option. How are they handling it?
> Why do they feel it works for them when we don't feel it works for
> us?
Maybe they are not interested in authorship or are only let people
create PRs, that are committers themselfs. The problem does not exist
(or in a much smaller way) when Comitter == Author. But git explicitly
allows the distinction of the two and github messes that up.
> If tracing authorship of contributions is the only concern, there is
> also the fact that the commit is not the only (or canonical) record
> of
> this - there is the pull request and associated email trail that is
> archived by ASF for this reason. Does this provide all the
> additional
> information required?
Sorry but this stupid. Git can hold the correct metadata:
- who authored
- who committed
The problem is, that github destroys that information (and no squash-
and-merge with a mix of committers is a IMHO a bad idea).
> Does manual squashing and merging still fall foul of the problem with
> PRs not being marked as merged, so missing that part of the audit
> trail too?
Yes it has its own drawbacks, but the commits should still be tied to
the JIRA issue, so there is a line back, but the information in the
commit itself is correct.
I totally have no problem to require authors to squash their commits
and create a sane history, but that is indeed a different discussion.
This discussion is intended only to cover the broken squash-and-merge
behaviour of github.
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
