Re: Updating the commit message for reverts

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

 



On 2019-12-27 11:13:47+0100, Gal Paikin <paiking@xxxxxxxxxx> wrote:
> Hi,
> Thanks for the reply!
> 
> So the idea of changing from "Revert Revert" to "Reland", "reapply"
> has a big problem: sometimes Revert^2 actually means 'reverting
> "Revert"' since "Revert" introduced a bug that wasn't in the original
> change.
> 
> So to your question, I don't know what Revert^47 means since it
> depends on each individual case. Sometimes it actually means "Revert"
> and sometimes it means "Reland".
> 
> So do people actually use it? Yes! Many users reported to me that it
> is not that unusual to get to "Revert^6", and it is very usual and

I've seen Revert x6 in a code base, I couldn't get to know the reason
for that reversion war. I think it could be seen more in some in-house
web development that uses trunk-based development, code is being
tested with CI/CD, lightly tested, squash-merged to master,
then run into problem in staging (or worst, production, because not
enough traffix was generated for testing environment).

> common to get to "Revert^2/3/4". It is also useful for the users to
> know the number of the revert, according to the reports. Here is an
> example:
> https://android-review.googlesource.com/c/platform/art/+/352330
> Feel free to also search for "Revert^2/3/4" to find many results.
> 
> Anyway, I am certain that "Revert^3" is better than "Revert revert
> revert". There is definitely no clear way to solve this issue, but
> perhaps "nth revert" would be a more "human language" solution?

In my very personal opinion, "nth revert" is a poor choice.
At a first glance, I would take it as:

	This is the "nth revert", after applying this patch n times.

-- 
Danh



[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