[PATCH 2 of 2] record: allow splitting of hunks by manually editing patches
Angel Ezquerra Moreu
angel.ezquerra at gmail.com
Tue Feb 21 03:08:43 CST 2012
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'd be great to
have this capability in TortoiseHg, for example.
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?
More information about the Mercurial-devel