←back to thread

94 points vincent_s | 1 comments | | HN request time: 0s | source
Show context
donatj ◴[] No.40914710[source]
One of the bigger things I try to hammer in to a junior developers mind is to be conscious and thoughtful about their individual commits. To basically never just "git add ." whatever might just happen to be different in their work area, but to ALWAYS review the diff and make the commit a logical collection of changes.

With the lack of staging area it really seems like this encourages the exact opposite. Seems like a good way to get secrets as well as just general junk and clutter committed to your repo history.

If I am working on a big project, I will start to commit change sets as parts of the code solidify without committing other less solid changes. That seems pretty basic. I don't want half finished changes forever committed to history.

replies(6): >>40914953 #>>40915330 #>>40915843 #>>40916939 #>>40919543 #>>40920358 #
1. aseipp ◴[] No.40916939[source]
There isn't an "explicit" staging area in the sense it's a separate semantic concept that is distinct from a "commit"; rather, the provided machinery for working with commits can be used to do all the things you do with the staging area. The staging area is subsumed as a concept by another concept. By the same token, it also subsumes the stash too. In other words, you can do all the same workflows you do now, but there are fewer "nouns" to juggle. In Git there's the working copy, staging area, and commits. In Jujutsu, there are only commits, and commits are used in more generalized ways with more generalized operations.

To put it another way: the staging area is great because it's really easy to manipulate and "chop it up" as you like. If you make commits themselves really easy to manipulate, just as easy as the staging area, then you can just get rid of the staging area and use commits instead i.e. split a commit in two, or squash two commits together, or parallelize them or reorder them, etc. This actually means that many workflows in Jujutsu are more open ended and flexible than the Git equivalents, while simultaneously having less nouns (which means that, for example, there are fewer UX irregularities because there's less surface area.)

The README that Martin mentions first says there's "no staging area", but then a few paragraphs later mentions that the working copy concept subsumes it and so it provides a superset of functionality. That should probably be rewritten.