5 ms·

I must admit I'm a little bit confused. It opens with a discussion that people find Git hard to use, and a statement that these problems are likely more than sk

by cyphar 8y ago

I must admit I'm a little bit confused. It opens with a discussion that people find Git hard to use, and a statement that these problems are likely more than skin-deep but then goes on to describe a wrapper around Git which is mostly a bunch of aliases. Don't get me wrong, I'm know that many people do find Git hard-to-use, but I don't see anything in the eventual project implementation which backs up the original claim that the problems are conceptual. I don't think it's possible to fix conceptual problems in a tool by just wrapping it. I have heard people complain about the staging concept (personally I find it useful, because you can do 'git add -p' which allows you to craft intermediate commits or to-be-squashed fixup commits after you've finished some development), so it's removal in this tool is unsurprising. And it is nice to auto-stash on branch change (though personally I think that they should've made stashing a much better-supported concept in their Git wrapper -- I've never really liked how stashing was implemented in Git). I do really like that they appear to have worked hard to remove all of the super-scary warnings that Git likes to spit out. As someone who has taught high-school students how to use Git (among other things), I've learned that the easiest way to scare away people from your project is to have bright-red warnings in response to a user doing something. Most students describe it as though the computer is effectively screaming at them. Some tools over-compensate for this is and spew emoji in response to user input, so I'm happy this tool has struck the right balance.

deepspace 8y ago
I could never understand the complaint that Git is "hard to use". Having used a plethora of version control systems over many years, I never found Git to significantly more or less complicated than any other system. Version management includes many use cases, some of which are inherently complex. Therefore any version control tool must be able to perform both simple and complex tasks, and the latter ones will obviously require a more complicated syntax and conceptual model. In any case, we are supposed to be professionals. Complaining that Git is hard to use is a bit like a machinist complaining that a CNC machine is hard to use. If you want to accomplish non-trivial things in any field, you have to be prepared to deal with some level of complexity. /rant
- saagarjha 8y ago
  Git, the version control system, is pretty simple. Git, the command line tool that helps manage repositories, is not.
  - chupasaurus 8y ago
    Linus' power had lasted that much.
  - Certhas 8y ago
    Which is why I like gutless. Same VCS, sane interfaces, less state to juggle.
- craftyguy 8y ago
  Not everyone here is a 'professional' software developer. Git does have a steep learning curve. (I've used git extensively for years, just playing devil's advocate)
  - SOLAR_FIELDS 8y ago
    To reinforce your point - I have worked with people in the past, mostly older, that struggled a lot with Git when all they were trying to do was something simple like commit some static files generated from third-party software to my project. These people only needed the bare minimum (stage, commit, push) of Git yet found themselves baffled and fighting with the tool because of all the possibilities and things it could do that they didn’t really need.
    - Piskvorrr 8y ago
      There's a fair amount of tools capable of manipulating a Git repo, not all of which are `/usr/bin/git`. "Everybody must use this complex CLI power tool, therefore people struggle" is simply untrue here, in the premise.
- oppositelock 8y ago
  Try managing a massive set of inter-dependent repositories too big for a mono-repo with git, then you will know "hard to use". Your only real choice in this case is submodules, and those bring in an additional layer of pain.
Nasrudith 8y ago
Conceptual problems themselves may be shallow, deep, or both. Wrapping machine code with assembly makes it easier to use but doesn't fix nasty issues with lack of memory boundaries. Conceptually programmers having to mentally convert every line is poor ergonomics and will reduce speed and increase errors. Going to labels instead of numbers is an improvement even if shallow and able to improved upon further.
opcenter 8y ago
I took a quick look at the list of commands and they looked so similar to the primary git commands I use that it seemed like a waste. Better to just learn how to use git.
chx 8y ago
In my own experience, https://www.sbf5.com/~cduan/technical/git/ https://www.sbf5.com/~cduan/technical/git/ makes all the difference in this world. The main complaint still remains: the CLI UX (yes, CLI has a user experience!) is really bewildeirng because switches change commands in really, really significant ways, so much so they ought to be different commands. And operations have totally different ways to express "work with repo only" "work with index" "work with working tree". And then git reset does not touch your working files but git reset --hard ruins your day unless you build a safety net: https://gist.github.com/chx/85db0ebed1e02ab14b1a65b6024dea29 https://gist.github.com/chx/85db0ebed1e02ab14b1a65b6024dea29 Back to the tutorial: > you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something. > Half of the existing resources on Git, unfortunately, take just that approach: they walk you through which commands to run when, and expect that you should do fine if you just mimic those commands. The other half does go through all the concepts, but from what I have seen, they explain Git in a manner that assumes you already understand how Git works.
rawoke083600 8y ago
Well I'm definitely not a git expert ( i guess I should just invest more time into it). But was wondering the other day. Isn't GIT "as good" as its(source control) going to get ? Giving the problem its trying to solve:source control,distributed teams/repo's, branching etc... I mean what comes after GIT ?
- cyphar 8y ago
  There are some projects that aim to improve the merging model of Git, such as pijul[1]. Git uses "three-way merge" and it is fairly well-known that the repository state you end up with for non-fast-forward merges (merges that need merge commits) is not necessarily well-understood in all cases. Pijul uses a more efficient algorithm that has well-understood merge characteristics, and is designed around patches not repository states (which means that conceptually patches are the core -- rather than in Git where patches appear to be core but are actually all generated on-the-fly). It should be noted that Git was not unique in its design. There were many source-control systems that had the same model that pre-dated Git, it's just that Git was fast and significantly easier to use than the other tools. The previous tools would not have been usable for developing Linux, and so Git was obviously necessary. [1]: https://pijul.org/ https://pijul.org/
  - rawoke083600 8y ago
    git was easier to use :) - thanks will check it out
