emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]


From: João Távora
Subject: Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]
Date: Wed, 20 Nov 2019 16:53:09 +0000

On Wed, Nov 20, 2019 at 4:27 PM Eli Zaretskii <address@hidden> wrote:

> > Of course, if somebody wants to hit the "merge pull request" button
> > in Gitlab, they can do that, but for most smaller pull requests,
> > Gitlab would just email the patch (presumably) and we can apply it
> > locally on our machines before pushing to the repo, just like now.
>
> What you describe is not the PR workflow that people are used to.

I don't think it's very far off, though.  Here's my usual workflow with
GitHub, in the hope that it helps the discussion:

In GitHub (very similar to Gitlab), I will often cherry-pick the PR's
commits, squash them, make minor adjustments to the commit
message or even the contents and then push them myself, preserving
the with the original authorship (and sometimes crediting myself as
the co-author).

To cherry-pick the PR"s commits, I just `git fetch` from a special
Git URL that references the PR's number.  In other words, there
is no clicking in the web interface required at all.

I can push my changes to master directly, but oftentimes I will
push them to the submitter's PR branch directly (when the
submitter gives me permission to do so). Again, no Web UI
is required for this (though it helps to track where things
stand at each moment, of course)

When I'm happy with the changes, I push to master. There
are some situations where GitHub detects that I merged the
contribution. For the cases where it doesn't, I sometimes include
a "Fix #PRNUMBER" line in the commit message. This ensures
it is automatically closed.

Up to this point, I have not used the Web UI at all. There is
small wrinkle though, which may or may not be important:
Github doesn't mark the PR's I merged with the "Fix
#PRNUMBER" label purple, its oficial color for a "Merged" PR.

Perhaps Gitlab could support "Merge #PRNUMBER"
as a way to manually mark purple.

>From the contributor's side, I've never had anyone object or find
this confusing. I believe once the submitter sees his/her commits in
the DAG with the little avatar they know what's happening.

Also, the bug numbers in the commit message automatically
create clickable cross-references in the PR's discussion page.
(This is like if debbugs automatically sent emails to the bug
number everytime anyone composes and pushes a commit
that mentions the bug's number.)

-- 
João Távora



reply via email to

[Prev in Thread] Current Thread [Next in Thread]