Strategies for push/merge problem?

[Douglas Philips]

On or about 2008 Jul 15, at 2:03 PM, Martin Geisler indited:
> If I have understood Adrian correctly, then he wants the test suite to
> pass at every changeset. So the first changeset adds the new
> functionality (without making any of the existing tests fail) and the
> second changeset add tests for the new functionality.

Yes, for brand new functionality, that might work. If I'm refactoring,  
or if I'm enhancing and changing existing APIs, it doesn't. Old code  
breaks, new code is incomplete, how do I avoid the Highlander of  
changesets, "there can be only one" ?

>> qrecord (if it existed)... letting me put the different hunks into
>> different patches, would be a way to avoid that. (As I understand
>> it, the reason for the qpush/qpop dancin' is to get the hunks into
>> the right paches?)
>
> Yes -- it is so that qrefresh affects the right patch.

So theoretically it would be possible to have a qrecord-ish command  
that would let me say: This hunk goes in that patch, that hunk goes in  
this one, ....
Since I can do that with enough qpush/qpop juggling, right?

--Doug