Re: Splitting up guc.c

From: Andres Freund <andres(at)anarazel(dot)de>
To: Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Splitting up guc.c
Date: 2022-09-12 20:50:24
Message-ID: 20220912205024.6bow7zzl7tin35ul@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2022-09-12 21:12:03 +0100, Dagfinn Ilmari Mannsåker wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> >> I think this is localized enough that asking people to manually resolve a
> >> conflict around adding a GUC entry wouldn't be asking for that much. And I
> >> think plenty changes might be automatically resolvable, despite the rename.
> >
> > I wonder whether git will be able to figure out that this is mostly a
> > code move. I would expect so for a straight file rename, but will that
> > work when we're splitting the file 3 ways?
>
> Git can detect more complicated code movement (see the `--color-moved`
> option to `git diff`), but I'm not sure it's clever enough to realise
> that a change modifying a block of code that was moved in the meanwhile
> should be applied at the new destination.

It sometimes can for large code movements, but not in this case. I think
because guc.c is more self-similar than guc_tables.c.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joel Mariadasan (jomariad) 2022-09-12 20:52:46 Permissions denied for the database file system on Windows during restore
Previous Message Andres Freund 2022-09-12 20:49:27 Re: Splitting up guc.c