6 ms·

I disagree. It's one of the best command line tools I've seen. It detects errors, gives you suggestions and you can get along with a few basic commands. Yes, th

I disagree. It's one of the best command line tools I've seen. It detects errors, gives you suggestions and you can get along with a few basic commands. Yes, there are multiple steps, but that's okay because it can't figure out your intentions. Look: http://imgur.com/xY8dKWD http://imgur.com/xY8dKWD no verbosity here and this is 99% of my git workflow. Working in a team is more tricky, but you should use and IDE with built in git support. If you want to see a bad command line tool, try FFMPEG.

dom0 10y ago
The progress displays for pushing and fetching are a bit verbose in my opinion, but otherwise I mostly agree.
drivingmenuts 10y ago
FFMPEG is a case of a tool trying to do too much, although, trying to break it out into separate tools would probably be worse.
- bobbyi_settv 10y ago
  Ffmpeg isn't a tool. It's a library to be used by programs who work with video and audio files. It has lots of features because different applications need different features. The ffmpeg command line program is basically a demo that exposes every one of those features directly. Having it "do less" would defeat the point.
zajd 10y ago
It's simplicity and ubiquity are the only reason we keep seeing absurd programs like Gitless put forth. Imagine if someone came out with someone that "fixed the warts of QT" that was just a wrapper around QT. It's a joke. It's coffeescript vs javascript all over again and we saw how that played out. Don't like how git works? contribute. Don't make some stupid command line utility that just adds another entire layer of abstraction on top because people don't want to take an hour to read about git internals.
- sametmax 10y ago
  Now, this is a UI problem, you don't need to change git, you just need something higher level. Git is fine the way it is, but it targets power users. Most people don't need that power. In that sense, gitless has a proper approach even if I don't like the result.
  - zajd 10y ago
    I tend to agree with you that most people don't need that power but I think the problem is just that it IS a CLI interface, not that it's a particularly bad one. A GUI is the perfect tool to deal with discoverability and providing an easier interface for non-technical users. A CLI wrapper is just making things more confusing. I don't really understand what problem gitless seems to be solving...
    - weberc2 10y ago
      I disagree; `hg` is a CLI as well, but it's far simpler and safer than `git`. That said, I have far more experience with git than hg. Further, gitless itself is a cli, and it's also simpler than git.
      - zajd 10y ago
        If simplicity was the goal of command line interfaces they wouldn't exist. This is not ls or cat, nor is it trying to be. hg might have a better CLI than git, but it still doesn't justify something like gitless. You need a really compelling reason to layer another level of abstraction on top of git and from what I can tell, having branches be full sets of working files isn't really a good enough reason to make that switch. Where are the improvements in Gitless exactly? Pretty telling they don't even list them in anywhere.
      - ori_b 10y ago
        I have experience with both daily, and I mostly just don't notice any meaningful difference. Especially with the bookmark extension.
      - deleted 10y ago
