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

[Dan Villiom Podlaski Christiansen]

On 5 Jan 2010, at 14:33, Steve Losh wrote:

>> When I first looked at the screenshot, I read it to already work that way :) I agree that line numbers and ranges should be counted from one and interpreted inclusively. Also, it might be worthwhile to increment numbers for consecutive hunks.
> 
> The way it works is each line number you specify is the start of a new hunk.  So saying "(0) 1 4" means: "split this hunk into three new hunks, one starting at line 0, one starting at line 1, and one starting at line 4".  You then get prompted as normal for each of these new hunks (which you could then split again, of course).
> 
> Dirkjan's idea of combining the splitting and recording into one step is interesting, and I want to play with that to see how it works out.

The current interface seems very complicated to me, but I look forward to the results from trying Dirkjan's proposal :)

> I'm not sure what the benefit is to incrementing numbers for later hunks.  You'll need to look at them each time anyway, and if you have a lot of hunks the numbers could get pretty large.  Also, you probably won't be splitting each and every hunk anyway (many will be applied with 'y' or skipped with 'n') so there would be large gaps in the numbers you do see.

Good point!

> I'm not sure I'm completely following, but I think I get the general idea.
> 
> I think extra modes might be overkill.  In the case where you want to just record one line of a three-line hunk (probably the common case) all you would have to do with Dirkjan's option is press the line number and hit return.  That's less work than hitting 'nyn<return>', and the user wouldn't have to learn a new UI to handle the more complicated cases.

The motivation was that these modes, despite being new, would appear similar to the rest of the interface. But you're right; they could indeed lead to an awful lot of keystrokes…

--

Dan Villiom Podlaski Christiansen
danchr at gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1943 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100105/a4e13263/attachment.bin>