Differences between revisions 32 and 33
Revision 32 as of 2012-10-19 18:23:21
Size: 5435
Editor: 192
Comment:
Revision 33 as of 2012-10-25 15:03:41
Size: 5448
Editor: broadband-77-37-228-65
Comment: Fixed comments: comments from different authors appear to be joined.
Deletions are marked like this. Additions are marked like this.
Line 64: Line 64:
 . Yes, this feature of {{{darcs record}}} is missing. It would be great to have it. As described below, git does have it - using the '''e''' option to open an editor, like in darcs. However, I like the darcs approach, with a "before" and "after" section, better than the git approach of editing "+" and "-" markers. I find it cleaner. --YitzGale fyi: this has been available for some time with the CrecordExtension (based on RecordExtension), so maybe it wouldn't be too hard to incorporate some of the changes back into record. --MarkEdgington
  . crecord uses a curses interface, but record uses merely command line. so it's not very easy to specify how to split the hunks in record. Besides, crecord provides line-level granularity, which in most case is sufficient. But in some edge cases, we may have two changes doing different things in ''one'' line. The best practice I can think of right now is git's approach (manually editing the patch) explained above. --WeakishJiang I find crecord to be really clunky when dealing with sizable patches. It's slow, and requires me to scroll a lot unnecessarily. In addition to the (decent) interface in [1], git also has a powerful "interactive" interface. It's not user-friendly, but once you figure it out, it's much more efficient than crecord, and much more powerful than record. --JustinLebar
  . . I think going more for git add --interactive works great. you can edit patches, and you can split which just breaks the hunk into smaller parts. Once split makes it as small as you want you can edit manually to break it apart how you want. Also git's interactive add also lets you see the diff so far and manually select which files you want to do this with. It's not the simplest interface but it is very powerful. --JacobKeller
 . Yes, this feature of {{{darcs record}}} is missing. It would be great to have it. As described below, git does have it - using the '''e''' option to open an editor, like in darcs. However, I like the darcs approach, with a "before" and "after" section, better than the git approach of editing "+" and "-" markers. I find it cleaner. --YitzGale
   .
fyi: this has been available for some time with the CrecordExtension (based on RecordExtension), so maybe it wouldn't be too hard to incorporate some of the changes back into record. --MarkEdgington
     . crecord uses a curses interface, but record uses merely command line. so it's not very easy to specify how to split the hunks in record. Besides, crecord provides line-level granularity, which in most case is sufficient. But in some edge cases, we may have two changes doing different things in ''one'' line. The best practice I can think of right now is git's approach (manually editing the patch) explained above. --WeakishJiang
     .
I find crecord to be really clunky when dealing with sizable patches. It's slow, and requires me to scroll a lot unnecessarily. In addition to the (decent) interface in [1], git also has a powerful "interactive" interface. It's not user-friendly, but once you figure it out, it's much more efficient than crecord, and much more powerful than record. --JustinLebar
   . I think going more for git add --interactive works great. you can edit patches, and you can split which just breaks the hunk into smaller parts. Once split makes it as small as you want you can edit manually to break it apart how you want. Also git's interactive add also lets you see the diff so far and manually select which files you want to do this with. It's not the simplest interface but it is very powerful. --JacobKeller

Record Extension

This extension is distributed with Mercurial.

Author: Bryan O'Sullivan

1. Overview

The record extension provides the record command, which may be used in lieu of commit. This command lets you choose which parts of the changes in a working directory you'd like to commit, at the granularity of patch hunks. It is similar in spirit to the darcs record command.

The record extension also provides the qrecord command, if MqExtension is enabled.

2. Configuration

Configure your .hgrc to enable the extension by adding following lines:

[extensions]
record=

3. Usage

hg record [OPTION]... [FILE]...

The option to examine changes is offered for each one of the selected files (or all the modified files if none is provided):

$ hg record my_dir/my_file.ext
examine changes to 'my_dir/my_file.ext'? [Ynsfdaq?]

