Re: RFS: commit-patch
> David Caldwell <david@porkrind.org> writes:
>
> > Here's a blog post about a possible use case, written a few years ago:
> >
> > <http://porkrind.org/missives/commit-patch-managing-your-mess>
>
> 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.
Yes, it basically works that way and I can understand your point of
view--the changes that go in are ephemeral and haven't actually existed
until being committed.
One thing to think about though: if you've ever checked in a single file
from your working directory you have essentially done the same thing--it's
just a different level of granularity.
> 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.
Interesting. I hadn't considered the shelve feature that way--I've been
thinking of it in terms of "git stash": as a way to get the directory clean
for merges. I saw that it let you shelve hunks away but didn't understand
what that feature might be used for.
> 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).
AFAIK the changes in the staging area exist as an internal git structure and
not as something that you can "get to" from the filesystem and test
directly. They are, like "darcs record", unrelated to the current working
directory.
Git even has "git apply --cached" which will put a patch in the staging area
without touching the working directory (and this is how commit-patch works
with git internally).
> 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
> 'commit-patch' method.
Darcs solves this with their "test" preference. You can define a test to run
before a commit is finalized and darcs will run the test on a clean checkout
with the only potential patch applied (ie. not on the working directory). If
the test passes, the patch actually gets recorded. Your test can be
anything--just a simple "make" or it could run your full test suite.
I believe git has a similar "test before commit" feature (though I haven't
used it myself yet).
> 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.
I understand. Thanks for taking the time to think about it, I appreciate the
alternate point of view.
-David
Reply to: