emacs-devel
[Top][All Lists]
Advanced

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

Re: [RFE] Migration to gitlab


From: Dmitry Gutov
Subject: Re: [RFE] Migration to gitlab
Date: Sat, 11 May 2019 16:13:09 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 11.05.2019 13:02, Eli Zaretskii wrote:

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.

Same here.

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.

There are basically two options:

If the MR only has a few commits (or just one, which might consititute the majority of them), you can "Merge with squashing" by clicking a checkbox: https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html. The UI will let you edit the commit message for the squashed commit before it is merged.

That would probably require using the Web UI; a hypothetical Emacs-based client might also support that later, IDK.

The alternative option is always there: when you don't want to squash all commits together (say, the branch is long and big), you can, of course, fetch it, check it out locally, rebase (fixing all commit messages while doing that) and push. And close the MR manually (I think automatic detection will break in the presence of rebasing).

And yes, GitLab adds the reference to the issue, which commit or PR resolves 
this issue.

What if the issue is not yet resolved, like when we commit a change
that fixes only part of the issue, or is only tangentially related to
it?  We cannot yet close the issue, but a reference to it should be in
the commit log.

An issue reference doesn't have to close it. #123 is a reference. "Fixes #123" is an auto-closing reference. Some details here: https://docs.gitlab.com/ee/user/project/issues/automatic_issue_closing.html

To sum up, we can create references to issues in commits (which the GitLab UI recognizes as references), *and* we can make commits close issues. In the latter case the issue notes will reference the commit that closed it automatically.

About adding the copyright/paperworks, there isn’t a default setting, but you 
can have a bot to do that. I’ve never used one myself, so I’m not sure, but 
I’ve seen lots of projects that use bots to get paperwork, etc...

How can a bot do that, when a commit log message is immutable once the
commit is pushed?

Is a commit message related to copyright/paperworks?



reply via email to

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