Skip to content
Snippets Groups Projects
Commit 66117dae87f9 authored by Jun Wu's avatar Jun Wu
Browse files

patch: rewrite reversehunks (issue5337)

The old reversehunks code accesses "crecord.uihunk._hunk", which is the raw
recordhunk without crecord selection information, therefore "revert -i"
cannot revert individual lines, aka. issue5337.

The patch rewrites related logic to return the right reverse hunk for
revert. Namely,

 1. "fromline" and "toline" are correctly swapped [1]
 2. crecord.uihunk generates a correct reverse hunk [2]

Besides, reversehunks(hunks) will no longer modify its input "hunks", which
is more expected.

[1]: To explain why "fromline" and "toline" need to be swapped, take the
     following example:

  $ cat > a <<EOF
  > 1
  > 2
  > 3
  > 4
  > EOF

  $ cat > b <<EOF
  > 2
  > 3
  > 5
  > EOF

  $ diff a b
  1d0   <---- "1" is "fromline" and "0" is "toline"
  < 1         and they are swapped if diff from the reversed direction
  4c3             |
  < 4             |
  ---             |
  > 5             |
                  |
  $ diff b a      |
  0a1   <---------+
  > 1
  3c4   <---- also "4c3" gets swapped to "3c4"
  < 5
  ---
  > 4

[2]: This is a bit tricky.

For example, given a file which is empty in working parent but has 3 lines
in working copy, and the user selection:

    select hunk to discard
    [x] +1
    [ ] +2
    [x] +3

The user intent is to drop "1" and "3" in working copy but keep "2", so the
reverse patch would be something like:

        -1
         2 (2 is a "context line")
        -3

We cannot just take all selected lines and swap "-" and "+", which will be:

        -1
        -3

That patch won't apply because of "2". So the correct way is to insert "2"
as a "context line" by inserting it first then deleting it:

        -2
        +2

Therefore, the correct revert patch is:

        -1
        -2
        +2
        -3

It could be reordered to look more like a common diff hunk:

        -1
        -2
        -3
        +2

Note: It's possible to return multiple hunks so there won't be lines like
"-2", "+2". But the current implementation is much simpler.

For deletions, like the working parent has "1\n2\n3\n" and it was changed to
empty in working copy:

    select hunk to discard
    [x] -1
    [ ] -2
    [x] -3

The user intent is to drop the deletion of 1 and 3 (in other words, keep
those lines), but still delete "2".

The reverse patch is meant to be applied to working copy which is empty.
So the patch would be:

        +1
        +3

That is to say, there is no need to special handle the unselected "2" like
the above insertion case.
parent 41b081ac2145
No related branches found
No related tags found
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment