Re: Rework the way multixact truncations work

On Fri, Nov 27, 2015 at 5:16 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> On Mon, Nov 23, 2015 at 11:44:45AM -0800, Peter Geoghegan wrote:
>> On Sun, Nov 8, 2015 at 11:52 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>> >> I'm not following along right now - in order to make cleanups the plan is to revert a couple commits and then redo them prettyfied?
>> >
>> > Yes, essentially. Given the volume of updates, this seemed neater than
>> > framing those updates as in-tree incremental development.
>>
>> I think that's an odd way of representing this work. I tend to
>> remember roughly when major things were committed even years later. An
>> outright revert should represent a total back out of the original
>> commit IMV. Otherwise, a git blame can be quite misleading.
>
> I think you're saying that "clearer git blame" is a more-important reason than
> "volume of updates" for preferring an outright revert over in-tree incremental
> development. Fair preference. If that's a correct reading of your message,
> then we do agree on the bottom line.

Hmm. I read Peter's message as agreeing with Andres rather than with
you. And I have to say I agree with Andres as well. I think it's
weird to back a commit out only to put a bunch of very similar stuff
back in. Even figuring out what you've actually changed here seems
rather hard. I couldn't get github to give me a diff showing your
changes vs. master.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company