sametmax 10y ago
This is not objective. Git CMD has terrible flaws that are easily spotted as soon as you start teaching git, because you can see people struggling on difficulties purely created by a bad design. As a professional trainer, here are the most commong problems: - git checkout does so many different things. Git check file, git checkout branch, git checkout commit all do different stuff, and don't get me started on the option flags. - git is context dependant. If you don't know the context, espcially the state your repo is in, you will struggle. And nothing in the tool gives you enough context if you don't explicitly ask for it, which supposes you need to know you need it, and what "it" is. - branch switching is a hard. see article. - stashing is dangerous. I've seen many students loosing work with a stash pop requiring a merge which ended badly. - the whole syntax is impossible to discover, even for very common tasks: git checkout HEAD^ /file/path, git rm --cached, etc. - git assumes you know what you are doing. Which means it let you destroy history with rebase, loose stuff with stash pop, create detached head, make force push, and all it all put yourself in many situations a beginer won't understand, and above all won't need. Now I don't blame git designers for those. They made the tool they wanted to use. What we need is a good UI on top of that. It can solve 99% of those problems. The github one is not so bad compared to all the ones I tried (yes I tried yours), but it's still not it. What you need is someone that look at the most done tasks and questions, and provide safe, fast buttons for that.
- chousuke 10y ago
  Let me just start by saying that while gitless seems fine, it tries to hide the index and thus encourages bad habits in git users. The index is by far one of the best features git has in comparison to other VCS, and trying to hide it because it can be confusing to users is doing them a disservice. EDIT: editing this to expand on why I think the index is essential: Being able to use the VCS tool to fashion a commit separately from what is in the worktree allows you to create changesets that make sense, instead of them being "this is what happened". Exact history is not interesting, it is the logical progression of the codebase (via changes applied to it) which really matters. Furthermore, when resolving conflicts, the index is extremely useful because you can work through a conflict (which often can span multiple files) piece-by-piece and easily tell whether you've already fixed everything, run diffs on what's resolved and what isn't, etc. I find myself missing the index whenever I need to do anything nontrivial with other VCS (which is most often Subversion) I've seen some people argue that they don't want to commit something that has not been tested, but I don't understand this argument. Why would you test something that isn't committed? Committing (or even pushing) something does not mean the code is instantly in production, but it means you have an unambiguous way to refer to what is being tested, instead of whatever state your worktree and system happened to be in. How could you be sure you're really testing what you will be committing? Certainly, creating separate commits after-the-fact can cause commits where the tests don't pass, but it's up to you to decide whether the merge points are what should be tested, or each individual changeset. Let's go through that list - git checkout does one thing: it updates your worktree to match whatever you want to check out, be that a commit, a branch (which actually is just a named commit) or a file in a branch. Why is this difficult for beginners, and how would you refactor/name the operations so that they make sense? - I'm not sure what you mean with context-dependency. Obviously it's context-dependent in that your worktree and repository may be in a state where certain commands do different things eg. because they have the current checked out branch as an implicit parameter. I don't think it's at all different from most other VCS - I'm not sure I'm convinced by the article's argument that branch switching is hard, but I guess I'll grant that. - Huh. I don't use stash that often, so this is a maybe. Teach people to use stash apply instead? - git rm --cached is weird, but mostly because git can't choose just one thing to call the index. - You can never accidentally destroy history with a rebase. Nothing short of manually wiping files destroys history in git once something has been committed. I don't really see why detached heads would be a problem (just create a branch?) and if you force push, you're basically telling git "I know what I'm doing, shut up" in which case the tool doesn't assume you're an idiot and will do what you want. You can't call it bad UI when you explicitly have to use a --force flag to do potentially destructive things. Not being able to do it at all is worse. Really though, other than minor gripes with terminology and maybe sometimes confusing command line switches, what is a good (hypothetical) UI for git that doesn't just ignore all the good things?
ms4720 10y ago
Or the original syntax for tar
- Pxtl 10y ago
  Obligatorily: https://m.xkcd.com/1168/ https://m.xkcd.com/1168/
nerdponx 10y ago
You don't think that the "git push" output includes a lot of verbose tehnical junk not meaningful to most users?
- kowdermeister 10y ago
  Not really, while I'm not sure what 50% of that means, it's just reassuring that after push I see that 5 lines and a percentage counter. I can also copy the commit hash and refer to it in a ticket.
  - oblio 10y ago
    The first 5 lines in that image could be replaced with a simple progress bar and no one, except for git developers, would lose anything worth keeping. That stuff in a normal CLI tool would only pop up if you use --verbose/-v, it's almost irrelevant to the average user.

dom0 10y ago

The progress displays for pushing and fetching are a bit verbose in my opinion, but otherwise I mostly agree.

drivingmenuts 10y ago

FFMPEG is a case of a tool trying to do too much, although, trying to break it out into separate tools would probably be worse.

bobbyi_settv 10y ago
Ffmpeg isn't a tool. It's a library to be used by programs who work with video and audio files. It has lots of features because different applications need different features. The ffmpeg command line program is basically a demo that exposes every one of those features directly. Having it "do less" would defeat the point.

zajd 10y ago

It's simplicity and ubiquity are the only reason we keep seeing absurd programs like Gitless put forth. Imagine if someone came out with someone that "fixed the warts of QT" that was just a wrapper around QT. It's a joke. It's coffeescript vs javascript all over again and we saw how that played out. Don't like how git works? contribute. Don't make some stupid command line utility that just adds another entire layer of abstraction on top because people don't want to take an hour to read about git internals.

sametmax 10y ago
Now, this is a UI problem, you don't need to change git, you just need something higher level. Git is fine the way it is, but it targets power users. Most people don't need that power. In that sense, gitless has a proper approach even if I don't like the result.
- zajd 10y ago
  I tend to agree with you that most people don't need that power but I think the problem is just that it IS a CLI interface, not that it's a particularly bad one. A GUI is the perfect tool to deal with discoverability and providing an easier interface for non-technical users. A CLI wrapper is just making things more confusing. I don't really understand what problem gitless seems to be solving...
  - weberc2 10y ago
    I disagree; `hg` is a CLI as well, but it's far simpler and safer than `git`. That said, I have far more experience with git than hg. Further, gitless itself is a cli, and it's also simpler than git.
    - zajd 10y ago
      If simplicity was the goal of command line interfaces they wouldn't exist. This is not ls or cat, nor is it trying to be. hg might have a better CLI than git, but it still doesn't justify something like gitless. You need a really compelling reason to layer another level of abstraction on top of git and from what I can tell, having branches be full sets of working files isn't really a good enough reason to make that switch. Where are the improvements in Gitless exactly? Pretty telling they don't even list them in anywhere.
    - ori_b 10y ago
      I have experience with both daily, and I mostly just don't notice any meaningful difference. Especially with the bookmark extension.
    - deleted 10y ago

