7 ms·

It's a shame how poor the command-line usability of the git client is. Commands are poorly named and often do the wrong thing. It's really hard to explain to

• adrianN 7y ago
  The git storage structure is not that difficult. People could implement their own compatible clients on top of it with a quite different UI. That there is nothing that overtook git as UI in popularity seems to be an indication that the interface is not as bad as many people claim.
  • CydeWeys 7y ago
    People have added better UIs on top of git. The problem is they don't come installed by default out of the box, and unless everyone else you work with is using them too it becomes quite hard for you to communicate properly over git issues (especially in writing development workflow docs). hg has a better UI out of the box, and is notably easier for new users to pick up and become productive with. You're underestimating how much inertia is created simply by being the out-of-the-box default, and how hard that inertia is to overcome even by better alternatives.
  • IcePic 7y ago
    GoT (gameoftrees.org) did just that. Built another tool similar but not same, using the same storage method underneath.
  • wbl 7y ago
    I use magit and it is a lifesaver.
  • weberc2 7y ago
    Not sure who "many people" are, but no one in this thread is claiming that git is unworkable, only that it is confusing. A collaboration tool like git is highly subject to network effects. The usability delta between git and a given alternative must be very, very high before people will leave git for the alternative. Ergo, git can be both awful and "good enough" to have a majority market share (although I don't think anyone is even saying git is awful in this thread).
• icedchai 7y ago
  Complain about Git, but there are commercial alternatives (I'm thinking of Perforce) that make even less sense.
  • CydeWeys 7y ago
    And there are alternatives that make better sense, too. But the existence of something even worse doesn't excuse something that is merely bad. And git is so much more widely used that its total overall harm on developer productivity is worse.
    • icedchai 7y ago
      You really only need to know a half dozen commands for basic productivity. I started in the late 90's when cvs was popular. Then we moved to svn. You had productivity issues of all sorts, mainly with branching and merging.
  • magduf 7y ago
    >but there are commercial alternatives (I'm thinking of Perforce) that make even less sense. Have you ever worked with Rational ClearCase? It's a true horror show.
    • pjmlp 7y ago
      I have during several occasions in the past (up to 2007), and while it is a monster, I still felt more productive than using git nowadays.
      • panpanna 7y ago
        Remember, back then companies had to hire dedicated Clear case engineers to get things working properly.
        • pjmlp 7y ago
          You mean just like we have to reach out to IT to sort out git issues for anyone that strays outside the path?
• celticninja 7y ago
  Thing is most of these can simply be fixed using an alias, its not that hard to remember '-b' creates a new branch, but 'gcb' followed by the branch name I want is probably easier, however maybe someone wants 'gcob' or just 'cob', thats what Alias is for.
  • CydeWeys 7y ago
    It'd be better to not have to do these things at all, i.e. if the commands just made sense out of the box. These are problems that every single person learning git has to figure out and then come up with their own solutions for.
    • glennpratt 7y ago
      I use git with no aliases and have forever. I came from SVN, and myself and the entire team I worked with at the time enjoyed the transition and had very few issues. So much of this drama seems propped up on things that just aren't that difficult.
  • weberc2 7y ago
    I don’t think those examples were meant to be an exhaustive list of git’s UI warts. There are many that are harder to remember and creating aliases and functions for each of them require building a full alternative UI. For example, how do you see all of the changes in a branch (IIRC the equivalent of ‘hg diff -b branch-name’)? How do you see the changes for just one commit (I.e., ‘hg diff -c $commit’). These things are all feasible in git, but I can never remember the incantation, so I have to Google every time. I haven’t used hg in 5 years and I still have an easier time remembering those commands.
    • samatman 7y ago
      The changes for just one commit are `git diff $commit`, while the changes for a branch are `git diff $branch`. While there are a metric ton of things which are confusing about git, this was perhaps not the greatest example.
• johnmaguire2013 7y ago
  A small correction... `git branch [branchname]` creates a branch without switching to it. `git checkout -b [branchname]` creates a branch and checks it out. And `git reset --hard` will also discard changes. (Arguably, this is better than `git reset` discarding local changes, as it is more explicit.)
  • jacquesm 7y ago
    Your comment only makes the GPs point stronger.
    • linuxftw 7y ago
      I disagree. I think the commands are intuitive and work perfectly for the system. It's very expressive, but it all makes sense once you've learned it. git is a tool. Different tools take different amounts of time to master. People should probably spend some time formally learning git just as one would formally learn a programming language.
      • wbl 7y ago
        Other version control systems don't have this problem as much.
        • linuxftw 7y ago
          And where are they now? If you're not using git as source control at this point, I wouldn't even consider downloading your project.
          • jacquesm 7y ago
            That's roughly the same as saying that you won't eat the food prepared by a chef if they don't use your favorite brand of knife. You've diminished the value of your previous comment substantially with this one.
          • weberc2 7y ago
• weberc2 7y ago
  I can still never remember the git equivalents for things like ‘hg log -r default:feature-branch’ or ‘hg diff -c <commit>’. People who haven’t used Mercurial really have no idea how pleasant a VCS interface can be.
  • jcranmer 7y ago
    The latter is 'git show <revision>', show being one of those fun commands that does a bazillion different things depending on what the argument is. My fun example of what's-the-git-command is 'hg cat -r <commit> <path>', whose git commit equivalent is another variant of 'git show'
• codesnik 7y ago
  I'd argue that naming and usability of git is actually very-very up to the point. Naming reflects not the what you want to do on high level, but what you want to do with underlying data structure and checked out files. This could be seen as weakness or unnecessary problem for newbies, but if you work with branches or in multiuser environment, you inevitably would run in some complex and problematic conflict, and then "magical tools" would leave you with a mess, while I've yet to see problem with git repository I couldn't solve. I've actually taught how to use git to many teams, and I always start with merkle trees. They are actually easy to grasp even for designers and other nontechnical people, and could be explained in 10 minutes with a whiteboard. And then suddenly git starts to totally make sense, and I'd dare to say, become intuitive.
• asdkhadsj 7y ago
  I don't even know what `git checkout HEAD * ` does lol. Does it just checkout the current branch to the HEAD of that branch? I can never seem to guess what things do in Git, and I consider myself fairly comfortable with the core concepts of Git. Having written many types of append-only / immutable / content address data systems (they interest me), you'd think Git would be natural to me. While the core concepts are natural, Git's presentation of them is not.. at least, to me. edit: formatting with the * .
  • zhynn 7y ago
    git checkout <reference> [<files>] so, that says, copy all of the files out of the current branch at the current commit into the local dir. What this will do in practice is "discard current changes to tracked files". So If i had files foo, bar, baz, and I had made edits to two of them, and I just want to undo those changes, that's what checking out * from HEAD does. It doesn't however delete new files you have created. So it doesn't make the state exactly the same. So why not just git checkout HEAD? Well, you already have HEAD checked out (you are on that branch), so there's nothing for git to do. You want to specify that you want to _also_ explicitly copy the tracked file objects out also. It's kind of like saying "give me a fresh copy of the tracked files". The confusing thing is that in practice it is "reverting" the changes that were made to the tracked files. But `git revert` is the command you use to apply the inverse of a commit (undo a commit). One of the more confusing aspects of git is that many of the commands operate on "commits" as objects (the change set itself), and some other commands operate on files. But it's not obvious which is which.
    • jolmg 7y ago
      That command would only discard changes to non-hidden files though, because * typically doesn't expand to hidden files. I think the command one really wants in these cases is git reset --hard
      • CydeWeys 7y ago
        That throws away everything though, whereas `git checkout HEAD *` only throws away stuff in the current directory and below, or you can pass exact filepaths to be surgical about which changes exactly you're reverting. This is what I use it for most often -- reverting some, but all, edits.
• jolmg 7y ago
  > It's a shame how poor the command-line usability of the git client is. In comparison to an average CLI program's usability, I think git's got a very good one. It's not perfect, but I think saying it's "poor" is really exaggerating the problems. In particular, I love how well it does subcommands. You can even add a script `git-foobar` in your $PATH and use it as `git foobar`. It even works with git options automatically like `git -C $repo_dir foobar`. > It's really hard to explain to new users why you need to run `git checkout HEAD * ` instead of `git reset` as you'd expect Why would you ever do `git checkout HEAD * ` instead of `git reset --hard`? The only difference is that your checkout command will still leave the changes you've done to hidden files, and I can't think that's ever any good. > why `git branch [branchname]` just switches to a branch whereas `git checkout -b [branchname]` actually creates it If you think those behaviors should be switched, good, because they are. EDIT: How did you manage to add the asterisk to the checkout command in your post so that it's not interpreted as italics without adding a space after it?