Re: RFS: commit-patch
David Caldwell <firstname.lastname@example.org> writes:
> Here's a blog post about a possible use case, written a few years ago:
Okay. The author of that post acknowledges:
Checking in patches effectively means checking in untested code.
That's my main problem with the Darcs default of recording untested
changes that never existed in the working tree; if this works the same
way, I'm just as much against it.
> I think it's worth trying (especially if you are an Emacs user)
> because it's a tool that, once you know it exists, you'll start
> reaching for more and more often.
I prefer the Bazaar ‘shelve’ approach: temporarily put aside changes you
*don't* want to commit, leaving the working tree in a state that *is*
suitable for committing. I believe Git's “staging area” works in a
similar way (that is, the changes to be committed actually exist in the
working tree as-is, before being committed).
This means it's a no-brainer to test that working tree state with
exactly those changes that will be committed, before committing;
something that can't be done with Darcs ‘record’ and (IIUC) this
All that said, though, I'm merely saying why I personally wouldn't find
this an improvement over what we already have. It's not a reason to keep
the package out of Debian.
\ “Few things are harder to put up with than the annoyance of a |
`\ good example.” —Mark Twain, _Pudd'n'head Wilson_ |