Re: [Bug?] Information around newlines lost in merge

From: Karthik Nayak <karthik.188@gmail.com>
Date: Jun 21, 2023, 11:41 UTC
Message-ID: <CAOLa=ZTBkzc78RpAdeQO2yN_itDbmKvkQ91RQjENwD9Y8uwR+w@mail.gmail.com>
In-Reply-To: <xmqqh6r2ni4i.fsf@gitster.g>

On Tue, Jun 20, 2023 at 7:44 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 21 quoted lines

>
>         $ git merge-file -p A O B
>         <<<<<<< A
>         with a single line added by side A (without terminating LF).
>         \No newline at end of file
>         ||||||| O
>         =======
>         with a single line added by side B (without terminating LF).
>         \No newline at end of file
>         >>>>>>> B
>
> It has exactly the same problem we already have as these conflict
> section separator lines in that lines that exactly would look like
> these extra lines _could_ exist in the payload, so it is not
> creating a new problem, but people may have built and are happy
> enough with their incomplete automation that relies on the faulty
> assumption that the merged payload would never contain lines that
> are mistaken as conflict section separator lines, and such an
> augmented output format _will_ be a breaking change to them.
>
> So, I dunno.

Thank you for taking the time and responding. I'm wondering if there is merit in modifying the merge algo.

Perhaps something where files merged with terminating LF would retain it. So merging "A\n" and "B\n" would produce "<<<<<<< master\nA=======\nB\n>>>>>>> newBranch\n\n", whereas files being merged without a terminating LF wouldn't, so merging "A" and "B" would produce "<<<<<<< master\nA=======\nB\n>>>>>>> newBranch\n". Which would make it easier to parse.

But overall, I get what you're saying. I will drop it here as expected behavior!