8 ms·

Well, the biggest UX fail for me on git was the ambiguous and counter intuitive use of the command `checkout`. I've heard the latest versions of Git mitigate th

• grumpydba 7y ago
  In 5 years from now, will there still be svners?
  • umvi 7y ago
    Maybe not, but "checkout" still conjures up imagery of libraries, where you get permission to use materials. You "checkout" a book in order to read it. So in that sense, it sort of makes sense to "checkout" a branch. But imagine bringing a book to a librarian and saying "hello, I'd like to checkout this book" and the librarian says "ok" and snatches the book from your hands and throws it into a furnace and tells you not to worry because she will order a new copy to be put on the shelf.
    • rumanator 7y ago
      > because she will order a new copy to be put on the shelf. Calling git checkout is a request to check out a specific version of the repository (or individual files) from a specific point in the repository's history. If you ask the librarian "hello, I'd like to checkout this May 23rd issue of this magazine" then you can't act surprised that the librarian returns from the library's repository with the issue of the magazine released in May 23.
  • onei 7y ago
    Sure there will. I doubt many people would use SVN for a new project, but plenty of old projects still use them. It's not always simple to migrate SVN to Git especially if you want to maintain the history.
  • jackewiehose 7y ago
    You could ask the same question about today and the answer would be yes. Why should that change in the next 5 years? (speaking out of experience - I try to sweet talk my coworkers about git for more than 5 years)
  • beagle3 7y ago
    In 2010, I joined a project that was still using svn; so I used git-svn and hardly even noticed svn; and my colleagues would often ask me about project history because many things that were easy to check in gut weren’t easy in svn. Also, I had offline history and everything and they didn’t but thanks to git’s compressed storage, it didn’t take more disk space.
  • umanwizard 7y ago
    FreeBSD uses SVN, and it is unlikely that they would ever move to git or mercurial, since they try to minimize the amount of copyleft code in the base system (e.g., they moved to Clang instead of GCC a few years ago)
    • throw0101a 7y ago
      Some OpenBSD devs may have the answer: * http://gameoftrees.org/ http://gameoftrees.org/
      • umanwizard 7y ago
        Cool, I vaguely remember having seen this on HN but I either never looked at it or forgot. Thanks!
    • _-david-_ 7y ago
      FreeBSD is looking into moving to Git. https://wiki.freebsd.org/Git https://wiki.freebsd.org/Git
      • umanwizard 7y ago
        Interesting... why?
  • pjc50 7y ago
    I still have some files in a CVS repository. Never shared with anyone, and I never felt the need to upgrade it. Doesn't make me a "CVSer".
• inetknght 7y ago
  `git checkout` does more than one thing and to trivialize it to a single sentence won't give it the value it deserves.
  • umvi 7y ago
    > `git checkout` does more than one thing And therein lies the problem. Ambiguous commands are not good for UX.
  • jfim 7y ago
    They're mapped to different verbs in mercurial, which helps the user. git checkout somefile (revert a file) -> hg revert git checkout somebranch (switch to a branch) -> hg update somebranch git checkout -b somebranch (create a new branch) -> hg branch somebranch
    • tux1968 7y ago
      To be fair, there is "git branch <somebranch>" to create a new branch. Then you'll have to checkout that branch if you want to use it. Your third git example above just combines those two operations into a single command as a convenience.
      • jfim 7y ago
        That's true, but from my perspective it makes more sense to attach combined operations to the first operation, not the following one. For example, the equivalent of git fetch (fetch remote code without updating the working copy) is hg pull, while the equivalent of git pull (fetch remote code and update the working copy) is hg pull -u (pull, then update). In my opinion, and this can be debated, is that it makes more sense to attach it to the first operation, since one would look at the documentation of the first command (how do I fetch the remote code?) then see that the working copy can be updated as part of that. The git documentation does mention git checkout -b as part of the git branch documentation, though. Maybe this is just a rant against git though, at the end of the day, as long as work gets done, use whatever tools work for you. :-)
    • 7y ago
