Re: Edit a rerere conflict resolution

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Op 16-3-2012 17:01, Junio C Hamano schreef:
Vincent van Ravesteijn<vfr@xxxxxxx>  writes:

Op 12-3-2012 21:01, Junio C Hamano schreef:
...
I haven't find it necessary in practice, as the re-fix for me
typically would go like this:

      $ git merge other-branch
      ... rerere kicks in; eyeball the results
      ... ah, my earlier resolution is no longer correct
      $ edit $the_path
      ... test the result of manual edit in the context of the merged whole
      ... and be satisified
      $ git rerere forget $the_path
      $ git add $the_path
      $ git commit
      ... rerere records the updated resolution

This doesn't really work for me:

      $ git merge other-branch
      Auto-merging<path>
      CONFLICT (content): Merge conflicts in<path>
      Resolved '<path>' using previous resolution.
      Automatic merge failed; fix conflicts and then commit the result.

      $ git rerere status
      $ git rerere forget<path>
      error: no remembered resolution for<path>

      $ edit<path>
      $ git commit -a -m "fix"
      ... no sign of rerere doing something.

Why is this different from what you describe above, and how can I
modify the recorded resolution ?
Do you have rerere.autoupdate set by any chance?  If so, don't.  At least
when you are trying to purge the broken rerere entry.

No, I turned rerere.autoupdate off. Proven in the above by the line "Resolved... " instead of "Staged...".

Vincent



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]