12 ms·

I believe people have a hard time with Git because it's simply not user friendly. Once you've grokked a handful of essential concepts, Git becomes easy to use p

• tenken 9y ago
  I would argue git is not novice friendly. It's original intended audience was not lay people learning how to program. It was seasoned kernel developers working on the Linux source tree. It (made) assumption(s) it's userbase were experts in their domain. > Naturally, people get confused and reach for the docs, which are filled with even more newbie-hostile terms like 'tree-ish', 'hunks' and 'refspec'. Yup, these are everyday terms for an expert in computer science and algorithm and software design. If I were a student in medical school I'd expect the books I'm learning from to use the expert terminology of my domain of study when describing the body and functions and not laymans terms such as -- "the hip bone is connected to the Red-Squishy-Thing .... ELI5 me plz" ... I agree git is complex, and can be scary. But building software is a complicated process rife with engineering pitfalls! If one is unable to properly use the Lego building blocks, then stay away :D I do believe when used properly, a productive Git workflow using Branches and sane commit messages can help to give Visibility to your project development life-cycle and help to make an issue or task on a project understandable in scope and difficulty by segmenting ones development work into comprehensible mergable pieces (branches) within the project.
  • sneak 9y ago
    I know a lot of CS experts who go weeks without saying any of “hunks”, “refspec”, or “tree-ish”. You are making excuses for needless, opaque jargon.
    • rileymat2 9y ago
      I was a pretty good CS student and do not remember any of those terms outside of git.
      • jwilk 9y ago
        Out of these, only “hunk” is a somewhat common term. “refspec” and “tree-ish” are obscure and git-specific.
  • masklinn 9y ago
    > I would argue git is not novice friendly. Git is not friendly period, it's a huge pile of leaky abstraction and incoherent commands, the "high-level UI" being closer to shortcuts for common sequences of lower-level operations than an actual abstraction. It simply can not be understood "top-down". > It's original intended audience was not lay people learning how to program. It was seasoned kernel developers working on the Linux source tree. It (made) assumption(s) it's userbase were experts in their domain. Domain expertise has nothing to do with it, unless the domain is playing with footguns and expertise is having toes left. > I agree git is complex Git is not complex, it just has a very, very shitty API.
    • microtherion 9y ago
      Git and its documentation are a prime example of what languagelog calls "Nerdview": http://languagelog.ldc.upenn.edu/nll/?p=276 http://languagelog.ldc.upenn.edu/nll/?p=276 people with any kind of technical knowledge of a domain tend to get hopelessly (and unwittingly) stuck in a frame of reference that relates to their view of the issue, and their trade's technical parlance, not that of the ordinary humans with whom they so signally fail to engage.
      • acqq 9y ago
        Some example of "wrong frame of reference" when "ordinary humans" even include "all other programmers not in his own team": https://blogs.msdn.microsoft.com/oldnewthing/20110512-00/?p=10683 https://blogs.msdn.microsoft.com/oldnewthing/20110512-00/?p=... I know a few "nerds" like that. They tend to give technically completely correct but misleading or dangerous or simply unusable answers.
      • u801e 9y ago
        Could this principle not also apply to any journal/conference paper? For the most part, one has to have a basic understanding of the field, and read through prior research to have a better understanding of the current problem domain. We don't expect journal papers to be written at an elementary level. But people who make an effort to get themselves up to speed in the area can understand them. The same thing applies to a lot of tools that are used in software development.
  • jejones3141 9y ago
    I've always been puzzled about why programmers aren't considered worthy of tools designed with thought given to user interface.
    • masklinn 9y ago
      Because it's hard demanding proper UI when you intuitively know you couldn't build one to save your life, not only does it feel like whining, if it spreads you might be out of a job.
    • seanmcdirmid 9y ago
      Very few dev tool organizations employ dev-oriented UX designers. It’s mostly the developers and PMs themselves doing UX design, when they have been evaluated and promoted based on other things (coding, project management).
• fulafel 9y ago
  Yep. It's puzzling how it won over hg. Linux is a powerful mannequin I guess.
  • throw7 9y ago
    hg was slow. if linus, at the time, felt otherwise, it might have been hg that "won" when bitkeeper was dropped.
    • coldacid 9y ago
      If Linus, at the time, felt otherwise, git probably wouldn't have been created.
  • Noumenon72 9y ago
    One of the nice things about my current job is they are still with hg -- we are going to have to switch to start using Bitbucket. I expect Git will be easier to understand the second time around, but I'll never forgive it for making itself so hard to use.
    • lozenge 9y ago
      Bitbucket supports mercurial.
      • kyrra 9y ago
        Bitbucket Server (on premesis) does not support mecurial. https://confluence.atlassian.com/confeval/development-tools-evaluator-resources/bitbucket/bitbucket-bitbucket-server-mercurial-support https://confluence.atlassian.com/confeval/development-tools-...
  • IshKebab 9y ago
    I suspect things would have gone differently if Github supported Mercurial. Also Git is now more or less locked in to terrible naming for its actions - yes they could be renamed but that would probably cause more issues than its worth. And Mercurial isn't dead yet - Facebook uses it and they're rewriting it in Rust (yeah yeah) to make it faster. I don't think the VCS wars are over yet.
