9 ms·

"The mental model for Git is needlessly complex" This, in a nutshell, sums up my feelings about git.

emodendroket 5y ago
I never feel this way. When I started to use it, I only had to understand a few concepts. And when it started to get more complex, it was because the things I wished to do were more complex in the first place.
- strictfp 5y ago
  Did you ever use any other VCS?
  - emodendroket 5y ago
    I used mercurial a bit when I was starting out but I saw which way the wind was blowing and switched.
    - throwawayboise 5y ago
      Kind of similar. I went from Subversion to git, then tried mercurial. I found mercurial to be more natural, and still use it for my own projects. I have never seen it used in the workplace though.
      - bluGill 5y ago
        My workplace switched from hg to git. Hg didn't get support for all the other tools we use. The Jenkins hg maintainers were all using git when we checked, and it showed. That is but one example of a tool that didn't work with hg.
  - throwawayboise 5y ago
    Subversion, and mercurial to a lesser extent. CVS and Visual Source Safe way back in the day.
    - strictfp 5y ago
      Intersting. I always found git needlessly obtuse, with for instance the status reporting diffs to local remote-tracking branches instead of the actual remote branches, the staging area having an unclear purpose to me at the start, that it mixes up "local" "remote" and "base" depending on how an operation is implemented, commands doing double duty providing wildly different functionality etc..
      - throwawayboise 5y ago
        Yes, coming from Subversion the whole staging area concept seemed like needless complexity. For my purposes it still is, but I've gotten used to it.
        emodendroket 5y ago
        It seems like a nice way of having changes you don't actually want to commit but I'm not sure how other systems approach that problem.
        strictfp 5y ago
        I really liked Perforce changelists, so in theory I should like the staging area, but I kind of don't :) I use it nowadays, but I think it's too limited to provide value like Perforce changelists does. I'd like to have one changelist for random local dev changes, like setting debug flags or turning off optimizations. Stuff I have no plan on checking in. Then I'd like to group my edits into maybe one to three possible future commits. The staging area doesn't allow this, I need to keep doing "git add -p" and carefully sidestep all the debugging stuff, plus that I can only work on one commit at a time. So could have been useful, but not so useful in it's current state IMO.
        jeffbee 5y ago
        > plus that I can only work on one commit at a time. This is that part of git that bugs me the most! It's totally hostile to the way I prefer to work: one screen session containing all the editors and shells per change that I am concurrently working on. Git simply cannot do it, unless I clone the entire repo for every change, which is not practical for large projects.
  - aidenn0 5y ago
    I have used SCCS, CVS, VSS, SVN, Clearcase, darcs, git, and hg. I found darcs to be the most ergonomic, except for the fact that it was orders of magnitude too slow. SVN was good in that it fixed most of the pain-points that CVS had. git and hg are both great. I tried them both out at about the same time and found hg to be more intuitive, but it didn't take me long using git to be comfortable with it. The UI of git is honestly quite terrible. Commands are often confusingly named and have seemingly disparate uses. However the underlying model of git is straightforward enough for me to reason about what operations should be possible. Pretty much all VCSs require some such knowledge and reasoning; e.g.: - The lack of atomic commits in CVS stems from the underlying RCS stack it is based on. - SVNs brain-dead branching stems from the fact that there are no branches in SVN, just O(1) copies from one path to another.
- throwawayboise 5y ago
  Yes, it can be that way. I know/use clone, diff, add, commit, and pull/push. That is all I ever do with Git, and it's pretty straightforward. I have found no need for the rest of it, and it confused me when I tried to look into it.
