phillip.wood123@xxxxxxxxx writes: >> "Ah, here is a big hunk with 10 changes, most of which I like, but >> one of the lines I do not want to include" in which case I may do >> the "Add the hunk to grab 10 changes, visit that decided-to-be-used >> hunk, split, and then visit the one minihunk that I want to eject >> and say 'n'". This makes the workflow simpler and more stupid by >> requiring the 9 minihunks to be chosen individually after splitting. > > If the user wants to deselect the 10th mini-hunk then they have to > wade through them all with or without this patch. If they want to > deselect an earlier one then they will now have to do more work. Or directly jump to it with "/go-to-the-one-with-this-string"? > Currently after a selected hunk is split we always prompt the user to > make a decision on the first mini-hunk even though it is marked as > selected when it is split. This seems inconsistent and confused me > when I first tried splitting a selected hunk which is why I wrote this > patch. Hmph, so there is an obvious alternative "fix" to the inconsistency, i.e., after splitting, move to the first unselected hunk? > I can see that in some circumstances this patch does make more > work for the user, but I do think it makes it easier to understand > what happens when hunk is split. And the alternative may resolve the inconsistency and make it less work for the users? I dunno. This is totally orthogonal to this "split" issue and outside the scope of this topic, but one thing that I do not like the design of "add -p", which most likely was inherited from the very initial iteration before it was rewritten in C, is that we never ask reconfirmation once all the hunks got decided. With 3 hunks, after choosing hunk #1 by mistake, I can still go back and correct the mistake even if I noticed the mistake after making decision on the hunk #2 (thanks to the fact that hunk #3 hasn't been decided), but if the hunk #3 is missing, going back and correcting #1 becomes impossible as the program exits immediatly after deciding on #2. But I guess this depends not just on the user but on occasion. After all, re-running "reset/add -p" after such a mistake is not so huge a deal anyway. Thanks.
