undefined | Better HN

0 pointsarxanas3y ago0 comments

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.)

0 comments

7 comments · 2 top-level

1attice3y ago· 5 in thread

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.

arxanasOP3y 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/

The findings validate the earlier conceptual design analysis in practically all aspects: 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.

1attice3y 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

sixstringtheory3y 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.

1 more reply

alwillis3y 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.

1attice3y 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!

1 more reply

fragmede3y 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

j / k navigate · click thread line to collapse

0 comments

7 comments · 2 top-level

1attice3y ago· 5 in thread

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.

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.

arxanasOP3y 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/

The findings validate the earlier conceptual design analysis in practically all aspects: https://gitless.com/#research

1attice3y 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

sixstringtheory3y 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.

1 more reply

alwillis3y 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.

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.

1attice3y ago

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!

1 more reply

fragmede3y ago

SVN branches were this doofy copy procedure that made sense once you drank the Kool aid, but they were so unwieldy compared to git

j / k navigate · click thread line to collapse