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

Steve Losh steve at stevelosh.com
Tue Jan 5 07:21:40 CST 2010


On Jan 5, 2010, at 4:09 AM, Dirkjan Ochtman wrote:

> On Tue, Jan 5, 2010 at 01:44, Steve Losh <steve at stevelosh.com> wrote:
>> With the current record extension you can't do this because the two  
>> lines are adjacent and so are part of a single hunk.  These patches  
>> attempt to address that situation in an easy-to-use fashion.
>
> Awesome, thanks for working on this!
>
>> A screenshot will probably make this clearer: http://twitpic.com/ 
>> wp8vs
>
> This usage got me a little confused, if only for the fact that the
> example is a little confusing (e.g. you're changing the whitespace in
> two lines, but the intermediate state is that you just remove the
> lines?!?).

Yeah, it's not a real-world example, I just grabbed a README and  
changed a few things to have something to play with.

> That said, first thoughts on what the UI should be, based on what I'm
> seeing here:
>
> - have you looked at darcs, where they have this already, IIRC?

I haven't looked at darcs' solution, just git's -- I should do that.

> - if using the line numbers (which may be non-obvious), why not make
> the line numbers be the lines that get applied? E.g. in your example
> if you say 0 2, it would fix the whitespace in the [usage] line but
> not the [keywords] line. Less indirection, and should make it fairly
> efficient to specify things, though may get unwieldy for large changes
> (ranges could help, e.g. 1-4 will apply lines numbered 1 to 4
> inclusive).

I was aiming more for a way to split patches that you could then apply  
through the normal mechanism.  It might be better to do it the way you  
mentioned.  I'll try it out and see how it feels.

> - don't use line numbers but prompt for every line (also very unwieldy
> for large patches, I guess)

Yeah, if you have a 100-line hunk and just want to commit 2 one-line  
docstring changes, hitting 'n' 98 times would get tedious.

>
> Cheers,
>
> Dirkjan



More information about the Mercurial-devel mailing list