5 ms·

Despite the greytexting of this comment, I'm still really interested in the discussion around it -- and I'm really curious to hear from people that have the opp

Despite the greytexting of this comment, I'm still really interested in the discussion around it -- and I'm really curious to hear from people that have the opposite experience. Moving from SVN to git felt like liberation because there were suddenly idiomatic ways of expressing states that were sort of smushed together by SVN -- stuff like, "I have some changes in my branch I want to line up for commit" which, became the handy one-word concept, "staging". The before-times were marked by a lack of these fine distinctions. While they existed in fact, they were obscured in-system. Like a map, any tool should 'resemble' the sphere of human activity it potentiates, and git resembles our diverse workflows better because it has so many asinine distinctions. This was always its strength, and indeed, likely the reason the platform is called 'git' in the first place, as 'smarmy git' (English idiom for 'smartass') implies an insufferable drawer-of-distinctions. And like a smarmy git, it's easier to complain about git than it is to replace it.

arxanas 4y ago
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.
      - 4y ago
- 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

arxanas 4y ago

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.
    - 4y ago
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