4 ms·

In my opinion, Git added too many moving parts in a poorly-designed way. Commits, the staging area, and stashes all implement the same sort of idea, but interac

In my opinion, Git added too many moving parts in a poorly-designed way. Commits, the staging area, and stashes all implement the same sort of idea, but interact poorly and considerably complicate workflows. Having them is better than not having them, but Git would have been better off if they consolidated into a single idea and concentrated their efforts on that. If you can remove a concept from Git and still support the same workflows equally well, then surely that concept was unnecessary. (Whether the staging area is actually better served by other concepts is a matter of judgment.)

1attice 4y ago
Interesting -- I have the opposite impression, and we're both just simply staring at the same pile of distinctions and disagreeing on whether it 'resembles' the workload. I imagine this will be settled by git steamrolling sapling in the market, but I wonder if there's a faster (and less network-effected) way to adjudicate? Both your position and mine seem lodged in a taste/touch/feel context, which seems like a data-poor place to make good decisions. On the other hand, I'd say that absent sufficient data, one should pick the most flexible tool, which I'll bet in this context is the one with the most moving parts, i.e. git.
- arxanas 4y ago
  We know empirically that the staging area is a major pain point for users in practice, as discussed in https://investigating-archiving-git.gitlab.io/ https://investigating-archiving-git.gitlab.io/ The findings validate the earlier conceptual design analysis in practically all aspects: https://gitless.com/#research https://gitless.com/#research Git doesn't support certain workflows well. For example, how do you split the contents of the staging area into two separate groups? Sapling handles this the same way it handles splitting commits in general. Essentially, it has a greater set of verbs that act on a smaller set of nouns, where Git has a medium set of verbs that act on a medium set of nouns.
  - 1attice 4y ago
    Thanks arxanas! This is great empirical research that definitely takes precedence over any hunch, even my own ;D One of my favourite parts of rationality is simply admitting that the data shows you're wrong
  - sixstringtheory 4y ago
    > how do you split the contents of the staging area into two separate groups What is the workflow behind this ask? I don't understand what the goal is. The basic git workflow: 1. Edit and save a tracked file; the changes appear in the working tree. 2. Select some subset of the changes in the working tree to stage them in the index. 3. Form a commit with the changes in the index. IIUC you want to add a step in between 2 and 3? But the way I see it, 2 is doing what you want. I can split the set of current changes by selectively adding them to the index in preparation for a commit. I can also selectively un-stage changes if I decide I don't want them to become part of the commit. Between the changes to a file in whatever editor buffer I'm writing in, saving those to disk, moving changes from unstaged to staged, and forming a commit in any of a variety of ways (plain ol' commit, amending a commit, a fixup commit) I can't imagine what other way I need to slice and dice changes. Maybe it's just a failure of my imagination since I've been using Git for so long now and only more basic things like SVN/TFS/CVS before that.
    - arxanas 4y ago
      To accomplish your workflow, there doesn't seem to be any need for a staging area at all. You can use an interactive commit selector to stage a subset of changes (or select a set of changes some other way), and then if you want to keep adding/"staging" changes, you can amend the commit you just made. Occasionally, I do run into the situation where I've staged some changes and then realize that I want to start staging another commit first, but don't want to lose the changed I already staged. Unstaging my current changes means I have to remember and select them again later. I could also just commit what I have staged and start staging a new commit (and perhaps reorder the commits later), but that shows that the staging area was unnecessary in the first place, and I could have used commits to accomplish the same workflow without adding a new set of concepts to my VCS.
- alwillis 4y ago
  On the other hand, I'd say that absent sufficient data, one should pick the most flexible tool, which I'll bet in this context is the one with the most moving parts, i.e. git. Outside of the Git fanboy bubble, developers don’t want to have to be version control experts, which once you get past a certain level of Git usage, you have to be, whether you wanted to or not. Especially if your team doesn’t have that person who can get you out of any Git jam you may get yourself into. It will also be much faster to get a new developer up to speed using Sapling than Git. And because it’s Git-compatible, if there’s something super advanced that can only be done using the Git command line, that’s still an option. Telling the intern/junior developer to read the man page for git-log is a non-starter; it’s over 19,000 words! The best thing for the greybeards is they can continue using Git while others use Sapling and commit to the same repo.
  - 1attice 4y ago
    To be fair, if I had a junior dev who couldn't skim a man page of 19 000 words, I would have freestanding concerns about their ability to contribute -- being able to inhale knowledge is a core competency of any engineer. That said, I hear you when you say that most folks (think) they have better uses of their attention. I daresay they're wrong, but it's not my place to dictate terms to anyone's curiosity, my own included!
    - alwillis 4y ago
      Agreed. It wouldn’t be that big a deal except pretty much every important git command is similarly complex for noobies.
