git hooks: Adjust hooks for the ports tree

[0mp]

Summary

• Capitalize the topic line: this way the example is consistent with the desired style.
• Update the description of MFH.
• Point the Pull Request field to the ports repo on GitHub.

[0mp]

Change the commit message

[0mp]

Whoops, I upated the wrong Phabricator link. Sorry about that.

Bring back the correct patch.

[0mp]

Do not remove MFH

[adamw]

Two thoughts here:

1. Should we restore "Submitted by:" to this list?
2. Should we examine $(make -V PKGORIGIN) to prepopulate the subject (first) line?

[kevans]

In D29861#670166, @adamw wrote:

Two thoughts here:

1. Should we restore "Submitted by:" to this list?

IMO if "Submitted by" gets restored, it should be noted that it's expected to be more of an anomaly than the norm -- reserved for situations where the original work was submitted by someone else, but changed substantially enough that the author should be updated.

[adamw]

In D29861#670168, @kevans wrote:

IMO if "Submitted by" gets restored, it should be noted that it's expected to be more of an anomaly than the norm -- reserved for situations where the original work was submitted by someone else, but changed substantially enough that the author should be updated.

Interesting. I always thought of that for "Reported by," and treated "Submitted by" as the norm.

[kevans]

In D29861#670177, @adamw wrote:

In D29861#670168, @kevans wrote:

IMO if "Submitted by" gets restored, it should be noted that it's expected to be more of an anomaly than the norm -- reserved for situations where the original work was submitted by someone else, but changed substantially enough that the author should be updated.

Interesting. I always thought of that for "Reported by," and treated "Submitted by" as the norm.

In a scenario where someone submitted a patch, "Reported by" would imply an even further alteration where you didn't really use their patch at all but took it as an alert that the problem existed. In a Git world, if you used their patch then the author would reflect them and the committer would reflect you, and if you made substantial changes to the patch then the author can reflect you and "Submitted by" would note the author of the patch you based it off of.

[adamw]

I may be misunderstanding the process you're describing, but it sounds to me like you're talking about a situation involving merging a pull request where the author is annotated. If the submission came from a BZ bug report, is the "Submitted by" field not still relevant?

My brain is definitely adapting slowly to the new git world order.

[0mp]

In D29861#670166, @adamw wrote:

1. Should we examine $(make -V PKGORIGIN) to prepopulate the subject (first) line?

This will not work. The editor is started from the root of the project directory. The following line is what I add to my hook at the moment:

$(git status --untracked-files=no --short | awk '{print $NF}' | cut -d / -f 1-2 | sort -u)

I am not sure if it's pretty enough to get included.

[0mp]

In D29861#670182, @adamw wrote:

I may be misunderstanding the process you're describing, but it sounds to me like you're talking about a situation involving merging a pull request where the author is annotated. If the submission came from a BZ bug report, is the "Submitted by" field not still relevant?

My brain is definitely adapting slowly to the new git world order.

From what I understand, it is not relevant because you can use git commit --author "Ports Contributor <[e-mail]>" in order to show who's the author.

[kevans]

In D29861#670182, @adamw wrote:

I may be misunderstanding the process you're describing, but it sounds to me like you're talking about a situation involving merging a pull request where the author is annotated. If the submission came from a BZ bug report, is the "Submitted by" field not still relevant?

My brain is definitely adapting slowly to the new git world order.

Ok, let's start over. :-) The key point that I think we're missing here is that Git has a separate record of who wrote a change, vs. who committed a change. Take a look, for example, at this in base: git show --pretty=full 600bd6ce0639c:

commit 600bd6ce0639c84b763516477250df5964e8edf6
Author: Kurosawa Takahiro <[e-mail]>
Commit: Kristof Provost <[e-mail]>

    pfctl, libpfctl: introduce pfctl_pool

    Introduce pfctl_pool to be able to extend the pool part of the pf rule
    without breaking the ABI.

    Reviewed by:    kp
    MFC after:      4 weeks
    Differential Revision:  https://reviews.freebsd.org/D29721

As @0mp pointed out, with a random patch from Bugzilla you would commit with git commit --author="Bob Snow <[e-mail]>" to get the correct authorship recorded and you would be reflected on the "Commit" line (this requires --pretty=full to show). Going forward, we should be encouraging git show style patches so that you can just git am it and not worry about the metadata or commit message.

[0mp]

Update MFH description

[mat]

Why remove Relnotes? It would be great if people could use it for important stuff, could be used when branching a new quarterly branch, or when a release is cut.

[adamw]

In D29861#670188, @kevans wrote:

As @0mp pointed out, with a random patch from Bugzilla you would commit with git commit --author="Bob Snow <[e-mail]>" to get the correct authorship recorded and you would be reflected on the "Commit" line (this requires --pretty=full to show). Going forward, we should be encouraging git show style patches so that you can just git am it and not worry about the metadata or commit message.

Aha! That clicked for me. Thanks!

[0mp]

In D29861#670208, @mat wrote:

Why remove Relnotes? It would be great if people could use it for important stuff, could be used when branching a new quarterly branch, or when a release is cut.

I removed it because I always found it confusing in the ports world. We don't really use it consistently, sometimes committers put links to port's release notes there. Also, the only valid value for this metadata field is yes according both to the commit hook and the Committer's Guide, which makes no sense in terms of ports because we have no ports releases.

That's my reasoning.

If we can benefit from a field where we can mark important events in the ports tree then I'd introduce a new metadata field. This way we avoid confusion with how this field works in the src tree.

[sbz]

.hooks/prepare-commit-msg

58

I think we can update<repo> and set it to be ports here, now it lives in the repo.

[mat]

Please keep Relnotes.

[0mp]

• Add Relnotes back as requested by @mat.
• Update the Pull Request field