12 ms·

I'm not an idiot, but I don't fully understand git. I am coding for a living, and I use git every day. I probably could sit down for a couple of days and fully

• zingermc 6y ago
  I've definitely been the victim of my own git hubris. Once, when leaving a job, I decided to copy all of my local WIP branches to the server. I whipped out this fancy --mirror option I had just heard of: git push --mirror $remote Surprise! All branches on the remote repo got wiped. My local refs replaced the refs on the remote. Somehow I found the right commits floating around in the git ether. I was able to recreate the branches, but I had to recreate their names by reading the commit log. Did I mention this happened on my way out the door from a job? In retrospect, I shouldn't have panicked so much -- there were daily backups -- but the sheer terror I felt has made me read the man pages really closely to this day.
  • aulin 6y ago
    this definitely shouldn't happen if shared branches are properly protected against non fastforward pushes
    • mannykannot 6y ago
      ...and if you didn't know that, you shouldn't be using git! To be fair, one should always look up options you are unfamiliar with before using - and Stack Exchange is not an authoritative source. --mirror ...Newly created local refs will be pushed to the remote end, locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end... [my emphasis.] On the other hand, if you are on a system where the behavior can be fundamentally altered by multiple configuration options, this will not necessarily help you much. ...This is the default if the configuration option remote.<remote>.mirror is set.
      • Qwertious 6y ago
        >To be fair, one should always look up options you are unfamiliar with before using - and Stack Exchange is not an authoritative source https://xkcd.com/293/ https://xkcd.com/293/
  • dimgl 6y ago
    I get it, but I'm not sure you should fault Git for that. Nothing like that has ever happened to me and I wouldn't use a command I don't know in a critical setting...
    • NateEag 6y ago
      Any sane piece of software should warn you before doing a highly destructive operation. Something like You are trying to remove commits from twelve branches. Are you sure that's what you want to do? Include the --force option to go ahead with this change. would be a whole lot better. Even if it gives you the tools to undo the mistakes, it saves you time and stress if it keeps you from making the mistakes in the first place.
  • mcintyre1994 6y ago
    I have a horrible feeling your answer to this is going to stress me out, but does that work even without a force push?
    • jorams 6y ago
      Yes, --mirror implies a level of force. The man page contains this: "...locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end..."
      • hvidgaard 6y ago
        That breaks a very simple rule that a VCS tools should adhere consistently. Do not make destructive changes unless explicitly told to. Since most other commands to not allow you to do this without -f, the same should apply here.
        • jorams 6y ago
          I'm not sure I see your point. The entire reason `git push --mirror` exists is to turn the remote end into a mirror of the local end. By definition that's a destructive operation. What would it do without a further --force? If you just want to push all branches or tags you should use --all or --tags.
          • hvidgaard 6y ago
            Because you normally cannot make remote destructive changes without the --force. Unless you know the commands that does that by default. That is bad UX.
    • ziml77 6y ago
      Probably because removing branches from the remote doesn't make the commit history inconsistent with any copies made before the push. That seems to be the only case where git second-guesses what you tell it to do.
  • em-bee 6y ago
    mistakes happen. it is a testament to the power of git that your command didn't cause permanent damage. and yes, it could have been worse. but if you want a system that protects you from these mistakes by making mistakes impossible, then you get a system that is very rigit and actually harder to use. git protects you from these mistakes by making it possible to recover. in this particular instance though, there could probably be some extra help to recover. (some way restore the removed refs)
• ghayes 6y ago
  I'm not sure I follow your logic: why not take a few days to learn the fundamentals of git? I did that a few years back (and I'm not saying I read the source code, just learned about the base concepts from a few blogs and played around with some more advanced commands), and it has paid dividends _every single day for the last several years_. For example, I avoid tracking branches and have started using `git fetch`, `git merge --ff-only <remote>/<branch>`, `git reset --hard <remote>/<branch>` and `git push <remote> <branch>` to push and pull remote code. Even these slightly lower level commands will start to help you understand what's going on behind the scenes and take the mystery out of, say, rebase conflicts.
  • ramraj07 6y ago
    I am limited by time on what I can learn, every day I have five other things I'd rather spend my time learning about instead of git. The "git experts" that I know of are no more productive than me and more often than not do annoying things like rewriting commit histories after I made comments in their PRs, that I'm not convinced it's worth the day or two I need to learn it fully. In the end git is not in production, it's just a tool to manage code, I'd rather be an expert on the code than the coding tool. This is probably akin to trying to understand how your car works when all you need it to do is get you to work. Changing tires is about as much as anyone who's trying to be productive should know about their car. Call a mechanic for anything else.
    • tankenmate 6y ago
      Before undertaking his craft, the artisan first sharpens his tools.
      • ramraj07 6y ago
        A good cook doesn't need to own 5 stones to sharpen his knife, he just needs to have the number of the sharpening guy.
        • bipson 6y ago