qznc 8y ago
I'm now roughly one year into my experiment to not use the index. I made some aliases to do that. My conclusion is: The index is unnecessary complexity. Amend to commits instead. My aliases do not work cleanly, so I don't want to advertise them. Still, a git wrapper which removes the index would be an improvement. By the way, can we still call it "porcelain" or is that outdated?
- maxxxxx 8y ago
  "The index is unnecessary complexity. Amend to commits instead." How is that easier than the index and how do you undo changes?

by cyphar 8y ago

deepspace 8y ago

I could never understand the complaint that Git is "hard to use". Having used a plethora of version control systems over many years, I never found Git to significantly more or less complicated than any other system. Version management includes many use cases, some of which are inherently complex. Therefore any version control tool must be able to perform both simple and complex tasks, and the latter ones will obviously require a more complicated syntax and conceptual model. In any case, we are supposed to be professionals. Complaining that Git is hard to use is a bit like a machinist complaining that a CNC machine is hard to use. If you want to accomplish non-trivial things in any field, you have to be prepared to deal with some level of complexity. /rant

saagarjha 8y ago
Git, the version control system, is pretty simple. Git, the command line tool that helps manage repositories, is not.
- chupasaurus 8y ago
  Linus' power had lasted that much.
- Certhas 8y ago
  Which is why I like gutless. Same VCS, sane interfaces, less state to juggle.
craftyguy 8y ago
Not everyone here is a 'professional' software developer. Git does have a steep learning curve. (I've used git extensively for years, just playing devil's advocate)
- SOLAR_FIELDS 8y ago
  To reinforce your point - I have worked with people in the past, mostly older, that struggled a lot with Git when all they were trying to do was something simple like commit some static files generated from third-party software to my project. These people only needed the bare minimum (stage, commit, push) of Git yet found themselves baffled and fighting with the tool because of all the possibilities and things it could do that they didn’t really need.
  - Piskvorrr 8y ago
    There's a fair amount of tools capable of manipulating a Git repo, not all of which are `/usr/bin/git`. "Everybody must use this complex CLI power tool, therefore people struggle" is simply untrue here, in the premise.
oppositelock 8y ago
Try managing a massive set of inter-dependent repositories too big for a mono-repo with git, then you will know "hard to use". Your only real choice in this case is submodules, and those bring in an additional layer of pain.

Nasrudith 8y ago

Conceptual problems themselves may be shallow, deep, or both. Wrapping machine code with assembly makes it easier to use but doesn't fix nasty issues with lack of memory boundaries. Conceptually programmers having to mentally convert every line is poor ergonomics and will reduce speed and increase errors. Going to labels instead of numbers is an improvement even if shallow and able to improved upon further.

opcenter 8y ago

I took a quick look at the list of commands and they looked so similar to the primary git commands I use that it seemed like a waste. Better to just learn how to use git.

chx 8y ago

In my own experience, https://www.sbf5.com/~cduan/technical/git/ https://www.sbf5.com/~cduan/technical/git/ makes all the difference in this world. The main complaint still remains: the CLI UX (yes, CLI has a user experience!) is really bewildeirng because switches change commands in really, really significant ways, so much so they ought to be different commands. And operations have totally different ways to express "work with repo only" "work with index" "work with working tree". And then git reset does not touch your working files but git reset --hard ruins your day unless you build a safety net: https://gist.github.com/chx/85db0ebed1e02ab14b1a65b6024dea29 https://gist.github.com/chx/85db0ebed1e02ab14b1a65b6024dea29 Back to the tutorial: > you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something. > Half of the existing resources on Git, unfortunately, take just that approach: they walk you through which commands to run when, and expect that you should do fine if you just mimic those commands. The other half does go through all the concepts, but from what I have seen, they explain Git in a manner that assumes you already understand how Git works.

rawoke083600 8y ago

Well I'm definitely not a git expert ( i guess I should just invest more time into it). But was wondering the other day. Isn't GIT "as good" as its(source control) going to get ? Giving the problem its trying to solve:source control,distributed teams/repo's, branching etc... I mean what comes after GIT ?

cyphar 8y ago
There are some projects that aim to improve the merging model of Git, such as pijul[1]. Git uses "three-way merge" and it is fairly well-known that the repository state you end up with for non-fast-forward merges (merges that need merge commits) is not necessarily well-understood in all cases. Pijul uses a more efficient algorithm that has well-understood merge characteristics, and is designed around patches not repository states (which means that conceptually patches are the core -- rather than in Git where patches appear to be core but are actually all generated on-the-fly). It should be noted that Git was not unique in its design. There were many source-control systems that had the same model that pre-dated Git, it's just that Git was fast and significantly easier to use than the other tools. The previous tools would not have been usable for developing Linux, and so Git was obviously necessary. [1]: https://pijul.org/ https://pijul.org/
- rawoke083600 8y ago
  git was easier to use :) - thanks will check it out

qznc 8y ago

I'm now roughly one year into my experiment to not use the index. I made some aliases to do that. My conclusion is: The index is unnecessary complexity. Amend to commits instead. My aliases do not work cleanly, so I don't want to advertise them. Still, a git wrapper which removes the index would be an improvement. By the way, can we still call it "porcelain" or is that outdated?

maxxxxx 8y ago
"The index is unnecessary complexity. Amend to commits instead." How is that easier than the index and how do you undo changes?