fragmede 4y ago
coming from SVN, the biggest thing about is it's distributed nature making everything local and fast. yeah there are a lot of other concepts along with that too, but just being able to work on my laptop, commiting and making branches to my heart's content, without talking to a server until I'm ready for that step was the killer feature for me. SVN branches were this doofy copy procedure that made sense once you drank the Kool aid, but they were so unwieldy compared to git

1attice 4y ago

Interesting -- I have the opposite impression, and we're both just simply staring at the same pile of distinctions and disagreeing on whether it 'resembles' the workload. I imagine this will be settled by git steamrolling sapling in the market, but I wonder if there's a faster (and less network-effected) way to adjudicate? Both your position and mine seem lodged in a taste/touch/feel context, which seems like a data-poor place to make good decisions. On the other hand, I'd say that absent sufficient data, one should pick the most flexible tool, which I'll bet in this context is the one with the most moving parts, i.e. git.

arxanas 4y ago
We know empirically that the staging area is a major pain point for users in practice, as discussed in https://investigating-archiving-git.gitlab.io/ https://investigating-archiving-git.gitlab.io/ The findings validate the earlier conceptual design analysis in practically all aspects: https://gitless.com/#research https://gitless.com/#research Git doesn't support certain workflows well. For example, how do you split the contents of the staging area into two separate groups? Sapling handles this the same way it handles splitting commits in general. Essentially, it has a greater set of verbs that act on a smaller set of nouns, where Git has a medium set of verbs that act on a medium set of nouns.
- 1attice 4y ago
  Thanks arxanas! This is great empirical research that definitely takes precedence over any hunch, even my own ;D One of my favourite parts of rationality is simply admitting that the data shows you're wrong
- sixstringtheory 4y ago
  > how do you split the contents of the staging area into two separate groups What is the workflow behind this ask? I don't understand what the goal is. The basic git workflow: 1. Edit and save a tracked file; the changes appear in the working tree. 2. Select some subset of the changes in the working tree to stage them in the index. 3. Form a commit with the changes in the index. IIUC you want to add a step in between 2 and 3? But the way I see it, 2 is doing what you want. I can split the set of current changes by selectively adding them to the index in preparation for a commit. I can also selectively un-stage changes if I decide I don't want them to become part of the commit. Between the changes to a file in whatever editor buffer I'm writing in, saving those to disk, moving changes from unstaged to staged, and forming a commit in any of a variety of ways (plain ol' commit, amending a commit, a fixup commit) I can't imagine what other way I need to slice and dice changes. Maybe it's just a failure of my imagination since I've been using Git for so long now and only more basic things like SVN/TFS/CVS before that.
  - arxanas 4y ago
    To accomplish your workflow, there doesn't seem to be any need for a staging area at all. You can use an interactive commit selector to stage a subset of changes (or select a set of changes some other way), and then if you want to keep adding/"staging" changes, you can amend the commit you just made. Occasionally, I do run into the situation where I've staged some changes and then realize that I want to start staging another commit first, but don't want to lose the changed I already staged. Unstaging my current changes means I have to remember and select them again later. I could also just commit what I have staged and start staging a new commit (and perhaps reorder the commits later), but that shows that the staging area was unnecessary in the first place, and I could have used commits to accomplish the same workflow without adding a new set of concepts to my VCS.
alwillis 4y ago
On the other hand, I'd say that absent sufficient data, one should pick the most flexible tool, which I'll bet in this context is the one with the most moving parts, i.e. git. Outside of the Git fanboy bubble, developers don’t want to have to be version control experts, which once you get past a certain level of Git usage, you have to be, whether you wanted to or not. Especially if your team doesn’t have that person who can get you out of any Git jam you may get yourself into. It will also be much faster to get a new developer up to speed using Sapling than Git. And because it’s Git-compatible, if there’s something super advanced that can only be done using the Git command line, that’s still an option. Telling the intern/junior developer to read the man page for git-log is a non-starter; it’s over 19,000 words! The best thing for the greybeards is they can continue using Git while others use Sapling and commit to the same repo.
- 1attice 4y ago
  To be fair, if I had a junior dev who couldn't skim a man page of 19 000 words, I would have freestanding concerns about their ability to contribute -- being able to inhale knowledge is a core competency of any engineer. That said, I hear you when you say that most folks (think) they have better uses of their attention. I daresay they're wrong, but it's not my place to dictate terms to anyone's curiosity, my own included!
  - alwillis 4y ago
    Agreed. It wouldn’t be that big a deal except pretty much every important git command is similarly complex for noobies.

fragmede 4y ago

coming from SVN, the biggest thing about is it's distributed nature making everything local and fast. yeah there are a lot of other concepts along with that too, but just being able to work on my laptop, commiting and making branches to my heart's content, without talking to a server until I'm ready for that step was the killer feature for me. SVN branches were this doofy copy procedure that made sense once you drank the Kool aid, but they were so unwieldy compared to git