9 ms·

With the amount of information available, there is no excuse: * https://rogerdudler.github.io/git-guide/ https://rogerdudler.github.io/git-guide/ * https://gi

With the amount of information available, there is no excuse: * https://rogerdudler.github.io/git-guide/ https://rogerdudler.github.io/git-guide/ * https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2 Also see stackoverflow. Git is a complex tool because it’s tackling a complex problem. I don’t see a way of making it “easier” without massively reducing what it can do. It’s like saying we should reduce a formula one car so people can use it without reading up on it, etc. If something happens once, it happens. If something happens multiple times then it means you’re not evaluating why it occurred in the first place and learning from it. No tool in the world can solve this problem because it’s not a problem with the tool, rather the user. Git is really not so hard, but it requires a little reading.

metabagel 7y ago
Git isn’t something which you can generally be successful using in a shallow way. Most developers will need to devote significant time and energy to mastering it. There really needs to be a better layer on top of it in order to make it easier for developers to figure out how to do what they want to do. Some of the commands and switches don’t seem to be orthogonal and/or intuitive.
- wasdfff 7y ago
  A lot of people get by just staging and pushing/pulling commits, myself included. That’s 3 commands, 4 if you count git status. You do not need to dig deep to get a lot of use out of git as a basic remote sync.
- munmaek 7y ago
  Git already has layers on top of it like git porcelain or the various GUI tools that attempt to handle things smoothly. > significant time and energy All someone needs is to read through https://rogerdudler.github.io/git-guide/ https://rogerdudler.github.io/git-guide/, and learn a few commands. Are we seriously going to refer to “reading the manual” as “significant time and energy”? In this case you don’t even have to read the manual, just a primer on how git works. You know, on how the tool that you’re using works. Why are people so allergic to spending even a modicum of time on learning a tool that massively simplifies their life and makes their work possible? Do plumbers complain about having to read manuals for the equipment that they use? Electricians? As programmers our tools are easier to learn and use, yet we complain about having to any work at all. Why even be a programmer? If reading about git is so hard, what about the rest of the field that doesn’t even have documentation? How about we don’t make tools that cater to the lowest common denominator, in this case people who basically can’t be assed to do anything? RTFM.
  - Frondo 7y ago
    Because a lot of us have used tools besides git that enable the workflow we need without that complexity, and without the fragility that often necessitates going to stackoverflow or asking on a slack channel. I have a way of picking the losing side so I've been using mercurial for everything until now, and until now Bitbucket offered hg. They're decommissioning it so I'm moving over to git and I feel like my workflow has been hampered, not just in the immediate complexity of learning the new tool, but in the ongoing complexity of using a less good tool for my needs. I'm dealing with it, but the situation you're describing isn't really the one that I and a lot of other whiners are dealing with.
    - josefx 7y ago
      > Because a lot of us have used tools besides git that enable the workflow we need without that complexity I spend ages unfucking local svn working copies and long running branches on both windows and linux. git needs some serious flaws to keep up with that experience.
    - anoncake 7y ago
      > Because a lot of us have used tools besides git that enable the workflow we need Thankfully the standard DVCS is flexible enough to enable the workflows others need too.
