1. 18
  1.  

  2. 10

    Looks interesting but FWIW I think Magit is really nice for this (among other things) so I personally probably won’t switch, but maybe it’ll be useful for people who don’t use Emacs. It’s also good to know that there’s an equivalent for Mercurial, ‘cause I miss Magit when I work on Mercurial repositories.

    1. 3

      agree with @0, magit is much better :)

      1. 2

        Magit is good for Emacs users or people who prefer doing all things in their editor of choice. I prefer using my editor (which is vim, by the way) for editing things, and committing/diffing/etc from the command line.

        There’s tig, but I personally find it much less intuitive than crecord.

    2. 8

      For those curious, git has similar built-ins but nothing that allows for staging/unstaging all in 1 command. The corresponding commands:

      # Stage hunks in patch mode
      # DEV: Patch mode is REPL to add/skip/navigate hunks
      git add -p
      
      # Unstage hunks in patch mode
      git reset -p
      
      # Commit hunks in patch mode (TIL this exists)
      git commit -p
      
      # Bonus: Stash hunks in patch mode
      git stash -p
      
      1. 4

        I wouldn’t say core Git has similar built-ins. Sure, you can do interactive selection (and editing) of hunks to commit/stage/unstage/stash, but that is not Crecord’s innovation: Mercurial and Git both already had Commit this? [yes/no/etc]?-style interactive selection when crecord was created. Crecord’s innovation is its interface. Here, have all three interfaces (crecord, old-style-Mercurial, old-and-current-style Git) side-by-side.

        NB: Please don’t interpret this as ‘nobody else has done this / done this first’. Others have mentioned Magit, f.ex. I merely say crecord is an improvement over core Git’s hunk selection interface. It was an improvement over core Mercurial’s hunk selection interface, too – so much so that it is now in core.

        Crecord. Plain text doesn’t do it justice, go look at the screenshot.

        # git crecord
        # hg commit -i / --interactive
        SELECT CHUNKS: (j/k/up/dn/PgUp/PgDn) move cursor; (space/A) toggle hunk/all; (e)dit hunk;
         (f)old/unfold; (c)onfirm applied; (q)uit; (?) help | [X]=hunk applied **=folded, toggle [a]mend mode
        
        [x]    diff --git a/a b/myfile
               1 hunks, 2 lines changed
        
           [x]     @@ -0,0 +1,2 @@
              [x]  +fishfingers
              [x]  +custard
        

        Mercurial, prior to 3.4 (2015-05-01) – that’s when crecord was moved into core.

        # hg commit -i / --interactive
        diff --git a/myfile b/myfile
        1 hunks, 2 lines changed
        examine changes to 'myfile'? [Ynesfdaq?]
        
        @@ -0,0 +1,2 @@
        +fishfingers
        +custard
        record this change to 'myfile'? [Ynesfdaq?]
        

        Git

        # git commit -p / --patch
        diff --git a/myfile b/myfile
        index e69de29..de98044 100644
        --- a/myfile
        +++ b/myfile
        @@ -0,0 +1,2 @@
        +fishfingers
        +custard
        Stage this hunk [y,n,q,a,d,/,e,?]?
        
        1. 2

          Yep. totally. The interface is much slicker than text based navigation. My comment was to inform people that might not know git had interactive modes for its commands

      2. 4
        1. 2

          See also git add -i.

          1. 2

            Correct me if I’m wrong, but weren’t the crecord/record extensions and the --interactive option for hg commit originally intended to simulate Git’s staging area? The design was derived, IIRC, from darcs, but the intention was to essentially allow users to select which parts of the changes should be included in the next commit (which Git’s index does).

            1. 5

              Right, this is a nice curses interface for that, which git lacks. Think of this as a way nicer “git add -p”.

            2. 1

              I really like git gui.
              There are two things I would change though:
              Fix the weird GUI, control focus changes inexplicably after staging changes, ong other issues.
              Either change the text view to be editable before staging, or add a button to launch meld with “HEAD”, “ My changes” and “My changes that are really about to be staged and I can make slight adjustments such as removing an extra new line”. I need this as I often find myself alt tabbing back to my editor, fixing something and then refreshing in git gui Another option would be a “ Open this document in your editor” button.

              1. 1

                I really dislike git gui. Probably because I used TortoiseHg for Mercurial, which is better than anything else I’ve seen so far. But it’s hg only.

                1. 1

                  There is TortoiseSVN and TortoiseGit as well and yes, they are definitely better than git gui.

                  I should have said “On Linux git gui is good enough, it does hide the implementation details and advanced features, but it mostly keeps beginners like me productive and unconfused” :)

                  1. 1

                    Well, I know there’s TortoiseGit, but it’s a direct port of TortoiseSVN which I find not nearly as good as TortoiseHg, which in fact is a totally unrelated tool, sharing only a bit of the name. Of course, things like this:

                    https://tortoisegit.org/docs/tortoisegit/images/RevisionGraph.png or this:

                    https://tortoisegit.org/docs/tortoisegit/images/ContextMenuDirControl.png

                    are better than nothing, but still, compared to

                    http://tortoisehg.bitbucket.org/img/vt_history.png

                    I find them pretty ugly.

                    1. 1

                      Gitg/gitk/git-cola all look more like the 3rd one for showing history at least.

                      To use TortoiseSVN/Git without going mental bananas you really have to customise the menu by adding the power user items that are actually very useful and then removing all the random rubbish that no one ever uses. They could both really do with some saner defaults :)

                      I didn’t realise TortoiseHg was that different to TortoiseSVN/Git.