[Top][All Lists]

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

Re: [RFE] Migration to gitlab

From: Basil L. Contovounesios
Subject: Re: [RFE] Migration to gitlab
Date: Sat, 11 May 2019 20:25:25 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: 조성빈 <address@hidden>
>> Date: Sat, 11 May 2019 16:38:30 +0900
>> Cc: address@hidden, address@hidden, address@hidden,
>>  address@hidden, address@hidden, address@hidden
>> If you’re saying commit messages, you can view them and ask the contributors
>> to fix the messages, rebase the commits, and force-push them. You can merge
>> them afterwards.
> Asking the contributors to fix the log messages works only up to some
> not very far limit.  Quite frequently, IME, the 2nd, the 3rd, and
> sometimes the 4th attempt are still not what I'd like to see, whether
> due to misunderstanding or something else.  At which point I usually
> give up and fix the rest myself, so as not to discourage the
> contributor the next time he/she wants to contribute.
> Force-push is normally not an option, as our repository disallows
> that, to avoid someone's mistake corrupting the repository or losing
> data.
> So there should be an easy way of accepting a PR/MR where I can
> augment the log message in the process.  Because once the commit is
> pushed, whatever deficiencies there were in the log message are carved
> in stone forever.

I'm not sure if GitLab has added this feature yet, but GitHub pull
request submissions include a checkbox (default on) to allow the
project's maintainers to edit the pull request.  This means they are
allowed to push (forcefully or otherwise) changes to the submitter's
non-master branch before merging the pull request.

I don't find this a particularly "nice" way to work by default (so I'm
not advocating it), but I thought I'd mention it for completeness.



reply via email to

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