Re: [hatari-devel] HDC code update patch

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

Hi again,

> Main reason for this is that I'd like your commit message to tell reason 
> for the functional changes you did not mention:
> -	else if (ctr->opcode == 0x05 || (ctr->opcode >= 0x20 && ctr->opcode <= 
> 0x7d)) {
> +	else if (ctr->opcode >= 0x20 && ctr->opcode <= 0x7d) {
> ...
> -	else if (ctr->opcode >= 0x60)
> +	else if (ctr->opcode >= 0x60 && ctr->opcode != HD_REPORT_LUNS)
> 
> (If it e.g. fixes your earlier commit, it would be nice to give ID for 
> the fixed commit in the commit message.)

Don't get me wrong, but let me just say that the recommended length of git
commit messages is 70-75 characters. https://i.stack.imgur.com/uzUqh.png
shows that for the Linux kernel the contributors mostly manage to stay
within this range.
If you mention the commit ID you refer to in your comment there is hardly
any space left for other information. I don't see this practice followed in
hardly any recent commit messages, by the way.

Again, don't get me wrong, but if what you pointed out is the Hatari commit
message policy, it is IMHO not very developer-friendly.

The way github handles this is quite good, because you can edit the
consolidated commit message in the web frontend before merging a PR, usually
with commit squashing enabled. Of course, one does not need github for this,
because squashing commits is a git feature.

I would like to hear other opinions on that.

Best regards

Uwe