1. 16

This particular use case: (“It is tempting to make sweeping changes and clean up lots of code while implementing a small new feature, however, it’s also good practice to separate commits that don’t include any unrelated changes.”) is great. However, it requires discipline to remember what changes pertain to what.

It’s almost as if I want an editor where you can tag your edits as you do them and then collect edits related to one tag into a commit.


  2. 9

    This is one of the most compelling features of magit, and what made me actually use it over the git cli.

    M-x magit-status launches a window that contains all your staged and unstaged code, and you can highlight individual lines of the diff to remove or add them to your staged changes. It also includes a stash UI as well.

    1. 6

      God yes, that and +/- to expand/decrease where the hunks start (be careful getting it too close to one line). s/u to stage/unstage things (can even do this if you highlight stashed hunk as well, soooo nice).

      It really is the best git ui i’ve used.

      1. 5

        Funny you should mention magit. So, I’m learning Common Lisp, and I was using Atom + Slime. Then I got really annoyed by Atom (I’m sure I could have reconfigured it given some study, but the Slime integration started to get wonky too). I took the plunge and have started using emacs (which isn’t that bad, once I figure out what M-x meant :P) Then I read a thread on HN about altassian buying trello (comments are hillarious) but ran into magit, and learning about magit I learned about hunks which seems to me one of those things about git that should be advertised more prominently.

        1. 2

          magit is really well done… shows the power of emacs customization.

        2. 4

          Or use @andrewshadura’s git-crecord.

          I do this workflow all the time using mercurial, trying to keep my commits as atomic as possible.

          1. 4

            I remember the first time I needed to stage split chunks of a file and thought “I wonder if I can just highlight these lines and hit s… I can!” Bravo magit devs.

            1. 2

              For years, magit was the only piece of emacs that I kept on using. It is great.

            2. 8

              When I need to break up a big changeset into several commits, my workflow usually looks something like this:

              git add -p   # stage relevant chunks
              git stash -k # stash all non-staged chunks
              ...          # run tests, verify nothing is broken or forgotten
              git commit

              That ability to stash non-staged chunks was a game-changer for the way I use git add -p.

              1. 8

                I tend to use git add -p even when I don’t want to break things up into different commits, it’s very convenient that you don’t need to type any of the file paths you changed, and at the same time you get a nice refresher of your code before you write a commit message <3 git being so undiscoverable means that I think it’s easy to miss great features like this!

                Also: was pleasantly surprised when I learned that the flag is supported (and super useful with) a bunch of other git commands also! eg:

                git stash -p

                git reset -p

                git checkout -p

                1. 4

                  One more: git commit -p which does the same as git add -p but will allow you to directly create the commit once you went through all changes.

                  1. 2

                    awesome! love talking about git because I always learn something. (Will probably use this every day)

                2. 4

                  You can also do this interactively in a GUI with git-gui (unless you abhor TCL/TK), or in a console with tig.

                  I ssh into my dev machine (long story), so gitk + git-gui over sshfs is kind of cumbersome (things take noticeably longer). Moreover, switching between the console and a mouse driven GUI program isn’t very effective, even with a tiling manager.

                  Then I found tig and got used to it, and replaced gitk+git-gui with it. LOVE IT. I bound it to a key in vim, and I bring it up and close it as needed; it even uses most of the same keys as vim. Since I have a screen window for each repo I work with, I don’t even need a different screen window for tig; it’s all in that window.

                  Everything just fits, and I can do git operations a lot faster than in bash (even knowing most history and completion shortcuts).

                  I HIGHLY recommend tig.

                  1. 3

                    What brought me into the version control lifestyle is the idea that a VCS almost forces you to make smaller, more focused commits that you have to give a reason for existing. Over time, this has made editing code easier as I have clear paths for what I’m doing and where I’m going.

                    I couldn’t imagine making multiple types of changes at the same time and then retroactively making different commits for each one of them.