where the following responses are possible:

    y - record this change
    n - skip this change

    s - skip remaining changes to this file
    f - record remaining changes to this file

    d - done, skip remaining changes and files
    a - record all changes to all remaining files
    q - quit, recording no changes

    ? - display help

If y is selected, then each of the patch hunks for the file are offered for acceptance or rejection:

@@ -164,5 +164,5 @@
                                     #nice comment
                                     ])
     elif options.action:
-        print >>sys.stderr, "wrong action"
+        print >>sys.stderr, ";wrong action"
     else:
record this change to 'my_dir/my_file.ext'? [Ynsfdaq?]

where the previous options can be used with the same meaning.

After file and hunk selection is finished, a normal commit is recorded.

Feature Request: I would really like to have the ability to split hunks in this plugin. The problem is, that if there are multiple adjacent changes that have nothing to do with each other (like two new functions right next to each other) it is downright hard to commit them separately short of removing one, comitting and adding the other one again. --MartinHäcker

  • Me too. git has this handy feature. --LesliePolzer

    • How does git do this? --ThurnerRupert

      • When using git add -p, you will enter the interactive mode, and do something similar with darcs|hg record. But in git you've the choice of 'e' to open up an editor, and edit the patch. There is an example[1] at the footer of this page. --WeakishJiang

  • Yes, this feature of darcs record is missing. It would be great to have it. As described below, git does have it - using the e option to open an editor, like in darcs. However, I like the darcs approach, with a "before" and "after" section, better than the git approach of editing "+" and "-" markers. I find it cleaner. --YitzGale

    • fyi: this has been available for some time with the CrecordExtension (based on RecordExtension), so maybe it wouldn't be too hard to incorporate some of the changes back into record. --MarkEdgington

      • crecord uses a curses interface, but record uses merely command line. so it's not very easy to specify how to split the hunks in record. Besides, crecord provides line-level granularity, which in most case is sufficient. But in some edge cases, we may have two changes doing different things in one line. The best practice I can think of right now is git's approach (manually editing the patch) explained above. --WeakishJiang

      • I find crecord to be really clunky when dealing with sizable patches. It's slow, and requires me to scroll a lot unnecessarily. In addition to the (decent) interface in [1], git also has a powerful "interactive" interface. It's not user-friendly, but once you figure it out, it's much more efficient than crecord, and much more powerful than record. --JustinLebar

    • I think going more for git add --interactive works great. you can edit patches, and you can split which just breaks the hunk into smaller parts. Once split makes it as small as you want you can edit manually to break it apart how you want. Also git's interactive add also lets you see the diff so far and manually select which files you want to do this with. It's not the simplest interface but it is very powerful. --JacobKeller


Footnotes:

[1] a git example:

   1 $ git add -p f.c
   2 diff --git a/f.c b/f.c
   3 index a32488e..cf4b43e 100644
   4 --- a/f.c
   5 +++ b/f.c
   6 @@ -1,2 +1,4 @@
   7 -void splodge(int c) {
   8 +int blorf() { return s_blorfulocity / s_RAT; }
   9 +
  10 +void splodge(long c) {
  11  }
  12 Stage this hunk [y/n/a/d/e/?]? e
  13 
  14 4) External editor opens up with this content
  15 # Manual hunk edit mode -- see bottom for a quick guide
  16 @@ -1,2 +1,4 @@
  17 -void splodge(int c) {
  18 +int blorf() { return s_blorfulocity / s_RAT; }
  19 +
  20 +void splodge(long c) {
  21  }
  22 # ---
  23 # To remove '-' lines, make them ' ' lines (context).
  24 # To remove '+' lines, delete them.
  25 # Lines starting with # will be removed.
  26 #
  27 # If the patch applies cleanly, the edited hunk will immediately be
  28 # marked for staging. If it does not apply cleanly, you will be given
  29 # an opportunity to edit again. If all lines of the hunk are removed,
  30 # then the edit is aborted and the hunk is left unchanged.


CategoryBundledExtension

RecordExtension (last edited 2016-03-28 19:59:08 by Pierre-YvesDavid)