• dralley 9y ago
  Not to mention that the most common way of creating a branch is by using git checkout, and it also reverts files, and also switches branches, again all based on what flags you feed it
  • stouset 9y ago
    `git checkout` has one main responsibility: take stuff from a commit and put it on the filesystem (and put it in the index as well). All of its functionality is simple variants on that. `-b` is the only real odd man out, and it’s just a shortcut for calling `git branch $branchname` first.
• adrianmonk 9y ago
  A lot of it is easy UX wins left on the table. "git revert" would have been clearer if it were identical but just named "git retract". It's a more natural match because reverting usually just means going back to how things were, whereas retracting can and often does mean to announce that you are going back. After a newspaper prints something untrue or unfounded, they issue a retraction. "git checkout -b" is confusing because the main and most significant thing it does is create a new branch, and checking it out is secondary to that. If it had been "git branch -c" instead (create a branch also check it out) that would have been more natural than "git checkout -b" (check out a branch that, incidentally, you will have created). "git reset", as you mentioned, does two things. This could have been made easier by just splitting it into two commands. Perhaps the first two forms could be called "git unstage". The git book ( https://git-scm.com/book/id/v2/Git-Basics-Undoing-Things https://git-scm.com/book/id/v2/Git-Basics-Undoing-Things ) explains it under a heading called "Unstaging a Staged File", which suggests that it's a more natural term.
  • Already__Taken 9y ago
    git reset should be renamed to git remove, because add is used to add the staging. Or "git add" should be "git stage" "git remove" should then be "git delete".
    • erik_seaberg 9y ago
      The staging area was a mistake because it's hidden in the repo where I can't build and test it. I should be stashing changes I don't want to commit, and then committing the known-good workspace.
• tjr225 9y ago
  Git is much like Vim...user-unfriendly on the surface...but user friendly at the core. It is a simple tool that works, but is hard to understand for the beginner.
  • jcranmer 9y ago
    There's one key difference: vim's user manual is useful. git's user manual is not (see https://news.ycombinator.com/item?id=16590497 https://news.ycombinator.com/item?id=16590497 for an example).
  • IshKebab 9y ago
    Yeah that's not an excuse though. It could easily have been user-friendly on the surface too!
• jcranmer 9y ago
  The best example I can think of right now as to where git's documentation is unusable: suppose you accidentally git add'd a file, and you want to remove it without deleting it on disk (since, you know, that's your only copy of it). This doesn't come up very often, so there's no way you're going to remember the command off the top of your head. The most reasonable guess is "it sounds like a special rm, so let's look at the documentation for rm." Here's hg help rm: remove the specified files on the next commit Schedule the indicated files for removal from the current branch. This command schedules the files to be removed at the next commit. To undo a remove before that, see 'hg revert'. To undo added files, see 'hg forget'. Oh, I don't want hg rm, I want hg forget. hg help forget confirms this: This only removes files from the current branch, not from the entire project history, and it does not delete them from the working directory. Okay, let's ask git help rm: Remove files from the index, or from the working tree and the index. git rm will not remove a file from just your working directory. (There is no option to remove a file only from the working tree and yet keep it in the index; use /bin/rm if you want to do that.) The files being removed have to be identical to the tip of the branch, and no updates to their contents can be staged in the index, though that default behavior can be overridden with the -f option. When --cached is given, the staged content has to match either the tip of the branch or the file on disk, allowing the file to be removed from just the index. For this to be any use, you have to remember that "index" refers to the staging area and not anything else that might reasonably be presumed to be an index (such as the commit history). Of course, if you knew there was a glossary, you could double-check the definition in the glossary, only to find that the definition (a collection of files with stat information, whose contents are stored as objects) is about as useful as the infamous "a monad is a monoid in the category of endofunctors," but the latter was supposed to be a joke. Sure, some problems with git may be that people have trouble understanding the concepts. But many of them are due to git's impenetrable documentation and a few of the commands that do too many things. The sheer resistance of many adherents of git to recognize that it has a UX problem is just mind-boggling.
  • chopin 9y ago
    In such cases, I look for my problem on stackoverflow. When I find a solution which seems right to me, I look up https://git-scm.com/docs https://git-scm.com/docs to get a better understanding of what I am doing and why. The problem with many documentations is that they are not use-case driven. Much of it is a functionality description. Such as: - To fasten, you have to turn the nut clockwise. instead of: - To fit these two parts together you need to fasten the nuts onto the screws.