guix-devel
[Top][All Lists]
Advanced

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

Re: How can we decrease the cognitive overhead for contributors?


From: Maxim Cournoyer
Subject: Re: How can we decrease the cognitive overhead for contributors?
Date: Tue, 05 Sep 2023 11:25:08 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Hi,

brian via "Development of GNU Guix and the GNU System distribution."
<guix-devel@gnu.org> writes:

> pinoaffe <pinoaffe@gmail.com> writes:
>
>> Andreas Enge <andreas@enge.fr> writes:
>>> So as far as I am concerned, they are tremendously useful. Well, that may
>>> be due to a lack of git knowledge, of course! But while in other projects
>>> I often find I need to look at the content of commits, in Guix it is often
>>> enough to just look at the changelog.
>>
>> I also quite like the commit messages, they've allowed me to find things
>> that I couldn't have found using `git blame`
>
> There's a trade-off, though. They seem to have their uses for some
> people, though it doesn't appear to me to be majority of people, on some
> occasions (the relative number of which I can't guess, since I don't use
> them at all). However, there's a cost, too. The very existence of them
> as a requirement puts at least some people off from submission at all,
> it adds to the work of people who still put in the effort to submit
> (especially so for people not using Emacs!), it's an extra check for
> committers to go through. If the check fails, the patch can get bounced
> back for (to me) trivial reasons, or, best case, the committer fixes the
> error themselves. But even in the best case, since the commit hash has
> now changed, it causes ‘git branch -d’ to issue a warning about unmerged
> commits.
>
> I, clearly, do not think the trade-off is worth it.

While experimenting with package builds, it's frequent to add inputs
while testing.  It can be easy to forget about them later when preparing
the commit message.  Typing them out in your commit message forces you
to sign on these changes as 'intended'.

I find them useful for that purpose and frequently catch problems in my
commits while writing the associated changelog (in other words, it
forces me to review my own code).

While 'git log -G' can be useful, it doesn't replace changelog commit
messages, which are much faster (cheaper) to go through with 'git log
--grep='.

-- 
Thanks,
Maxim



reply via email to

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