- loudthing 5y ago
  Honestly, git is absolutely needlessly complex. The worst aspect of git is the almost arbitrary naming of tasks that hardcore git users swear are obvious. E.g. "cherry picking", "fast forward", "rebase". Anyone not familiar with git will balk at the concept that the intent of these phrases are obvious. Note: I use git frequently every day, not by choice, but simply because it is the defacto version tracking system. I have grown to like it, but I miss the more straightforward every day use of Mercurial (which is rarely supported by any services anymore). Edit: ... and as a native English speaker, I can't help but feel bad for others who are expected to become familiar with these functions without familiarity with these colloquialisms.
  - withinboredom 5y ago
    If you used SVN or something similar, daily, prior to git existing, git operations actually does seem pretty obvious.
    - HWR_14 5y ago
      As the poster pointed out, he's coming from Mecurial, which is a DVCS similar to Git.
    - wyoung2 5y ago
      Fossil was designed by someone coming from CVS, so its everyday CLI is actually closest to that. As a Subversion expat, I found Fossil quite easy to pick up, modulo a few quibbles that muscle memory sorted out quickly enough.
  - judge2020 5y ago
    Perhaps, but it originates from the days you'd run `man git <command>` before using it. `man git rebase` works and has a very lengthy description with example tree states.
    - strictfp 5y ago
      git-remove-ref-format vigilantly removes non-annotated remote ref formats using non-configured upstream branches, while applying applicable parents to transfer the given ref formats. https://git-man-page-generator.lokaltog.net https://git-man-page-generator.lokaltog.net
strictfp 5y ago
BuT It MaKEs SeNsE If YoU KnOW HoW ItS ImPleMEnTeD
orra 5y ago
git rebase -i (interactive rebase) is, however, to kill for.
- strictfp 5y ago
  I don't know, git doesn't have very good memory when doing rebases. You need to redo the same conflict resolution several times. You need rerere to get around that. Plus that it's quite hard to rewrite dates, names, or split commits into several.
  - orra 5y ago
    Some fair points, but these things are possible. Last time I was using Mercurial—which was admittedly a long time ago—there wasn't /anything/ like fixup.
  - TeeMassive 5y ago
    > I don't know, git doesn't have very good memory when doing rebases. https://www.git-scm.com/book/en/v2/Git-Tools-Rerere https://www.git-scm.com/book/en/v2/Git-Tools-Rerere > Plus that it's quite hard to rewrite dates, names, or split commits into several. Read the documentation for 'rebase' and 'cherry-pick' and 'add'.
    - growse 5y ago
      > > I don't know, git doesn't have very good memory when doing rebases. > https://www.git-scm.com/book/en/v2/Git-Tools-Rerere https://www.git-scm.com/book/en/v2/Git-Tools-Rerere Thank you for this, looks like exactly what I need at the moment maintaining a dev branch alongside a bugfix deployed main branch and having to do lots of rebasing.
    - strictfp 5y ago
      If you read my post again, you'll see that I already mentioned rerere :)
- mdaniel 5y ago
  And its friend, "git rebase -i --autosq" for when you knew at commit time that you needed to fold a fix into an earlier commit, by setting the commit message as "fixup! cafebabedeadbeef" or "fixup! the old commit message" (but I have less experience with the latter form)
RyEgswuCsn 5y ago
I think it's not that bad. There is a local commit graph and there are one or more remote commit graphs. The main operations with git are to manipulate one's commit graphs and, when the time comes, reconcile the local graph with the remote one. Once users figured out what they want to do with the graphs, they then need to figure out how to achieve that with git's cli. And I feel that is where many of the complaints about git's complexities comes from. IMHO the best way to use git is through a GUI so that one only needs to figure out what they want to do with the commit graphs, leaving the second part of the puzzle to the GUI.
andrew_ 5y ago
We say this now, ignoring the hot messes that were SourceSafe, Pervasive, CVS, and SVN. Git is light years more elegant that predecessors, and its holding power is evidence of that. We're able to criticize now because we've had the privilege of forgetting (or never having experienced) just how bad it used to be, and the sheer amount of time with one tool that's been a staple for far longer than previous tools lasted.
- unclebucknasty 5y ago
  Most of the previous version control systems you mentioned were much less complex and had an extraordinadily easy mental model to understand in comparison. Git set out to solve a different problem: adapt VCS to an agile, CI/CD world. It does this much better than those previous VCS generations, but its mental model does seem needlessly complex.
  - nijave 5y ago
    Well, I think it was also meant to be highly distributed as well (many different people all over the place could then come back and bring their changes together) In order to achieve that, I think you end up with some additional complexity like local vs remote and a complicated graph structure to accommodate people coming "on" and "off" line
    - unclebucknasty 5y ago
      >Well, I think it was also meant to be highly distributed as well Yeah, I guess I kind of consider that an agile tenet: in general, that people can work quickly and iteratively with limited interdependencies. Said another way, it would be difficult for teams to work in an agile fashion--where the work itself is frequently distributed and happening in parallel--using most older VCS models.
  - plorkyeran 5y ago
    Git set out to solve the problems the Linux kernel development faced, which is not particularly "Agile" and doesn't do CI/CD.
