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.
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.
git add -p
Gitless has a --partial flag that can be used to interactively select segments of a file to commit.
As durin42 mentioned elsewhere, hg gets arround this (without having a staging area) by having support for interactive commit selection with hg commit --interactive.
hg commit --interactive
For non-trivial changes, how do you know for sure that your code still compiles afterwards? Is this not a problem in practice?
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:
…times as many stack-levels of yak-shaving as you can stand.
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.
You can use git stash -k to stash unstaged changes, run your compiler / test suite, and commit them if they all pass.
git stash -k
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.
git rebase -i
[Comment removed by author]
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.)
note /u/nwjsmith’s comment
The paper described in the blog post is linked here: http://people.csail.mit.edu/sperezde/pre-print-oopsla16.pdf
I pointed to the article as an appetizer for the paper ;)