[reactordev]

Funny because `git pull` is an abstraction like you talk about. It's a `git fetch` followed by a `git rebase`. Staging or `stashing`, it's all just leaves on the merkle tree. The concept of time/branches/doesn't exist. Only previous hash, current hash. It's simple and people have ADDED complexity to make sense of it (coming from other VCS').

[computerdork]

True, the pull command is simple. But it's really the pushing and merging that cause the problems.

And, yeah, don't know if i'd call it simple in the way you're using the word. It's simple in that the tool is very "RISC" in nature instead of CISC, doing smaller simple operations instead of larger more complex ones (except for a few exceptions like pull). But for procedures like pushing your code, it's complex. You have to do a lot of things yourself that other VCS take care of. As you probably are aware of, you need to make sure you do things in the correct order, because the tool won't help you if you make a mistake. Don't think something like source control should be this way (especially when other VCS's don't require this amount of thought).

Just my two cents.

[reactordev]

My counter argument is “what is the right order?” And you’ll say “the way work gets done” (paraphrasing) but then I’ll say “that’s exactly how git came to be”.

You are right that it gives you more options and more ways to footgun yourself but that mostly came after the fact. It does need a simplicity wrapper or some better defaults.

[computerdork]

Yeah, hopefully, someday someone will write a really good one that becomes universal used.