5 ms·

Disagree that git is hard to use. It's fairly complex, I'll admit, however it's pretty much all "necessary complexity". Occasionally, I'll see articles talk ab

Disagree that git is hard to use. It's fairly complex, I'll admit, however it's pretty much all "necessary complexity". Occasionally, I'll see articles talk about "fixing" git by eg. removing the staging area, or something like that... but the staging area is great! It's literally a feature I was dreaming about when I used Mercurial. I definitely think there's room for a more intuitive solution. I would rate the git learning curve as "medium-easy"

guytv 4y ago
Just the ergonomics of git are sometimes mind-boggling. for instance: "git checkout" is used for 3 different things: “switch”, “create branch”, and “revert a file”. Deleting a remote tag is “git push” but a deleting a local one is “git tag -d”. There are many such examples
- jwilk 4y ago
  > "git checkout" can is used for 3 different things: “switch”, “create branch”, and “revert a file” Git v2.23 (released in August 2019) added "git switch" and "git restore" commands to straighten this up.
- chociej 4y ago
  IMO push is quite coherent since it consistently updates remote refs. The variation in checkout is pretty bad though.
  - 988747 4y ago
    The perfect command for deleting remote tag would be "tag -d(elete) -r(emote) <tag>" The existence of "remote refs" is an implementation detail, and git bothers you with it unnecessarily. And if you really need a command to update all remote refs at once why not call it "git sync-refs"? The fact that you use "push" command to delete something is confusing as hell.
- codesnik 4y ago
  It's just git's UI is based on operations on the underlying storage instead of workflow intent. From that perspective branch switching and reverting a file are actually similar operations. For many cases this would be a wrong approach. But git's storage model is quite simple and elegant, and both gives unlimited freedom in adapting it to your needs and could be dangerous if you don't understand it. When coaching junior devs on git usage I always start with merkle trees, not with a list of commands to remember. This detour takes 20 minutes, but actually gives intuition to fix even worst mistakes without my help when they happen. I can't imagine the same with any other VCS.
  - guytv 4y ago
    yet one often has to google a command, to make sure what is the correct command, even if they know all about the mechanics of the underlying blob storage.
- idle_zealot 4y ago
  Right. The git porcelain is baffling, but the actual git data model doesn't need fixing; it's complex but necessarily so. I'd be more interested in an alternative porcelain than a totally different VCS like FB's Sapling.
- P_I_Staker 4y ago
  Honestly, the examples you gave seem to make sense when you understand how git works and the philosophy. It seems most (all?) interaction with the remote is via sync commands: push/pull/fetch. So why bake it into a different command. Commands like "git tag" interact with your local. Given the abstract concept of a checkout, as it works in git, none of that is surprising (save for maybe that you could create a branch); however, that seems like a desirable feature. Why would you want to do a branch create, then checkout after, when you just want it done right away? EDIT/P.S. Regarding the git "abstract concept of checkout" that I mentioned, but forgot to define. This is a pretty simple concept: switch working copy to on pointed to by branch reference, and new commits will go on that branch (appended to the end of the branch), create new branch if it doesn't exist (but doesn't this require a flag?)... can't you still create with branch if you really want to?
ww520 4y ago
Yes. The staging area is for prepping the current commit set. I can pick or exclude which changes to go into the next commit. May be if it’s renamed to Change Set people would feel better.
codesnik 4y ago
I sometimes think that staging area could be represented as a special WIP commit instead. Non pushable, automatically squashing. This potentially could cut amount of commands to learn by third. But of course I'm missing something important.
- guytv 4y ago
  That's actually doable and is what HighFlux is doing.
- P_I_Staker 4y ago
  That would certainly be simpler. You could also roll back to any commit.
somerandomqaguy 4y ago
Sorta. If you started out from a blank slate then git's not too bad to learn; I've taught several non technical people to get to the point where they can at least read a git history and have some understanding of what's happening when. At my current job though a lot of folks came in from CVS, SVN, and TFS and it's been a struggle for many. TFS for instance encourages committing large binaries so when they were migrated onto git, their repos were as large as 50 gigabytes because they have every binary from every release from way back when. I've found they actually need someone to explain why git does the things it does, otherwise they have a very wrong mental model of what's going on. And git's confusing terminology doesn't help at all. Though once it clicks, it just clicks for the most part.