wyoung2 7y ago
> Git is a complex tool because it’s tackling a complex problem. Fossil tackles much the same sort of problem, yet it's far simpler to use. Most of Git's problems are due to purposeful choices, but they're design choices, not inherent aspects of how a DVCS must behave. We've laid out our case for the differences here: https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik...
- munmaek 7y ago
  > their thing: Sprawling, incoherent, and inefficient > our thing: Self-contained and efficient This is not biased in any way and makes me want to continue reading. /s Also, you can’t claim something to be “efficient” when it’s doing many different things like scm, issues/tickets, a web forum/ui .... Then you have non-issues like git being installed via a package manager instead of dragging and dropping a binary. Yeah, this is such a huge problem that concerns people, better switch to Better Project (tm). And then you take Gitlab and conflate Gitlab’s issues with problems with Git. I guess gogs/gitea don’t exist? This page needs to be rewritten to simply list the differences in neutral language. There are good points but they’re lost in unnecessary epithets like “caused untold grief for git users”. I get it: git bad, our product good. Switch! — Personally, I don’t want something that tries to do many different things all at once.
  - wyoung2 7y ago
    > This is not biased in any way Of course we're biased, but every row in that table corresponds to a section below where we lay out our argument for the few words up in the table at the top. Here's the direct link for that particular point: https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki#efficient https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik... Now, if you want to debate section 2.2 on its merits, we can get into that. > you can’t claim something to be “efficient” when it’s doing many different things We can when all of that is in a single binary that's 4.4 MiB, as mine here is. A Git installation is much larger, particularly if you count its external dependencies, yet it does less. That's what we mean when we say Git is "inefficient." But I don't really want to re-hash the argument here. We laid it out for you already, past the point where you stopped reading. > git being installed via a package manager instead of dragging and dropping a binary. Yeah, this is such a huge problem that concerns people, better switch to Better Project (tm). It is on Windows, where they had to package 44-ish megs of stuff in order to get Git to run there. On POSIX platforms, the package manager isn't much help when you want to run your DVCS server in a chroot or jail. The more dependencies there are, the more you have to manually package up yourself. If your answer to that is "just" install a Docker container or whatever, you're kind of missing the original point. `/home/repo/bin/fossil` chroots itself and is self-contained within that container. (Modulo a few minor platform details like /dev/null and /dev/urandom.) > This page needs to be rewritten to simply list the differences in neutral language. We accept patches, and we have an active discussion forum. Propose alternate language, and we'll consider it. > unnecessary epithets like “caused untold grief for git users” You don't have to go searching very hard to find those stories of woe. They're so common XKCD has satirized them. We think the characterizations are justified, but again, if you think they're an over-reach, propose alternate language. > I don’t want something that tries to do many different things all at once. Not a GitHub user, then?
u801e 7y ago
> It’s like saying we should reduce a formula one car so people can use it without reading up on it, etc A far better analogy is: It's like saying we should reduce a programming language so people can use it without reading up on it, etc.
- wyoung2 7y ago
  Sorry, but this is a terrible analogy. The core problem with it is that very few people can get paid more by being better at using their [D]VCS, whereas those more skilled with their programming language(s) of choice often do get paid more to wield that knowledge. Consequently, most people do not fully master their version control system to the same level that they do with their programming language, their text editor, etc. To be specific, there are many more C++ wizards and Vim wizards than there are Git wizards. In situations like this, I prefer a tool that lets me pick it up quickly, use it easily, and then put it back down again without having to think too much about it. You see this pattern over and over in software. It is why all OSes now have some sort of Control Panel / Settings app, even if all it does is call down to some low-level tool that modifies a registry setting, XML file, or whatever, which you could edit by hand if you wanted to. These tools exist even for geeky OSes like Linux because driving the OS is usually not the end user's goal, it is to do something productive atop that OS. [D]VCSes are at this same level of infrastructure: something to use and then get past ASAP, so you can go be productive.

metabagel 7y ago

Git isn’t something which you can generally be successful using in a shallow way. Most developers will need to devote significant time and energy to mastering it. There really needs to be a better layer on top of it in order to make it easier for developers to figure out how to do what they want to do. Some of the commands and switches don’t seem to be orthogonal and/or intuitive.

wasdfff 7y ago
A lot of people get by just staging and pushing/pulling commits, myself included. That’s 3 commands, 4 if you count git status. You do not need to dig deep to get a lot of use out of git as a basic remote sync.
munmaek 7y ago
Git already has layers on top of it like git porcelain or the various GUI tools that attempt to handle things smoothly. > significant time and energy All someone needs is to read through https://rogerdudler.github.io/git-guide/ https://rogerdudler.github.io/git-guide/, and learn a few commands. Are we seriously going to refer to “reading the manual” as “significant time and energy”? In this case you don’t even have to read the manual, just a primer on how git works. You know, on how the tool that you’re using works. Why are people so allergic to spending even a modicum of time on learning a tool that massively simplifies their life and makes their work possible? Do plumbers complain about having to read manuals for the equipment that they use? Electricians? As programmers our tools are easier to learn and use, yet we complain about having to any work at all. Why even be a programmer? If reading about git is so hard, what about the rest of the field that doesn’t even have documentation? How about we don’t make tools that cater to the lowest common denominator, in this case people who basically can’t be assed to do anything? RTFM.
- Frondo 7y ago
  Because a lot of us have used tools besides git that enable the workflow we need without that complexity, and without the fragility that often necessitates going to stackoverflow or asking on a slack channel. I have a way of picking the losing side so I've been using mercurial for everything until now, and until now Bitbucket offered hg. They're decommissioning it so I'm moving over to git and I feel like my workflow has been hampered, not just in the immediate complexity of learning the new tool, but in the ongoing complexity of using a less good tool for my needs. I'm dealing with it, but the situation you're describing isn't really the one that I and a lot of other whiners are dealing with.
  - josefx 7y ago
    > Because a lot of us have used tools besides git that enable the workflow we need without that complexity I spend ages unfucking local svn working copies and long running branches on both windows and linux. git needs some serious flaws to keep up with that experience.
  - anoncake 7y ago
    > Because a lot of us have used tools besides git that enable the workflow we need Thankfully the standard DVCS is flexible enough to enable the workflows others need too.

