Saturday, 9 November 2013

Why checkpoint commits are a good idea...

[12:11] <gbb> idea:  [c/sh]ould merge automagically take a security diff before merging, just to protect the clumsy from their foolish mistakes?  (I merged my working copy instead of my test dir in gdb, oww, repairable but ugh...)
[12:12] <stsp> gbb, you mean something like merge --dry-run?
[12:13] <stsp> with such things, it's tricky: if we do a check by default, one set of people will complain about the additional overhead, while the other group will complain about the need to specify an option to get the safe behaviour
[12:13] <gbb> hrm dry-run would have helped but not protected me from merging over all my work.  ;(  (luckily my emacs is my handbag and most of those files were still open)
[12:14] <stsp> i think it's the type of mistake that you just need to learn to avoid over time
[12:15] <stsp> if we had checkpoints implemented, you could checkpoint your working copy before a merge, to keep a record of the pre-merge state
[12:15] <stsp> i think that would be a nice solution
[12:16] <stsp> merge could automatically create such a checkpoint, in fact!
[12:16] <gbb> not sure what check points are.  but currently you can only revert to pristine, not to pre-merge
[12:16] <stsp> see
[12:17] <stsp> or shelving, even
[12:19] <gbb> that would be the ticket :)
[13:20] <ASFBot> gbg * r1540299 (subversion/branches/invoke-diff-merge-feature/ (14 files in 6 directories)) : On the invoke-diff-cmd-feature branch: Checkpoint commit (ignore, trivial).
[13:32] <gbb> as Mr. Twain remarked: "A man who carries a cat by the tail learns something he can learn in no other way."
[13:32] <stsp> :)