guytv 4y ago

Just the ergonomics of git are sometimes mind-boggling. for instance: "git checkout" is used for 3 different things: “switch”, “create branch”, and “revert a file”. Deleting a remote tag is “git push” but a deleting a local one is “git tag -d”. There are many such examples

jwilk 4y ago
> "git checkout" can is used for 3 different things: “switch”, “create branch”, and “revert a file” Git v2.23 (released in August 2019) added "git switch" and "git restore" commands to straighten this up.
chociej 4y ago
IMO push is quite coherent since it consistently updates remote refs. The variation in checkout is pretty bad though.
- 988747 4y ago
  The perfect command for deleting remote tag would be "tag -d(elete) -r(emote) <tag>" The existence of "remote refs" is an implementation detail, and git bothers you with it unnecessarily. And if you really need a command to update all remote refs at once why not call it "git sync-refs"? The fact that you use "push" command to delete something is confusing as hell.
codesnik 4y ago
It's just git's UI is based on operations on the underlying storage instead of workflow intent. From that perspective branch switching and reverting a file are actually similar operations. For many cases this would be a wrong approach. But git's storage model is quite simple and elegant, and both gives unlimited freedom in adapting it to your needs and could be dangerous if you don't understand it. When coaching junior devs on git usage I always start with merkle trees, not with a list of commands to remember. This detour takes 20 minutes, but actually gives intuition to fix even worst mistakes without my help when they happen. I can't imagine the same with any other VCS.
- guytv 4y ago
  yet one often has to google a command, to make sure what is the correct command, even if they know all about the mechanics of the underlying blob storage.
idle_zealot 4y ago
Right. The git porcelain is baffling, but the actual git data model doesn't need fixing; it's complex but necessarily so. I'd be more interested in an alternative porcelain than a totally different VCS like FB's Sapling.
P_I_Staker 4y ago
Honestly, the examples you gave seem to make sense when you understand how git works and the philosophy. It seems most (all?) interaction with the remote is via sync commands: push/pull/fetch. So why bake it into a different command. Commands like "git tag" interact with your local. Given the abstract concept of a checkout, as it works in git, none of that is surprising (save for maybe that you could create a branch); however, that seems like a desirable feature. Why would you want to do a branch create, then checkout after, when you just want it done right away? EDIT/P.S. Regarding the git "abstract concept of checkout" that I mentioned, but forgot to define. This is a pretty simple concept: switch working copy to on pointed to by branch reference, and new commits will go on that branch (appended to the end of the branch), create new branch if it doesn't exist (but doesn't this require a flag?)... can't you still create with branch if you really want to?

ww520 4y ago

Yes. The staging area is for prepping the current commit set. I can pick or exclude which changes to go into the next commit. May be if it’s renamed to Change Set people would feel better.

codesnik 4y ago

I sometimes think that staging area could be represented as a special WIP commit instead. Non pushable, automatically squashing. This potentially could cut amount of commands to learn by third. But of course I'm missing something important.

guytv 4y ago
That's actually doable and is what HighFlux is doing.
P_I_Staker 4y ago
That would certainly be simpler. You could also roll back to any commit.

somerandomqaguy 4y ago

Sorta. If you started out from a blank slate then git's not too bad to learn; I've taught several non technical people to get to the point where they can at least read a git history and have some understanding of what's happening when. At my current job though a lot of folks came in from CVS, SVN, and TFS and it's been a struggle for many. TFS for instance encourages committing large binaries so when they were migrated onto git, their repos were as large as 50 gigabytes because they have every binary from every release from way back when. I've found they actually need someone to explain why git does the things it does, otherwise they have a very wrong mental model of what's going on. And git's confusing terminology doesn't help at all. Though once it clicks, it just clicks for the most part.