• ChrisMarshallNY 6y ago
  That’s a similar approach to mine. I tend to learn enough about something to “get the job done.” This is both good and bad. I get a lot done, but not always as efficiently as possible, and I do find myself realizing, down the road, that I didn’t need to do it that way. But it’s entirely possible to get caught in “tool rabbitholes,” where the main goal becomes subservient to the infrastructure. I remember dealing with folks that would spend three days, writing CLI tools that saved, maybe two hours, over the course of a year.
  • ajuc 6y ago
    I learn similarly (breadth first search + going deeper when needed) and my wife just does depth first seach. I've tried studying with her when we were at university and we just couldn't make it work - she would want to go 10 levels deep into the first subject and I would get insane trying to remember all the nested questions that get us there withotu understanding where the thing I'm learning about will be used :) Her problem is she gets discouraged halfway through and never gets to use the stuff she learned. My problem is I got good at winging it and looking up stuff as needed so I never learn the stuff I didn't needed even when it could be useful if I knew about it. Probably some compromise would be the best - start with what you need and force yourself to go deep into one random topic each month. > I remember dealing with folks that would spend three days, writing CLI tools that saved, maybe two hours, over the course of a year. My friend is like that, but I learnt to aprecciate this when I worked with him. The script maybe only saved 1 minute of work 10 times a year, but more importantly it's self-checking documentation of how we are doing stuff we rarely do.
• krageon 6y ago
  > I probably could sit down for a couple of days and fully understand how git works This means it isn't hard. If you are capable of understanding algorithms of any complexity you should be able to learn how to use git (and how much of it) without treading on ground that is dangerous for you to use. All of this "it's too hard" rhetoric is infantilising or coddling people who frankly shouldn't be trusted to code anything of importance anyway. There's no shame in admitting your own limitations, but there is definitely shame in lowering the bar for others so much you are actively harming the industry.
  • Joeri 6y ago
    Everyone starts at the ground floor. What would you tell a beginner who has to figure out 20 different technologies including git to get a basic web project going? Besides, nobody is arguing git needs to be made weaker, just that it would be nice if it had a more gradual learning curve. Easy things easy, hard things possible. If you can’t see how git is hard you’ve forgotten what it is like to be a beginner.
    • thrwyoilarticle 6y ago
      >What would you tell a beginner who has to figure out 20 different technologies including git to get a basic web project going? Software development is hard. That's why we have to spend years studying it and earn conspicuously good wages. A basic project doesn't need git anyway.
      • gpderetta 6y ago
        eh, git is perfectly fine even for trivial projects. Agree on the need for education to be a good developer though.
    • drran 6y ago
      > What would you tell a beginner who has to figure out 20 different technologies including git to get a basic web project going? We have the whole education system to deal with that. It's the same problem as in mechanics, chemistry, biology, etc.
• secondcoming 6y ago
  +1 These commands will get you 99% of the way: - git status - git branch - git pull - git add - git commit - git diff - git merge - git push - git checkout For everything else there's StackOverflow, but the info in there comes with the risk of being stale. -------------- Edit commit abaeb3b4: Add missing commands and improve formatting Edit commit 842babda: Add git checkout
  • h0l0cube 6y ago
    `git status` is required to determine which untracked files you need to add. And then, of course, `git add` would be need to be added to the list too. To add untracked files you could use interactive mode `git add -i` and forgo reading `status`. But you can also `git commit -p` if you only modified files and forgo the `add` step. And to give yourself a sense of the commit graph, these aliases come in handy [alias] lol = log --graph --decorate --pretty=oneline --abbrev-commit lola = log --graph --date=short --pretty=format:'%C(auto)%h %C(dim)%ad%C(auto)%d %s' --all The only 'advanced' thing I commonly do is `git rebase -i` to squash a bunch of WIP commits. And a shell script I have to turn merged branch into a tag, and remove the branch. The other day I had to remove a sensitive file that accidentally got checked into the repo for a couple of commits behind HEAD, and was glad that git had the power to do this in one line and without fuss. (Edit: but yes, I had to look it up on SE)
    • secondcoming 6y ago
      Indeed, I forgot 'git status', and 'git add' I've honestly ever felt the need, or had the requirement, to look at the graph.
      • h0l0cube 6y ago
        I've found it indispensable when tracking and integrating other peoples' branches. I wouldn't use it so much if I was working solo.
        • sethammons 6y ago
• darekkay 6y ago
  > I'm not an idiot, but I don't fully understand git. I am coding for a living, and I use git every day. I probably could sit down for a couple of days and fully understand how git works, but I've never needed it, I understand how basic git operations work, and I stay away from commands that I don't understand. That's a great summary for the majority of Git users. I am still motivating people to spend the time to learn it "properly" if they're using Git daily. First of all, it will make them more efficient. I've seen too many people literally redoing their changes, because a cherry-pick/rebase is "an operation they don't understand". Secondly, they will be able to solve most issues when (not if) they occur. Sure, I am more than happy to help my colleagues solving their issues. From "why are those changes in my PR" to "our Jenkins job went rogue and now we've got hundreds of MB of data in our repository that we would like to remove". But the time of me explaining things the "learning by doing" style would be better spent actually learning Git.