wyoung2 7y ago

> Git is a complex tool because it’s tackling a complex problem. Fossil tackles much the same sort of problem, yet it's far simpler to use. Most of Git's problems are due to purposeful choices, but they're design choices, not inherent aspects of how a DVCS must behave. We've laid out our case for the differences here: https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik...

munmaek 7y ago
> their thing: Sprawling, incoherent, and inefficient > our thing: Self-contained and efficient This is not biased in any way and makes me want to continue reading. /s Also, you can’t claim something to be “efficient” when it’s doing many different things like scm, issues/tickets, a web forum/ui .... Then you have non-issues like git being installed via a package manager instead of dragging and dropping a binary. Yeah, this is such a huge problem that concerns people, better switch to Better Project (tm). And then you take Gitlab and conflate Gitlab’s issues with problems with Git. I guess gogs/gitea don’t exist? This page needs to be rewritten to simply list the differences in neutral language. There are good points but they’re lost in unnecessary epithets like “caused untold grief for git users”. I get it: git bad, our product good. Switch! — Personally, I don’t want something that tries to do many different things all at once.
- wyoung2 7y ago
  > This is not biased in any way Of course we're biased, but every row in that table corresponds to a section below where we lay out our argument for the few words up in the table at the top. Here's the direct link for that particular point: https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki#efficient https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik... Now, if you want to debate section 2.2 on its merits, we can get into that. > you can’t claim something to be “efficient” when it’s doing many different things We can when all of that is in a single binary that's 4.4 MiB, as mine here is. A Git installation is much larger, particularly if you count its external dependencies, yet it does less. That's what we mean when we say Git is "inefficient." But I don't really want to re-hash the argument here. We laid it out for you already, past the point where you stopped reading. > git being installed via a package manager instead of dragging and dropping a binary. Yeah, this is such a huge problem that concerns people, better switch to Better Project (tm). It is on Windows, where they had to package 44-ish megs of stuff in order to get Git to run there. On POSIX platforms, the package manager isn't much help when you want to run your DVCS server in a chroot or jail. The more dependencies there are, the more you have to manually package up yourself. If your answer to that is "just" install a Docker container or whatever, you're kind of missing the original point. `/home/repo/bin/fossil` chroots itself and is self-contained within that container. (Modulo a few minor platform details like /dev/null and /dev/urandom.) > This page needs to be rewritten to simply list the differences in neutral language. We accept patches, and we have an active discussion forum. Propose alternate language, and we'll consider it. > unnecessary epithets like “caused untold grief for git users” You don't have to go searching very hard to find those stories of woe. They're so common XKCD has satirized them. We think the characterizations are justified, but again, if you think they're an over-reach, propose alternate language. > I don’t want something that tries to do many different things all at once. Not a GitHub user, then?

u801e 7y ago

> It’s like saying we should reduce a formula one car so people can use it without reading up on it, etc A far better analogy is: It's like saying we should reduce a programming language so people can use it without reading up on it, etc.

wyoung2 7y ago
Sorry, but this is a terrible analogy. The core problem with it is that very few people can get paid more by being better at using their [D]VCS, whereas those more skilled with their programming language(s) of choice often do get paid more to wield that knowledge. Consequently, most people do not fully master their version control system to the same level that they do with their programming language, their text editor, etc. To be specific, there are many more C++ wizards and Vim wizards than there are Git wizards. In situations like this, I prefer a tool that lets me pick it up quickly, use it easily, and then put it back down again without having to think too much about it. You see this pattern over and over in software. It is why all OSes now have some sort of Control Panel / Settings app, even if all it does is call down to some low-level tool that modifies a registry setting, XML file, or whatever, which you could edit by hand if you wanted to. These tools exist even for geeky OSes like Linux because driving the OS is usually not the end user's goal, it is to do something productive atop that OS. [D]VCSes are at this same level of infrastructure: something to use and then get past ASAP, so you can go be productive.