[PATCH 0 of 3] RFC: Splitting patch hunks with the record extension

[Steve Borho]

On Sun, Jan 24, 2010 at 2:40 PM, Patrick Mézard <pmezard at gmail.com> wrote:
> Le 24/01/10 20:48, Steve Borho a écrit :
>
> [...]
>
>> Maybe I should throw my 2c in here.  When I imagined adding hunk
>> splitting into the tortoisehg commit tool, the dialog I imagined would
>> open a particular hunk in a treeview widget that allows a range of
>> lines to be selected (aka, rubber banding).  The user would then hit
>> 'split' and the tool would try to split the hunk into (at most) three
>> pieces.. the lines before the selection, the selection, and the lines
>> after the selection.  This could just as easily be generalized to
>> split the hunk at each selection/non-selection boundary, but I doubt
>> that resolution of splitting would be needed very often.
>>
>> Maybe it's just me, bit the git style patch editing seems suited only
>> for developers who work with raw patch files all day long.
>
> This patch series and crecord extension both implement hunk splitting, while git and darcs propose hunk editing. So I just wondered what we really want, because I lack of concrete use cases.
>
> I cannot remember using record and saying "argh, I messed up, those changes should not be intermingled, would be great to have hunk splitting!" because when this happens, it means I messed up and I would not trust a simple line filtering to untangle the mess. Instead either I decide it would be too time consuming to fix this mistake and I commit something a bit too large for my taste. Or I take the time and fallback to my $EDITOR and start an editing/compiling/testing cycle again, and filter out one of the changes.
>
> On the other hand, I can remember me saying "argh, there is a (typo in this comment|trailing whitespace), it would be great to fix it right there instead of quitting, fixing in the $EDITOR and recording again". But I would not insist on supporting this workflow either.
>
> So git implementation is hardcore as usual. darcs is nicer and marginally useful to me but I have a vague feeling it will be much less efficient with large hunks, where diffs may be superior to before/after sections.
>
>
> I am not sure how your "rubber band" selection works with hunks. Imagine:
>
> -----------
> @ whatever @
> context
> context
> - line11
> - line12
> + line21
> + line22
> + line23
> context
> context
> -----------
>
> How do I record only:
> -----------
> context
> context
> - line11
> + line12
> + line22
> context
> context
> ------------
> ? (which is a simple "replace one line with two new lines edit)

It probably wouldn't.  The use case I want to handle is when you add
three new functions to a class and only want to commit one of them.
If the new functions are contiguous, they will be in a single hunk.
My UI would allow you to quickly split the hunk into parts for
individual selection/rejection for commit or shelve.

--
Steve Borho