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

[Steve Borho]

On Sun, Jan 24, 2010 at 3:07 PM, Steve Losh <steve at stevelosh.com> wrote:
> On Jan 24, 2010, at 3:57 PM, Steve Borho wrote:
>
>> 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.
>
> After you "rubber band" a bunch of lines, you then see each new hunk individually and get the chance to commit it (or split again), right?
>
> What if you added four functions and want to commit the first and third?  It seem like you'd have to do this:
>
>        * Select the Split command.
>        * "Rubber-band" the first function.
>        * Now you're looking at a patch that adds the first function.  Select Yes to commit it.
>        * Now you're looking at a patch with the last three.  Select Split again.
>        * "Rubber-band" the third function.
>        * You're at a patch containing f2, select No.
>        * You're at a patch containing f3, select Yes.
>        * You're at a patch containing f4, select No.
>
> Is there any reason that Dirkjan's "Select the lines of this patch you want to commit" wouldn't work for this, and be much faster to use?  You'd just input all the lines you want to commit at once -- like "14-32 78-101", for example.

The commit tool already has hunk level selection. so all the split
dialog does is break larger hunks into pieces that can be toggled
separately.  If we only offered simple rubber band selection, it would
take two passes.

* rubber band the first function, hit split
* select the remaining hunk, rubber band the third function, hit split
* toggle off the hunks you don't want committed, hit commit

But as I said, the dialog could allow the user to select the first and
third functions in one pass, with little extra code (just added UI
complexity).

Selecting all the lines you want to commit up front is much more work
if you have multiple files to cherry pick from, or if most of the
hunks you want to select do not need splitting.  I use hunk selection
cherry picking fairly often, and I regret not having hunk splitting
maybe once a month.

There are different considerations between a CLI and a GUI commit
tool, however.  Explicit line number selection is probably the best
way to handle this on the command line.

--
Steve Borho