[PATCH 2 of 2] record: allow splitting of hunks by manually editing patches

[A. S. Budden]

On 21 February 2012 09:08, Angel Ezquerra Moreu
<angel.ezquerra at gmail.com> wrote:
> On Mon, Feb 20, 2012 at 2:30 PM, A. S. Budden <abudden at gmail.com> wrote:
>> # HG changeset patch
>> # User A. S. Budden <abudden at gmail.com>
>> # Date 1329683565 0
>> # Node ID 58f3e35efe716309e64bf498f44ffb0117554aad
>> # Parent  ea6086ad210db327591965ad58f9e656313ce2fe
>> record: allow splitting of hunks by manually editing patches
>>
>> It is possible that unrelated changes in a file are on sequential lines.  The
>> current record extension does not allow these to be committed independently;
>> this patch is intended to overcome that limitation.
>>
>> In order to take control over which lines in the hunk are applied, an editor is
>> opened with a single-hunk patch.  Instructions on how to edit the patch are
>> included with the patch (this follows Git's method of doing things).  Although
>> patch editing sounds complicated, in practice, editing is actually very simple
>> as all the user needs to do is either replace the '-' at the start of line with
>> a space or delete lines starting with a '+' (this is explained in the
>> instructions).  Given how rarely I'd expect this to be used in general, I felt
>> that this was an acceptable level of complexity.
>>
>> An example use case for this is in software development for deeply embedded
>> real-time systems.  In these environments, it is not always possible to use a
>> debugger (due to time-constraints) and hence inline UART-based printing is
>> often used.  When fixing a bug in a module, it is often convenient to add a
>> large number of 'printf's (linked to the UART via a custom fputc) to the module
>> in order to work out what is going wrong.  printf is a very slow function (and
>> also variadic so somewhat frowned upon by the MISRA standard) and hence it is
>> highly undesirable to commit these lines to the repository.  If only a partial
>> fix is implemented, however, it is desirable to commit the fix without deleting
>> all of the printf lines.  A partial commit also simplifies removal of the
>> printf lines as once the final fix is committed, 'hg revert' does the rest.  It
>> is likely that the printf lines will be very near the actual fix, so being able
>> to split the hunk is very useful in this case.
>>
>> There were two alternatives I considered for the user interface.  One was to
>> manually edit the patch, the other to allow a hunk to be split into individual
>> lines for consideration.  The latter option would require a significant
>> refactor of the record module and is less flexible.  While the former is
>> potentially more complicated to use, this is a feature that is likely to only
>> be used in certain exceptional cases (such as the use case proposed above) and
>> hence I felt that the complexity would not be a considerable issue.
>>
>> In my opinion, this is a valuable addition to Mercurial: Git can do this and I
>> often find myself using Git on some projects for this feature alone.  However,
>> I dislike the way that the partial commit is essentially the default way of
>> committing in Git and I feel that it should be available for exceptional
>> circumstances but not the default behaviour; this is one of the reasons I'd
>> rather use Mercurial.
>>
>
> I guess that a similar thing could be done with a UI?

I really really really hope so!  Git GUI does this quite well.

> I'd be great to have this capability in TortoiseHg, for example.

I think it's in the feature requests for TortoiseHG somewhere if
memory serves me correctly.  The old GTK version supported record
(hunk-by-hunk only) and there's something on the bug tracker
discussing re-adding that.  In amongst the comments is discussion of
line-by-line operation.

> Please forgive my ignorance, but could you please give a bit more
> details about how it works? In particular, if you were to manually
> edit an unapplied mq patch file _without_ your extension, in order to
> split a hunk in two, how would you do it? Does the diff format allow
> having two patches whose context overlaps?

Actual editing of diffs can be quite a risky process.  You could
certainly do it manually in an unapplied mq patch, but you're likely
to have to mess around with recountdiff and the like to try to get it
to work well (I've had very mixed results with this).  All that is
required with this patch is the removal of lines starting with '+'
signs and the replacement of '-' signs with space.  You can do more if
you choose, but then you run the risk of the patch not applying
cleanly (this is explained in the comment added to the patch).
There's an example of the Git implementation (on which I based this)
in footnote 1 of http://mercurial.selenic.com/wiki/RecordExtension

I've no idea whether the diff format allows having two patches whose
context overlaps.

Does that answer your questions or have I missed the point?

Al