• mehrdadn 7y ago
  Hm, I was hoping there would be higher-level differences than that. Like maybe the notion of having an index and staging area would be fundamentally different (or absent), or the notion of committing locally and pushing remotely would be fundamentally different, or something like that. Which is not to say command names aren't also confusing in git ('git add' to remove a file is my favorite), but they're not really where I imagined the substantial differences would lie?
  • deleted 7y ago
    [deleted]
  • jcranmer 7y ago
    > the notion of having an index and staging area would be fundamentally different (or absent) Mercurial indeed lacks a staging area > the notion of committing locally and pushing remotely would be fundamentally different If you enable phases, it does. By default, all local commits are "draft" commits, which can have history edited. But when you push to (or pull from) a public repository, it becomes a "public" commit, and Mercurial will refuse to edit those commits. There's also a "secret" phase, which Mercurial will refuse to push to a public repository. You can also configure whether or not remote repositories are public or not. The other fun feature is changeset evolution: when you rebase a changeset, Mercurial will keep the original changeset around with a link between the old and new versions of it. If you push the rebase remotely to a repository that previously had the original, Mercurial will tell people that changesets based on the original also need to be rebased when they pull it, and the history information will let them use the regular rebase flow to do it. Too bad BitBucket is dropping hg repos...
    • doubleunplussed 7y ago
      > Mercurial indeed lacks a staging area I'm sure someone will dispute that it is the same as the staging area, but mercurial does have the ability to only include some things in commits, and I use it daily. I admit I have no idea how it works on the command line, but in tortoisehg I can select individual files and hunks thereof to add to a commit (screenshot: https://imgur.com/ErPEjSN https://imgur.com/ErPEjSN). It's my impression that loads of people use this feature and somehow don't notice it exists, and will openly agree that mercurial lacks a staging area. My opinion is that defaulting to including changes from all files previously committed is such a sensible default that it makes the feature so seamless that people forget it exists even whilst using it. Kinda like how people from the US think you can't turn left on red in Australia (equivalent of right on red in the US). You can, but the existence of slip lanes everywhere its allowed mean you don't actually face the red light when doing so. This hides it so effectively that I've seen several people complaining that they can't turn on red, not noticing that they do it every day.
• koolba 7y ago
  Anytime the lay description of a command involves “when operating on a ...” you know you have a problem.
• linsomniac 7y ago
  It seems like "one sentence or less" is an unreasonable demand in this case. But, if you're up for it, can you describe for an SVNer what the benefit of hg over svn is, you know, in one sentence or less? :-)
  • pseudalopex 7y ago
    It works offline.
  • alwillis 7y ago
    SVN’s main commands mean the same thing in Mercurial with the added bonus of being a DVCS.
• rumanator 7y ago
  > Just attempt to describe to an SVNer what `git checkout` does in one sentence or less. It checks ou a version of the repository from a specific point in its history?
  • Lazare 7y ago
    That is not a good description of what checkout does. :) That is one of the things checkout can do, if you pass it a commit hash as the only argument. If you pass it a branch name, it does something quite different (a branch does not represent a specific point). If you pass it the path of a file, it does something quite different again. And depending on what extra flags you pass it, it'll do different things again, including creating a new branch, which is entirely different again.
    • rumanator 7y ago
      > That is one of the things checkout can do, if you pass it a commit hash as the only argument. No, that's all that git checkout does: check out prior commits. Passing a branch name actually points to the branch HEAD, which marks a specific commit made in a specific point in time. Passing a tag also does the same thing: check out a specific commit. Passing a file path does the exact same thing: check out the contents of a specific file as saved in a specific commit represented by the branch HEAD. It's the exact same thing as git checkout <branch> or git checkout <tag>, except it does not update the whole working copy. > And depending on what extra flags you pass it, it'll do different things again, including creating a new branch, which is entirely different again. That's false as well. Running git checkout -b may be syntactic sugar for git branch && git checkout but what you are asking git to do, again, is to checkout a specific commit that represents the state of the repository at a specific point in time. That's it. All git does is enable users to navigate and edit a graph of commits. It takes a poor mental model of git and a poor understanding of what git does to fail to understand that all git checkout does is checkout a commit done somewhere in the past.
• chousuke 7y ago
  git checkout puts files from the repository into your working directory. For convenience, it will also update the HEAD ref if you check out the full contents of a branch. I'm not sure what's so confusing about it. Are people thinking of their entire git workdir as the repository? I suppose the fact that .git is often in the same directory as the checkout might lead to people not thinking of them as separate entities.
  • lilyball 7y ago
    > For convenience, it will also update the HEAD ref if you check out the full contents of a branch. Not quite accurate. From the root of the repo, `git checkout foo -- .` will checkout the entire contents of the branch without updating HEAD.
  • comex 7y ago
    > For convenience, it will also update the HEAD ref if you check out the full contents of a branch. And updates the index. And sometimes it gets files from the index instead of a commit. From a workflow perspective, "switch to working on a different branch", "copy some files into the working tree from a different commit", and "resolve all merge conflicts in this file in favor of 'ours' or 'theirs'" are three very different operations. From a low-level perspective they're somewhat similar, but not the same.