5 ms·

Considering how many people are incredibly productive with Git, calling it junk might be unfair.

• krupan 9y ago
  How many people are incredibly productive with git? Or most just kinda productive, as long as an expert isn't too far away from them?
  • jdc0589 9y ago
    git is not complicated 95% of the time. you really only need to learn a handful of commands and read a blog post or two about branching models and you are good to go. is there is some set of problems plaguing git users I've just never run in to?
    • bsder 9y ago
      Given that practically every non-beginner git tutorial starts off with "back up your repository", it's quite clear that git gets wedged a lot. Somehow, I rarely see a Mercurial tutorial give that same advice unless you are doing something really experimental.
      • swift 9y ago
        If you're writing a non-beginner git tutorial and you feel the need to include advice to "back up your repository" then you haven't done your job. It's incredibly hard to lose data with git - no matter what changes you make, the old commits are still around, because they're immutable. If you lose track of them, there's always "git reflog". I don't want to pounce on you just because you prefer Mercurial to git, so this isn't really directed at you, but in general this line of argument is always a bit frustrating to me. I've never lost data with git, but I've lost data with Mercurial several times because of the terrible UI of "hg resolve", which throws away your changes without warning unless you remember to type "hg resolve -m". None of git's questionable UI decisions (and there are many) has caused me remotely as much trouble as "hg resolve".
        • chx 9y ago
          It's way too easy to lose work with git. The easy availability of git reset --hard is a menace. I am using this https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278 https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278 shell script to make it not lose data. And it's a disgrace I need to do this. Disk space is free (within measurement error, especially for 99.99% of codebases) so just put that thing somewhere and if necessary I can use date and pickaxe to dig it up.
          • jononor 9y ago
            git reflog has the previous refs, git reset --hard does not remove anything that has been committed. It will however nuke changes that are not committed. Which is exactly what I use it for... But your script sounds like a decent solution if you want also that to be undoable
            • chx 9y ago
              A revision control system losing data on a bad ctrl+r is, as I mentioned, a menace.
            • weberc2 9y ago
              Having to navigate the reflog as a beginner can be overwhelming.
          • swift 9y ago
            I do agree with that; "git reset --hard" should stash the changes in the working copy somewhere. I'm sure you'd agree, though, that backing up your repository is not going to protect you from "git reset --hard" unless what you're really doing is backing up the working copy, and if that's what you're doing, there's a built in feature to do that in git called "git commit". =)
            • bsder 9y ago
              Except that "git commit" isn't sufficient. You have to use "git add" on a bunch of files that you have used "git add" on before. As far as I can tell, every other revision control system tracks a file for "commit" once it has had even a single "add". This is the default case and what 99% of people want--"I told you to keep track of the file. Now keep track of it until I tell you otherwise." git is the only revision control system I know of where I have to "git add" the same file over and over and over and over ... before doing "git commit". But that is fairly standard git UI practice--"Optimize the 1% case and make the 99% case annoying."
      • labster 9y ago
        That's too bad for Mercurial. Backing up a repo is just good practice—if you care enough to do version tracking, you should care that you have a backup. I have backups of all of my repos, but I have never once gotten Git into an unusable state.
        • weberc2 9y ago
          In Mercurial, you backup in case Mercurial does something it isn't supposed to do and you lose data. With Git, you backup because git is hard to reason about and there's a good chance that the command you're running will put you into a technically-valid state that you don't understand or know how to get out of and you don't want to spend hours Googling git jargon to figure out how to get out of it. This might be detached-head-state for beginners, or an odd rebase that somehow lost your data and your company's git experts can't figure out where it went. Obviously the probability of such a state is inversely proportional to your understanding of git.
      • slavik81 9y ago
        I wished I could back up my repository when I worked with AccuRev or SVN. Knowing with absolute certainty that the worst-case scenario was just reverting to a copy meant that I could try anything in git, even when I barely knew what I was doing. Freedom to experiment without consequences made learning git a much faster process than previous version control systems I'd worked with.
    • alwillis 9y ago
      http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/
  • chx 9y ago
    You can become that expert too by reading this tutorial. https://www.sbf5.com/~cduan/technical/git/ https://www.sbf5.com/~cduan/technical/git/ It doesn't teach you commands at first because: > 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.
    • chii 9y ago
      you shouldn't _need_ to understand how git internally works to use it (and if you did, then it confirms that git isn't good). You should understand the abstract model of DVCS that git presents (just like you'd need to understand the abstract model of a car to drive it).
      • db48x 9y ago
        Understanding the abstract model is exactly what people mean when they say this. It just happens that Git's implementation is incredibly close to the abstract model. This was particularly true in the beginning, before regiments such as pack files were introduced. Those regiments complicate the implementation somewhat, but haven't changed the abstract model at all.
        • db48x 9y ago
          err, s/regiments/refinements/g. Thank you, autocomplete.
        • chii 9y ago
          > Git's implementation is incredibly close to the abstract model which is exactly why a lot of people claim that git is shit. The fact that it "won" makes those people more angry.
          • qb45 9y ago
            Oh well. OTOH, I'm a kind of guy who just must take everything apart before using it and I like the brutal simplicity of git ;) The naming of commands could be better, though.
• weberc2 9y ago
  Yeah, it was hyperbole. Git does the job.
• alkonaut 9y ago
  People are productive in C too. C (like git) It's very good at what it was intended for, but everyone and their mother using git on the command line for VCS now is as if everyone had just used C to do every website, game, app etc since 1980. Git, like C, is a solid core but by now we should have better abstractions to help people be even more productive.