Commit messages and the move to git
Richard Earnshaw (lists)
Richard.Earnshaw@arm.com
Mon Nov 4 16:35:00 GMT 2019
On 04/11/2019 16:19, Jonathan Wakely wrote:
> On Mon, 4 Nov 2019 at 10:29, Richard Earnshaw (lists)
> <Richard.Earnshaw@arm.com> wrote:
>>
>> With the move to git fairly imminent now it would be nice if we could
>> agree on a more git-friendly style of commit messages; and, ideally,
>> start using them now so that the converted repository can benefit from this.
>>
>> Some tools, particularly gitk or git log --oneline, can use one-line
>> summaries from a commit's log message when listing commits. It would be
>> nice if we could start adopting a style that is compatible with this, so
>> that in future commits are summarized in a useful way. Unfortunately,
>> some of our existing commits show no useful information with tools like
>> this.
>>
>> Eg.
>>
>> git log --oneline
>> 2b70dbd64b5 (HEAD -> master, origin/trunk, origin/master, origin/HEAD)
>> 2019-11-01 Kewen Lin <linkw@gcc.gnu.org>
>> 29f4f5f13b9 [C++ PATCH] cleanup check_field_decls
>> 0f931fb75ae 2019-11-01 Kewen Lin <linkw@gcc.gnu.org>
>> e9c4da22199 OpenMP] use_device_addr/use_device_ptr with Fortran
>> allocatable/pointer arrays
>> 377311a90fa 2019-11-01 Kewen Lin <linkw@gcc.gnu.org>
>> cc286dd8517 Daily bump.
>> 8e87e30df8d Regenerate libstdc++ HTML docs
>> fad04d507e0 Add remaining changes from P1065R2 "constexpr INVOKE"
>> d5e4b5a17de Partial implementation of C++20 of <ranges> header
>> 345d712f776 Test --help=common for full sentences
>> a737cc23c15 PR preprocessor/92296 * internal.h (struct
>> def_pragma_macro): Add is_builtin bitfield.
>> (_cpp_restore_special_builtin): Declare. * init.c
>> (_cpp_restore_special_builtin): New function. * directives.c
>> (do_pragma_push_macro): For NT_BUILTIN_MACRO set is_builtin and
>> don't try to grab definition. (cpp_pop_definition): Use
>> _cpp_restore_special_builtin to restore builtin macros.
>> e9c843f92f6 2019-10-31 Jozef Lawrynowicz <jozef.l@mittosystems.com>
>> d7069e154ee [AArch64] Fix g++.target/aarch64/sve/vcond_1_run.C
>> ae5f034c085 [AArch64] Split gcc.target/aarch64/sve/vcond_4*
>>
>> As you can see, some of these are useful and give a good summary of the
>> patch, others only tell me who committed the patch, which is less than
>> useful. In other cases almost the entire ChangeLog entry gets printed
>> because there is no blank line to tell git where the end of the summary
>> lies.
>>
>> The normal convention in git is that the one line summary is essentially
>> the subject line of the email message that describes the patch and is
>> then followed by a blank line before the body of the commit message.
>
> I've already proposed a more specific format for libstdc++:
> https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html
>
Well having additional requirements for a component on top of 'global'
requirements doesn't pose a real problem as long as the maintainers of
that component concur.
Having incompatible requirements would be problematic, though.
R.
More information about the Gcc
mailing list