Issue #13 resolved

cannot modify diffs for newly added file

sr105
created an issue

{{{ harveybook:Desktop hchapman$ hg init test harveybook:Desktop hchapman$ cd test harveybook:test hchapman$ echo -e "One\nTwo\nThree" >> file.txt harveybook:test hchapman$ hg addremove adding file.txt harveybook:test hchapman$ hg crecord harveybook:test hchapman$ hg export -r tip

HG changeset patch

User Harvey Chapman hchapman@3gfp.com

Date 1277215054 14400

Node ID 9d0e0b6c20e67d04697f76aba9a850dc1c0a0c8a

Parent 0000000000000000000000000000000000000000

test

diff --git a/file.txt b/file.txt new file mode 100644 --- /dev/null +++ b/file.txt @@ -0,0 +1,3 @@ +One +Two +Three }}} **"+One" should not be in the export above since I specifically unselected it.

Comments (4)

  1. sfink

    I ran into this problem, too. The workaround was fairly painful, something like:

    1. Stick the add-file changes into a temporary patch (I'm using mq & qcrecord)
    2. Pop the patch
    3. Create a dummy patch that just creates the new files
    4. Edit the add-file patch. Remove the 'new file' lines, and change '--- /dev/null' to '--- a/path...'.
    5. Push the patches back on

    I'm not sure if it was even that straightforward, but I can't think of what the additional issues might have been. Part of the problem is that hg? mq? refuses to apply a patch that adds files when those files already exist, even if the files are empty.

    It would be awesome if qcrecord were capable of magically Doing The Right Thing magically.

  2. edgimar repo owner
    • changed status to open

    I've also noticed that this behavior occurs when moving a file (hg mv ...), and then trying to do a partial-commit on changes which have been made to the moved file. Ideally, one expects the 'unselected' chunks/lines in crecord to not get committed, and remain as uncommitted changes to the moved file. What happens, though, is that 'unselected' items are ignored (they are treated as if they were selected), and all changes are committed.

    I guess that this is the same problem which is causing the reported bug. If anyone has time to investigate the cause (and solution), go right ahead!! ;) It is probably best to try fixing the bug in record, since this also occurs with record, and the reason one sees it in crecord is because crecord is based on record.

  3. Log in to comment