1. 39
  1.  

  2. 21

    Experts, who are deeply familiar with the product, have learned its many intricacies, developed complex, customized workflows, and regularly exploit its most elaborate features, are often defensive and resistant to the suggestion that the design has flaws.

    The paper looks really good from what I’ve read so far, but this somewhat offhand remark is pure gold.

    1. 12

      Gitless has no staging area

      I frequently use git add -p to stage chunks of diffs, so that I can make separate commits of unrelated changes in a single file. I would miss that feature greatly.

      1. 9

        Gitless has a --partial flag that can be used to interactively select segments of a file to commit.

        1. 6

          As durin42 mentioned elsewhere, hg gets arround this (without having a staging area) by having support for interactive commit selection with hg commit --interactive.

          1. 3

            For non-trivial changes, how do you know for sure that your code still compiles afterwards? Is this not a problem in practice?

            1. 7

              For non-trivial changes, I don’t know. But if it gets to the point where I have non-trivial changes in my working copy, I’ve already lost.

              In my experience, a common pattern is:

              • start editing some function
              • realise this function would be easier/safer/simpler with a change to the helper function it’s based on.
              • go off and edit the helper function, write some tests, make sure it’s solid
              • come back and finish the outer function, to make sure that the changes to the helper function actually accomplish the thing I needed
              • git add -p the changes to the helper function and the tests, which I’m confident can stand alone because the existing tests still pass, plus my new ones
              • commit the changes to the outer function

              …times as many stack-levels of yak-shaving as you can stand.

              1. 1

                Once you have made small commits, you can do an interactive rebase to build every version and make edits if necessary. With e.g. Gerrit and Jenkins you can automatically get feedback whether each commit builds/passes tests.

                1. 1

                  You can use git stash -k to stash unstaged changes, run your compiler / test suite, and commit them if they all pass.

                2. 1

                  I think I could make do with their --partial flag, but the lack of git rebase -i is a bit of a deal-breaker for me.

                3. [Comment removed by author]

                  1. 7

                    I do this regularly with hg (using ‘hg commit –interactive’), but I find that the typical user of source control tooling finds the partial commit functionality puzzling. Having it on by default is biasing towards the wrong users in my experience (anecdata is pretty broad from having been the guru for all of svn, git, and hg for varying teams over time.)

                    1. [Comment removed by author]

                  2. 3

                    The paper described in the blog post is linked here: http://people.csail.mit.edu/sperezde/pre-print-oopsla16.pdf

                    1. 3

                      I pointed to the article as an appetizer for the paper ;)