setpatchaddress 5y ago
The git model is really not that complicated. What's awful is the command-line UI to the functionality.
philwelch 5y ago
I'm not sure about that. Ironically I think git would be extremely intuitive if you had the right GUI for it and could e.g. rebase by clicking and dragging branches onto master.
rsj_hn 5y ago
git was a great breakthrough in terms of performance and supporting distributed workflows, but now like many technological breakthroughs there needs to be an interface that exposes completely different abstractions based on the user's workflows rather than the implementation's data structures. For example, why can't I do something like git view filename -3 # shows file before last 3 changes _made_to_the_file_ (irrespective of how many commits) git view filename $date # shows state of file at date git revert filename $date | number # roll back a specific file to what it looked like at $date or file version I have the feeling that the developers of git even understand this, but they needed to get git out the door and assumed the community would build the layer atop git to make it more user-friendly. Sadly, attempts to make git user-friendly have so far boiled down to GUIs rather than introducing new concepts. Certainly the current collection of shell scripts that exist as the ui for git definately have a hackish feel to them.
- nijave 5y ago
  I think the explosion of the internet sort of squashed some of the great distributed feats. Having blazing fast internet connections (at least relative to source code transfer) available all over the world makes decentralization less important (in the normal pull, change, push model)
  - rsj_hn 5y ago
    Yeah, fast internet helps a lot, but being able to grab open source code, work on it, and then push in changes with something better than an email of diffs is certainly nice. The technology of pull requests/cloning has a lot of advantages when you want code to cross organizational boundaries.
unclebucknasty 5y ago
You (and the author) are not alone: https://xkcd.com/1597/ https://xkcd.com/1597/
cdogl 5y ago
I suspect this is highly subjective. I learned git when I barely understood programming. Figured out the basics and went from there. It’s never gotten in my way. I don’t deny it’s been confusing at times, but I’ve used svn and hg and had a similar experience. People seem to have highly variable experiences of it - maybe due to how they think, or perhaps an element of chance and first impressions?
TeeMassive 5y ago
Directed Acyclic Graphs and SHA hashes are not hard concepts to understand. From that every commands make sense very quickly.
- kps 5y ago
  >Directed Acyclic Graphs and SHA hashes… … of what, though? On GitHub, and on every other project I've worked on that used git, the natural unit is a set of changes (e.g. a GitHub PR, a patch). If you run `git show $SHA`, git will show you a set of changes. But that's a lie; that's not what git stores. If you run `git log`, it'll give you a list of commits. If you run `git show` for each, it'll show you a bunch of changes. Many users expect (quite reasonably, before they've been bitten) that if you start from scratch and apply those changes in order, what you end up with will be the same as your current tree. Nope.
  - TeeMassive 5y ago
    > the natural unit is a set of changes What "natural" does even mean? That's a vague philosophical argument. And even then, all versioning systems deal with versions, not changes. Changes are relative to different versions. This is true even for SVN. Changes are always relative, it doesn't make sense to track them as the based unit conceptually or even for performance. Different versions implies change, not the other way around. > If you run `git show $SHA`, git will show you a set of changes. But that's a lie; that's not what git stores. Each new version will bring a change. This is not a lie. Sure it could show the entire corresponding tree by flooding your console, or it could be more practical and merely show the diff from the previous parent(s). This is the kind of thing that people who do not bother to take the time (about one hour) are stuck with. Don't worry, it's not that hard. > Many users expect (quite reasonably, before they've been bitten) that if you start from scratch and apply those changes in order, what you end up with will be the same as your current tree. Nope. The author, the date and other data about the commit do matter. If you rebase your commits, which is effectively applying those changes in order, then very very likely you will not have the same snapshots of the filesystem. And even if the filesystem remain the same, the data about the commit will be changed. It seems that your expectations of what a CVS "truly stores" is naive and based on a lack of experience.
throw0101a 5y ago
The old joke: > git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space. * https://twitter.com/agnoster/status/44636629423497217 https://twitter.com/agnoster/status/44636629423497217
didip 5y ago
I agree. The reason why it doesn't feel that way is because of the wealth of tutorial website on how to run git commands or the users already got used to it. Mercurial names are much more natural but it lost the war already. I use git every day and don't complain when using it. But when a junior is learning git, you start seeing the oddities.

I never feel this way. When I started to use it, I only had to understand a few concepts. And when it started to get more complex, it was because the things I wished to do were more complex in the first place.

strictfp 5y ago
Did you ever use any other VCS?
- emodendroket 5y ago
  I used mercurial a bit when I was starting out but I saw which way the wind was blowing and switched.
  - throwawayboise 5y ago
    Kind of similar. I went from Subversion to git, then tried mercurial. I found mercurial to be more natural, and still use it for my own projects. I have never seen it used in the workplace though.
    - bluGill 5y ago
      My workplace switched from hg to git. Hg didn't get support for all the other tools we use. The Jenkins hg maintainers were all using git when we checked, and it showed. That is but one example of a tool that didn't work with hg.
- throwawayboise 5y ago
  Subversion, and mercurial to a lesser extent. CVS and Visual Source Safe way back in the day.
  - strictfp 5y ago
    Intersting. I always found git needlessly obtuse, with for instance the status reporting diffs to local remote-tracking branches instead of the actual remote branches, the staging area having an unclear purpose to me at the start, that it mixes up "local" "remote" and "base" depending on how an operation is implemented, commands doing double duty providing wildly different functionality etc..
    - throwawayboise 5y ago
      Yes, coming from Subversion the whole staging area concept seemed like needless complexity. For my purposes it still is, but I've gotten used to it.
      - emodendroket 5y ago
        It seems like a nice way of having changes you don't actually want to commit but I'm not sure how other systems approach that problem.
      - strictfp 5y ago
        I really liked Perforce changelists, so in theory I should like the staging area, but I kind of don't :) I use it nowadays, but I think it's too limited to provide value like Perforce changelists does. I'd like to have one changelist for random local dev changes, like setting debug flags or turning off optimizations. Stuff I have no plan on checking in. Then I'd like to group my edits into maybe one to three possible future commits. The staging area doesn't allow this, I need to keep doing "git add -p" and carefully sidestep all the debugging stuff, plus that I can only work on one commit at a time. So could have been useful, but not so useful in it's current state IMO.
        jeffbee 5y ago
        > plus that I can only work on one commit at a time. This is that part of git that bugs me the most! It's totally hostile to the way I prefer to work: one screen session containing all the editors and shells per change that I am concurrently working on. Git simply cannot do it, unless I clone the entire repo for every change, which is not practical for large projects.
- aidenn0 5y ago
  I have used SCCS, CVS, VSS, SVN, Clearcase, darcs, git, and hg. I found darcs to be the most ergonomic, except for the fact that it was orders of magnitude too slow. SVN was good in that it fixed most of the pain-points that CVS had. git and hg are both great. I tried them both out at about the same time and found hg to be more intuitive, but it didn't take me long using git to be comfortable with it. The UI of git is honestly quite terrible. Commands are often confusingly named and have seemingly disparate uses. However the underlying model of git is straightforward enough for me to reason about what operations should be possible. Pretty much all VCSs require some such knowledge and reasoning; e.g.: - The lack of atomic commits in CVS stems from the underlying RCS stack it is based on. - SVNs brain-dead branching stems from the fact that there are no branches in SVN, just O(1) copies from one path to another.
throwawayboise 5y ago
Yes, it can be that way. I know/use clone, diff, add, commit, and pull/push. That is all I ever do with Git, and it's pretty straightforward. I have found no need for the rest of it, and it confused me when I tried to look into it.
loudthing 5y ago
Honestly, git is absolutely needlessly complex. The worst aspect of git is the almost arbitrary naming of tasks that hardcore git users swear are obvious. E.g. "cherry picking", "fast forward", "rebase". Anyone not familiar with git will balk at the concept that the intent of these phrases are obvious. Note: I use git frequently every day, not by choice, but simply because it is the defacto version tracking system. I have grown to like it, but I miss the more straightforward every day use of Mercurial (which is rarely supported by any services anymore). Edit: ... and as a native English speaker, I can't help but feel bad for others who are expected to become familiar with these functions without familiarity with these colloquialisms.
- withinboredom 5y ago
  If you used SVN or something similar, daily, prior to git existing, git operations actually does seem pretty obvious.
  - HWR_14 5y ago
    As the poster pointed out, he's coming from Mecurial, which is a DVCS similar to Git.
  - wyoung2 5y ago
    Fossil was designed by someone coming from CVS, so its everyday CLI is actually closest to that. As a Subversion expat, I found Fossil quite easy to pick up, modulo a few quibbles that muscle memory sorted out quickly enough.
- judge2020 5y ago
  Perhaps, but it originates from the days you'd run `man git <command>` before using it. `man git rebase` works and has a very lengthy description with example tree states.
  - strictfp 5y ago
    git-remove-ref-format vigilantly removes non-annotated remote ref formats using non-configured upstream branches, while applying applicable parents to transfer the given ref formats. https://git-man-page-generator.lokaltog.net https://git-man-page-generator.lokaltog.net

strictfp 5y ago

BuT It MaKEs SeNsE If YoU KnOW HoW ItS ImPleMEnTeD

orra 5y ago

git rebase -i (interactive rebase) is, however, to kill for.

strictfp 5y ago
I don't know, git doesn't have very good memory when doing rebases. You need to redo the same conflict resolution several times. You need rerere to get around that. Plus that it's quite hard to rewrite dates, names, or split commits into several.
- orra 5y ago
  Some fair points, but these things are possible. Last time I was using Mercurial—which was admittedly a long time ago—there wasn't /anything/ like fixup.
- TeeMassive 5y ago
  > I don't know, git doesn't have very good memory when doing rebases. https://www.git-scm.com/book/en/v2/Git-Tools-Rerere https://www.git-scm.com/book/en/v2/Git-Tools-Rerere > Plus that it's quite hard to rewrite dates, names, or split commits into several. Read the documentation for 'rebase' and 'cherry-pick' and 'add'.
  - growse 5y ago
    > > I don't know, git doesn't have very good memory when doing rebases. > https://www.git-scm.com/book/en/v2/Git-Tools-Rerere https://www.git-scm.com/book/en/v2/Git-Tools-Rerere Thank you for this, looks like exactly what I need at the moment maintaining a dev branch alongside a bugfix deployed main branch and having to do lots of rebasing.
  - strictfp 5y ago
    If you read my post again, you'll see that I already mentioned rerere :)
mdaniel 5y ago
And its friend, "git rebase -i --autosq" for when you knew at commit time that you needed to fold a fix into an earlier commit, by setting the commit message as "fixup! cafebabedeadbeef" or "fixup! the old commit message" (but I have less experience with the latter form)

RyEgswuCsn 5y ago

I think it's not that bad. There is a local commit graph and there are one or more remote commit graphs. The main operations with git are to manipulate one's commit graphs and, when the time comes, reconcile the local graph with the remote one. Once users figured out what they want to do with the graphs, they then need to figure out how to achieve that with git's cli. And I feel that is where many of the complaints about git's complexities comes from. IMHO the best way to use git is through a GUI so that one only needs to figure out what they want to do with the commit graphs, leaving the second part of the puzzle to the GUI.

andrew_ 5y ago

We say this now, ignoring the hot messes that were SourceSafe, Pervasive, CVS, and SVN. Git is light years more elegant that predecessors, and its holding power is evidence of that. We're able to criticize now because we've had the privilege of forgetting (or never having experienced) just how bad it used to be, and the sheer amount of time with one tool that's been a staple for far longer than previous tools lasted.

unclebucknasty 5y ago
Most of the previous version control systems you mentioned were much less complex and had an extraordinadily easy mental model to understand in comparison. Git set out to solve a different problem: adapt VCS to an agile, CI/CD world. It does this much better than those previous VCS generations, but its mental model does seem needlessly complex.
- nijave 5y ago
  Well, I think it was also meant to be highly distributed as well (many different people all over the place could then come back and bring their changes together) In order to achieve that, I think you end up with some additional complexity like local vs remote and a complicated graph structure to accommodate people coming "on" and "off" line
  - unclebucknasty 5y ago
    >Well, I think it was also meant to be highly distributed as well Yeah, I guess I kind of consider that an agile tenet: in general, that people can work quickly and iteratively with limited interdependencies. Said another way, it would be difficult for teams to work in an agile fashion--where the work itself is frequently distributed and happening in parallel--using most older VCS models.
- plorkyeran 5y ago
  Git set out to solve the problems the Linux kernel development faced, which is not particularly "Agile" and doesn't do CI/CD.

setpatchaddress 5y ago

The git model is really not that complicated. What's awful is the command-line UI to the functionality.

philwelch 5y ago

I'm not sure about that. Ironically I think git would be extremely intuitive if you had the right GUI for it and could e.g. rebase by clicking and dragging branches onto master.

rsj_hn 5y ago

git was a great breakthrough in terms of performance and supporting distributed workflows, but now like many technological breakthroughs there needs to be an interface that exposes completely different abstractions based on the user's workflows rather than the implementation's data structures. For example, why can't I do something like git view filename -3 # shows file before last 3 changes _made_to_the_file_ (irrespective of how many commits) git view filename $date # shows state of file at date git revert filename $date | number # roll back a specific file to what it looked like at $date or file version I have the feeling that the developers of git even understand this, but they needed to get git out the door and assumed the community would build the layer atop git to make it more user-friendly. Sadly, attempts to make git user-friendly have so far boiled down to GUIs rather than introducing new concepts. Certainly the current collection of shell scripts that exist as the ui for git definately have a hackish feel to them.

nijave 5y ago
I think the explosion of the internet sort of squashed some of the great distributed feats. Having blazing fast internet connections (at least relative to source code transfer) available all over the world makes decentralization less important (in the normal pull, change, push model)
- rsj_hn 5y ago
  Yeah, fast internet helps a lot, but being able to grab open source code, work on it, and then push in changes with something better than an email of diffs is certainly nice. The technology of pull requests/cloning has a lot of advantages when you want code to cross organizational boundaries.

unclebucknasty 5y ago

You (and the author) are not alone: https://xkcd.com/1597/ https://xkcd.com/1597/

cdogl 5y ago

I suspect this is highly subjective. I learned git when I barely understood programming. Figured out the basics and went from there. It’s never gotten in my way. I don’t deny it’s been confusing at times, but I’ve used svn and hg and had a similar experience. People seem to have highly variable experiences of it - maybe due to how they think, or perhaps an element of chance and first impressions?

TeeMassive 5y ago

Directed Acyclic Graphs and SHA hashes are not hard concepts to understand. From that every commands make sense very quickly.

kps 5y ago
>Directed Acyclic Graphs and SHA hashes… … of what, though? On GitHub, and on every other project I've worked on that used git, the natural unit is a set of changes (e.g. a GitHub PR, a patch). If you run `git show $SHA`, git will show you a set of changes. But that's a lie; that's not what git stores. If you run `git log`, it'll give you a list of commits. If you run `git show` for each, it'll show you a bunch of changes. Many users expect (quite reasonably, before they've been bitten) that if you start from scratch and apply those changes in order, what you end up with will be the same as your current tree. Nope.
- TeeMassive 5y ago
  > the natural unit is a set of changes What "natural" does even mean? That's a vague philosophical argument. And even then, all versioning systems deal with versions, not changes. Changes are relative to different versions. This is true even for SVN. Changes are always relative, it doesn't make sense to track them as the based unit conceptually or even for performance. Different versions implies change, not the other way around. > If you run `git show $SHA`, git will show you a set of changes. But that's a lie; that's not what git stores. Each new version will bring a change. This is not a lie. Sure it could show the entire corresponding tree by flooding your console, or it could be more practical and merely show the diff from the previous parent(s). This is the kind of thing that people who do not bother to take the time (about one hour) are stuck with. Don't worry, it's not that hard. > Many users expect (quite reasonably, before they've been bitten) that if you start from scratch and apply those changes in order, what you end up with will be the same as your current tree. Nope. The author, the date and other data about the commit do matter. If you rebase your commits, which is effectively applying those changes in order, then very very likely you will not have the same snapshots of the filesystem. And even if the filesystem remain the same, the data about the commit will be changed. It seems that your expectations of what a CVS "truly stores" is naive and based on a lack of experience.

throw0101a 5y ago

The old joke: > git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space. * https://twitter.com/agnoster/status/44636629423497217 https://twitter.com/agnoster/status/44636629423497217

didip 5y ago

I agree. The reason why it doesn't feel that way is because of the wealth of tutorial website on how to run git commands or the users already got used to it. Mercurial names are much more natural but it lost the war already. I use git every day and don't complain when using it. But when a junior is learning git, you start seeing the oddities.