7 ms·

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.

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
emodendroket 5y ago
Well, sure, the names aren't obvious if you're not already familiar with them, but neither are names like "linear probing." New concepts come with new names.
- deleted 5y ago
  [deleted]
roenxi 5y ago
The complexity isn't needless, it is hard to find a part of git that can be simplified without losing something important. But the command line user interface is one of the worst I've ever seen. The names are bad, discoverability is poor and which command line tool does what doesn't always make sense.
- loudthing 5y ago
  I completely agree. Git is a product of its requirements. It's not perfect, but it gets the job done, and obviously it does it pretty well.
  - quicklime 5y ago
    Products don't have requirements, users have requirements :) The requirements of Linus and the kernel developers are completely different from the requirements of the vast majority of users of Git, who are using it in small teams in a centralized way. I would argue that the only benefit that this decentralization gives is a local cache, which makes things nice and fast. Most users don't need to be able to create branches easily (code review tools already let you do that, effectively) and it's just given people enough rope to hang themselves (e.g. GitFlow). IMO the worst aspect of this needless complexity is having to explain to people "you've got 1) the branch central repo, 2) your local copy of that branch, and 3) your local branch". It gets even more complicated when personal forks come into the picture, as there are just so many copies of things to manage or trip over. Try explaining to a junior developer why "git fetch" takes two arguments ("origin" and "master") while "git rebase" takes just one: "origin/master".
  - Frost1x 5y ago
    I'm not sure it's so obvious that it does it well. The thing about the tech industry is there's a lot of cargo cult and leader/follower mentality. There are plenty of shops that use git just because every other shop uses git. Chances are, most of them don't need anything nearly as complex as Git and other version management approaches for their project would suffice just as well. It's sort of how a lot of shops decide they need to incorporate 'AI' into everything, or they need to use microservices and Kubernetes to solve their problem. Some of it is just resume driven development but a lot of it is just observing and following trends.
_dark_matter_ 5y ago
If you've used a tool like Looker that tried to ignore the difficult parts of git, you'll quickly realize they are not ignorable, but necessary.
jamesmontalvo3 5y ago
Genuinely curious: what would you rename cherry picking, fast forwarding, and rebasing?
- loudthing 5y ago
  I would eliminate these tasks from the aspect of the user and provide a more straight forward way to accomplish the same intent. You make a good point though because this is easier said than done with a typical terminal based application.
  - jamesmontalvo3 5y ago
    You want to remove fast-forward and rebase from a graph based version control system? What would you do instead? Always merge?
    - apocolyps6 5y ago
      It's been working for me so far :)
    - aeneasmackenzie 5y ago
      It sounds like he wants a GUI so you’d just drag and drop.
    - emodendroket 5y ago
      Isn't that the hg concept, no history rewrites? Well it's more nuanced than that but you have much less freedom, I think
  - rezonant 5y ago
    I don't think it makes sense to eliminate these, but I'll toss in "Take Commit" as an alternative name that might be more obvious than "Cherry Pick". Still, once you know it, you know it. You'd still need to understand what Take Commit means to use it effectively, but it would make it easier for a dev to learn it the first time.

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

emodendroket 5y ago

Well, sure, the names aren't obvious if you're not already familiar with them, but neither are names like "linear probing." New concepts come with new names.

deleted 5y ago
[deleted]

roenxi 5y ago

The complexity isn't needless, it is hard to find a part of git that can be simplified without losing something important. But the command line user interface is one of the worst I've ever seen. The names are bad, discoverability is poor and which command line tool does what doesn't always make sense.

loudthing 5y ago
I completely agree. Git is a product of its requirements. It's not perfect, but it gets the job done, and obviously it does it pretty well.
- quicklime 5y ago
  Products don't have requirements, users have requirements :) The requirements of Linus and the kernel developers are completely different from the requirements of the vast majority of users of Git, who are using it in small teams in a centralized way. I would argue that the only benefit that this decentralization gives is a local cache, which makes things nice and fast. Most users don't need to be able to create branches easily (code review tools already let you do that, effectively) and it's just given people enough rope to hang themselves (e.g. GitFlow). IMO the worst aspect of this needless complexity is having to explain to people "you've got 1) the branch central repo, 2) your local copy of that branch, and 3) your local branch". It gets even more complicated when personal forks come into the picture, as there are just so many copies of things to manage or trip over. Try explaining to a junior developer why "git fetch" takes two arguments ("origin" and "master") while "git rebase" takes just one: "origin/master".
- Frost1x 5y ago
  I'm not sure it's so obvious that it does it well. The thing about the tech industry is there's a lot of cargo cult and leader/follower mentality. There are plenty of shops that use git just because every other shop uses git. Chances are, most of them don't need anything nearly as complex as Git and other version management approaches for their project would suffice just as well. It's sort of how a lot of shops decide they need to incorporate 'AI' into everything, or they need to use microservices and Kubernetes to solve their problem. Some of it is just resume driven development but a lot of it is just observing and following trends.

_dark_matter_ 5y ago

If you've used a tool like Looker that tried to ignore the difficult parts of git, you'll quickly realize they are not ignorable, but necessary.

jamesmontalvo3 5y ago

Genuinely curious: what would you rename cherry picking, fast forwarding, and rebasing?

loudthing 5y ago
I would eliminate these tasks from the aspect of the user and provide a more straight forward way to accomplish the same intent. You make a good point though because this is easier said than done with a typical terminal based application.
- jamesmontalvo3 5y ago
  You want to remove fast-forward and rebase from a graph based version control system? What would you do instead? Always merge?
  - apocolyps6 5y ago
    It's been working for me so far :)
  - aeneasmackenzie 5y ago
    It sounds like he wants a GUI so you’d just drag and drop.
  - emodendroket 5y ago
    Isn't that the hg concept, no history rewrites? Well it's more nuanced than that but you have much less freedom, I think
- rezonant 5y ago
  I don't think it makes sense to eliminate these, but I'll toss in "Take Commit" as an alternative name that might be more obvious than "Cherry Pick". Still, once you know it, you know it. You'd still need to understand what Take Commit means to use it effectively, but it would make it easier for a dev to learn it the first time.