view tests/test-issue2137.t @ 32979:66117dae87f9

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.

https://bz.mercurial-scm.org/2137

Setup:

create a little extension that has 3 side-effects:
1) ensure changelog data is not inlined
2) make revlog to use lazyparser
3) test that repo.lookup() works
1 and 2 are preconditions for the bug; 3 is the bug.

  $ cat > commitwrapper.py <<EOF
  > from mercurial import extensions, node, revlog
  > 
  > def reposetup(ui, repo):
  >     class wraprepo(repo.__class__):
  >         def commit(self, *args, **kwargs):
  >             result = super(wraprepo, self).commit(*args, **kwargs)
  >             tip1 = node.short(repo.changelog.tip())
  >             tip2 = node.short(repo.lookup(tip1))
  >             assert tip1 == tip2
  >             ui.write('new tip: %s\n' % tip1)
  >             return result
  >     repo.__class__ = wraprepo
  > 
  > def extsetup(ui):
  >     revlog._maxinline = 8             # split out 00changelog.d early
  >     revlog._prereadsize = 8           # use revlog.lazyparser
  > EOF

  $ cat >> $HGRCPATH <<EOF
  > [extensions]
  > commitwrapper = `pwd`/commitwrapper.py
  > EOF

  $ hg init repo1
  $ cd repo1
  $ echo a > a
  $ hg commit -A -m'add a with a long commit message to make the changelog a bit bigger'
  adding a
  new tip: 553596fad57b

Test that new changesets are visible to repo.lookup():

  $ echo a >> a
  $ hg commit -m'one more commit to demonstrate the bug'
  new tip: 799ae3599e0e

  $ hg tip
  changeset:   1:799ae3599e0e
  tag:         tip
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     one more commit to demonstrate the bug
  

  $ cd ..