Re: [PATCH] revert: optionally refer to commit in the "reference" format

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

 



Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:

>> +		if (!opts->commit_use_reference) {
>> +			strbuf_addstr(&msgbuf, "Revert \"");
>> +			strbuf_addstr(&msgbuf, msg.subject);
>> +			strbuf_addstr(&msgbuf, "\"");
>> +		} else {
>> +			strbuf_addstr(&msgbuf, "DESCRIBE WHY WE ARE REVERTING HERE");
>
> Having seen how people use git in the wild, this *WILL* result in a
> bunch of history where people don't edit that at all.

It was done very much on purpose.  A pressure from other project
participants against the ugly all caps content-free message will
help instill better behaviour.  A solo developer also will learn
after making reverts with content-free titles (and if they do not
find it inconvenient for their development purpose that their
history is full of content-free titles shouting in all caps, then
more power to them---if they are happy, we are happy, too).

If we leave something like

	# Add one line above and explain not *what* this revert did,
	# but *why* you decided to revert in 50-70 chars.  Did it
	# break something? Was it premature?

	This reverts commit 8aa3f0dc (CI: set CC in MAKEFLAGS directly, 2022-04-21)

presumably, stripspace will make the "This reverts commit ..." the
title of the reverted commit.  It would invite people not to edit it
out out of laziness.  Since the whole point of this change is to
encourage people to describe the reason behind the revert on the
subject line, such an invitation is counter-productive.

Doing the first two lines like so:

	Revert 8aa3f0dc (CI: set CC in MAKEFLAGS directly, 2022-04-21)
	# Edit the above line to explain not *what* this revert did,

would have pretty much the same effect, I am afraid.

So...




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux