[Bug 4991] New: commit --amend --interactive and amend --interactive: unselected hunks with fixed newlines get committed

[mercurial-bugs at selenic.com]

https://bz.mercurial-scm.org/show_bug.cgi?id=4991

            Bug ID: 4991
           Summary: commit --amend --interactive and amend --interactive:
                    unselected hunks with fixed newlines get committed
           Product: Mercurial
           Version: 3.6.2
          Hardware: PC
                OS: Windows
            Status: UNCONFIRMED
          Severity: bug
          Priority: wish
         Component: eol
          Assignee: bugzilla at selenic.com
          Reporter: bamccaig at gmail.com
                CC: mercurial-devel at selenic.com

A particular SQL file had mixed newlines. I noticed early on Monday morning two
hunks in the patch that just modified invisible white-space and decided to
strip them to keep the patch simple and clean.

I switched to the affected patch (hg prevous && hg previous && hg previous),
uncommitted the changes (hg uncommit -all), and attempted to amend the
changeset interactively (hg amend -i). I skipped the first hunk, which just
added a missing CR byte (n). I included the next hunk, which contained the
actual intended change (y). I then skipped the final hunk by skipping all
remaining hunks (d). Afterward I inspected the results: the commit had all of
the changes according to "hg diff -c ."

Originally I thought that the dirstate still showed the bottom white-space hunk
with "hg diff", despite the changeset seeming to include it, but upon trying to
reproduce it I no longer see that. I may remember it wrong.

My eol section looks like this:

    [eol]
    only-consistent = False

Mercurial is installed in Windows using C:\Python27\Scripts\pip.EXE. I first
experienced the bug at 3.6.1 (when the phantom dirstate issue occurred, if at
all), but updated to 3.6.2 and it was still present.

evolve-main was originally at b338fe4e0657, but has since been updated to
ed63bf62ff02.

This is not a very ideal report because it's environment-based, and my
environment is about as complicated as they come. durin42 suggested I file a
report anyway so that he might look into it... We think we narrowed it down to
the eol extension being enabled, at least. Which isn't entirely surprising
since the buggy hunks were fixing newline sequences.

Now that I know the eol extension and mixed newlines are likely responsible I
might be able to come up with a simpler test case later on, but in case I don't
get around to it I'll post this anyway.

-- 
You are receiving this mail because:
You are on the CC list for the bug.