Fil
2018-11-29 23:46:25 UTC
-------- Forwarded Message --------
Subject: Re: [Replicant] [PATCH] fix #1853 "Ecryption" typo in Settings
App
Date: Sun, 25 Nov 2018 12:00:14 +0100
From: Fil <***@riseup.net>
To: Denis 'GNUtoo' Carikli <***@cyberdimension.org>
Hello all,
as I promised to Joonas, here's a revised patch bearing the commit
message that Denis suggested.
Joonas, please let me know if changing the message by hand worked and
you were able to push it.
Otherwise, I can redo the patch from scratch.
Cheers, everybody!
Fil
Subject: Re: [Replicant] [PATCH] fix #1853 "Ecryption" typo in Settings
App
Date: Sun, 25 Nov 2018 12:00:14 +0100
From: Fil <***@riseup.net>
To: Denis 'GNUtoo' Carikli <***@cyberdimension.org>
Hello all,
as I promised to Joonas, here's a revised patch bearing the commit
message that Denis suggested.
Joonas, please let me know if changing the message by hand worked and
you were able to push it.
Otherwise, I can redo the patch from scratch.
Cheers, everybody!
Fil
On Mon, 08 Oct 2018 13:55:00 +0000
<https://hackernoon.com/on-git-commit-messages-and-issue-trackers-f700f3cbb5a7?gi=1821111258f>.
The article mentions that issue tracker could change in future
therefore making those IDs in Git meaningless. As we don't publish
and review our patches in the issue tracker it means that if one
wants to sent patch to this mailing list they must also mention in a
cover letter / patch which issue the patch addresses but we would
have to do it anyways since one needs to tell also to what repository
the patch is for. So I don't think it is a big deal to drop the
ticket ID from the commit message.
I'm aware of that.
Different projects probably have different views on the topic. It also
depends a lot on how such thing is used or abused: Adding a pointer to
a bugreport should not be a substitute for writing good enough commit
messages.
For instance the Linux project sometimes has some pointers to
that this was discovered through a bugreport and we might want to look
how the bug was discovered and fixed.
message/summary and then closing the bugreport with a pointer to the
fix also works for me.
Denis.
Hi,
Hi,On Sun, 2 Sep 2018 21:17:21 +0200
I researched online this topic a bit and maybe providing ticket ID inFrom e17c05cfe9665ff1ec9dffbf46f90be18e44fa3d Mon Sep 17 00:00:00
Date: Sun, 2 Sep 2018 16:44:44 +0000
Subject: [PATCH] fix #1853 "Ecryption" typo in Settings App
Maybe mention the fact that the #1853 is a bug.Date: Sun, 2 Sep 2018 16:44:44 +0000
Subject: [PATCH] fix #1853 "Ecryption" typo in Settings App
fix bug #1853 ("Ecryption" typo in Settings App)
<https://hackernoon.com/on-git-commit-messages-and-issue-trackers-f700f3cbb5a7?gi=1821111258f>.
The article mentions that issue tracker could change in future
therefore making those IDs in Git meaningless. As we don't publish
and review our patches in the issue tracker it means that if one
wants to sent patch to this mailing list they must also mention in a
cover letter / patch which issue the patch addresses but we would
have to do it anyways since one needs to tell also to what repository
the patch is for. So I don't think it is a big deal to drop the
ticket ID from the commit message.
Different projects probably have different views on the topic. It also
depends a lot on how such thing is used or abused: Adding a pointer to
a bugreport should not be a substitute for writing good enough commit
messages.
For instance the Linux project sometimes has some pointers to
commit 7ce5c8cd753f9afa8e79e9ec40351998e354f239
[...]libata: mask swap internal and hardware tag
[commit message]Fixes: 28361c403683 ("libata: add extra internal command")
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=201151
Here adding a link to the bugreport might be interesting, as we knowBuglink: https://bugzilla.kernel.org/show_bug.cgi?id=201151
that this was discovered through a bugreport and we might want to look
how the bug was discovered and fixed.
What I suggest for the commit message is "Fix "Ecryption" typo".
As the patch is simple enough, merging it with the above commitmessage/summary and then closing the bugreport with a pointer to the
fix also works for me.
Denis.