sametmax 10y ago

This is not objective. Git CMD has terrible flaws that are easily spotted as soon as you start teaching git, because you can see people struggling on difficulties purely created by a bad design. As a professional trainer, here are the most commong problems: - git checkout does so many different things. Git check file, git checkout branch, git checkout commit all do different stuff, and don't get me started on the option flags. - git is context dependant. If you don't know the context, espcially the state your repo is in, you will struggle. And nothing in the tool gives you enough context if you don't explicitly ask for it, which supposes you need to know you need it, and what "it" is. - branch switching is a hard. see article. - stashing is dangerous. I've seen many students loosing work with a stash pop requiring a merge which ended badly. - the whole syntax is impossible to discover, even for very common tasks: git checkout HEAD^ /file/path, git rm --cached, etc. - git assumes you know what you are doing. Which means it let you destroy history with rebase, loose stuff with stash pop, create detached head, make force push, and all it all put yourself in many situations a beginer won't understand, and above all won't need. Now I don't blame git designers for those. They made the tool they wanted to use. What we need is a good UI on top of that. It can solve 99% of those problems. The github one is not so bad compared to all the ones I tried (yes I tried yours), but it's still not it. What you need is someone that look at the most done tasks and questions, and provide safe, fast buttons for that.

chousuke 10y ago
Let me just start by saying that while gitless seems fine, it tries to hide the index and thus encourages bad habits in git users. The index is by far one of the best features git has in comparison to other VCS, and trying to hide it because it can be confusing to users is doing them a disservice. EDIT: editing this to expand on why I think the index is essential: Being able to use the VCS tool to fashion a commit separately from what is in the worktree allows you to create changesets that make sense, instead of them being "this is what happened". Exact history is not interesting, it is the logical progression of the codebase (via changes applied to it) which really matters. Furthermore, when resolving conflicts, the index is extremely useful because you can work through a conflict (which often can span multiple files) piece-by-piece and easily tell whether you've already fixed everything, run diffs on what's resolved and what isn't, etc. I find myself missing the index whenever I need to do anything nontrivial with other VCS (which is most often Subversion) I've seen some people argue that they don't want to commit something that has not been tested, but I don't understand this argument. Why would you test something that isn't committed? Committing (or even pushing) something does not mean the code is instantly in production, but it means you have an unambiguous way to refer to what is being tested, instead of whatever state your worktree and system happened to be in. How could you be sure you're really testing what you will be committing? Certainly, creating separate commits after-the-fact can cause commits where the tests don't pass, but it's up to you to decide whether the merge points are what should be tested, or each individual changeset. Let's go through that list - git checkout does one thing: it updates your worktree to match whatever you want to check out, be that a commit, a branch (which actually is just a named commit) or a file in a branch. Why is this difficult for beginners, and how would you refactor/name the operations so that they make sense? - I'm not sure what you mean with context-dependency. Obviously it's context-dependent in that your worktree and repository may be in a state where certain commands do different things eg. because they have the current checked out branch as an implicit parameter. I don't think it's at all different from most other VCS - I'm not sure I'm convinced by the article's argument that branch switching is hard, but I guess I'll grant that. - Huh. I don't use stash that often, so this is a maybe. Teach people to use stash apply instead? - git rm --cached is weird, but mostly because git can't choose just one thing to call the index. - You can never accidentally destroy history with a rebase. Nothing short of manually wiping files destroys history in git once something has been committed. I don't really see why detached heads would be a problem (just create a branch?) and if you force push, you're basically telling git "I know what I'm doing, shut up" in which case the tool doesn't assume you're an idiot and will do what you want. You can't call it bad UI when you explicitly have to use a --force flag to do potentially destructive things. Not being able to do it at all is worse. Really though, other than minor gripes with terminology and maybe sometimes confusing command line switches, what is a good (hypothetical) UI for git that doesn't just ignore all the good things?

ms4720 10y ago

Or the original syntax for tar

Pxtl 10y ago
Obligatorily: https://m.xkcd.com/1168/ https://m.xkcd.com/1168/

nerdponx 10y ago

You don't think that the "git push" output includes a lot of verbose tehnical junk not meaningful to most users?

kowdermeister 10y ago
Not really, while I'm not sure what 50% of that means, it's just reassuring that after push I see that 5 lines and a percentage counter. I can also copy the commit hash and refer to it in a ticket.
- oblio 10y ago
  The first 5 lines in that image could be replaced with a simple progress bar and no one, except for git developers, would lose anything worth keeping. That stuff in a normal CLI tool would only pop up if you use --verbose/-v, it's almost irrelevant to the average user.