1. Yep.
2. I would phrase this as "merge is the default, but we may (should?)
sqaush/rewrite obvious fixup commits."
3. If separable commits belong to the same PR, let's keep them in the same
PR.
Sounds like we made a mistake for this PR, and should err more on the side
of not squashing.
On Tue, A
I would like to push back on 2 & 3 and replace it with this:
(not 2, not 3) Don't squash/rebase someone's pull request unless it is
obvious that they are OK with it
If someone has used git in the standard way, and you squash their commits,
you may have broken them and it is (minor) data loss
Thanks for the feedback. Sounds like there are a few takeaways from the
discussion:
1. Not everyone is a git power user, squash and merge is commonly used and
can't be disabled.
2. As a non-committer I should expect my commits to be squashed, rewritten,
or otherwise changed at the discretion of th
One thing that is available is the "allow maintainers to edit" which can
let any committer push to the PR and do all of this. It is either on by
default, or I have simply checked it in the past, since I have recently had
a maintainer push to my PR on accident :-)
On Tue, Apr 17, 2018 at 5:57 PM Ah
I agree with Robert. In this case one size does not fit all. There are
times, another round trip with a contributor would be frustrating to the
author. Especially for new contributors. Having the option to squash and
merge is useful in those cases. (For reference in the past we even helped
new cont
I think the two options are useful, because we have different kinds of
contributors. Sophisticated users curate their own history, create
logically useful commits, build atop it, etc. and merge is by far the
better option. Others have a single commit followed by any number of
"lint," "fixup," and "
Not strongly against `*Create a merge commit*`, but I use `squash and
merge` by default. I understand the potential impact mentioned by Andrew,
it's still a better option IMO:
1. if a PR contains several parts, it can be documented in commit message
instead of several commits; --If it's a big task,
+1 Having made a few web commits and been frustrated by the options,
anything to standardize on a single option seems good to me.
On Tue, 17 Apr 2018 at 01:49 Etienne Chauchot wrote:
> +1 to enforce the behavior recommended in the committer guide. I usually
> ask the author to manually squash be
+1 to enforce the behavior recommended in the committer guide. I usually ask
the author to manually squash before
committing.
Etienne
Le lundi 16 avril 2018 à 22:19 +, Robert Bradshaw a écrit :
> +1, though I'll admit I've been an occasional user of the "squash and merge"
> button when a smal
+1, though I'll admit I've been an occasional user of the "squash and
merge" button when a small PR has a huge number of small, fixup changes
piled on it.
On Mon, Apr 16, 2018 at 3:07 PM Kenneth Knowles wrote:
> It is no secret that I agree with this. When you don't rewrite history,
> distribute
It is no secret that I agree with this. When you don't rewrite history,
distributed git "just works". I didn't realize we could mechanically
enforce it.
Kenn
On Mon, Apr 16, 2018 at 2:55 PM Andrew Pilloud wrote:
>
>
>
> *The Github UI provides several options for merging a PR hidden behind the
*The Github UI provides several options for merging a PR hidden behind the
“Merge pull request” button. Only the “Create a merge commit” option does
what most users expect, which is to merge by creating a new merge commit.
This is the option recommended in the Beam committer’s guide, but it is not
12 matches
Mail list logo
