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

[Patrick Mézard]

Le 05/01/10 10:09, Dirkjan Ochtman a écrit :
> 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?!?).
> 
> 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?
> - 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).
> - don't use line numbers but prompt for every line (also very unwieldy
> for large patches, I guess)

Here is how it works in git and darcs:

git
---

git displays the hunk and let the user edit it like:

------------------
# Manual hunk edit mode -- see bottom for a quick guide
@@ -1,9 +1,9 @@
 a
 b
 c
-d
-f
-f
+dx
+fx
+fx
 f
 f
 f
# ---
# To remove '-' lines, make them ' ' lines (context).
# To remove '+' lines, delete them.
# Lines starting with # will be removed.
#
# If the patch applies cleanly, the edited hunk will immediately be
# marked for staging. If it does not apply cleanly, you will be given
# an opportunity to edit again. If all lines of the hunk are removed,
# then the edit is aborted and the hunk is left unchanged.
-------------------

If context lines are edited and the hunk fails to apply, git prompts again with the previously edited hunk. What's hard is the displayed hunk cannot be applied unless conflicting changes are correctly reverted, which does not seem easy to do without having the original lines available.


darcs
-----

darcs is smarter and present the hunk in the following way:



-------------------
Interactive hunk edit:
 - Edit the first set of lines to insert a new change before the current one.
 - Edit the second set of lines to insert a new change after the current one.
===
d
f
f
===
dx
fx
fx
===
-------------------

Once the first and second set have been edited into first_edited and second_edited, darcs present the following hunks:
- diff(first, first_edited)
- diff(first_edited, second_edited)
- diff(second_edited, second)

The common case (editing only second) giving:

- diff(first, second_edited)
- diff(second_edited, second)

I find displaying the last diff (equivalent to leftover changes) confusing and people on #darcs are not completely sure this is the right way to do it. I am not exactly sure what the use of editing "first", seems to be a darcs habit letting people tidy up patches, and I was told editing both "first" and "second" is probably useless.

But the compelling part is it let people edit changes like in git while accepting context lines changes

--
Patrick Mézard