6 ms·

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 co

by 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
      You would be surprised how many cooks sharpen their knives themselves. It is also a very wholesome and meditative activity.
    - quanticle 6y ago
      No? Good cooks most definitely sharpen their own knives.
      - Al-Khwarizmi 6y ago
        Cooks and knives are a bad example, because sharpening knives is easy. I am not a cook and sharpen mine too. It takes like 15 minutes to learn how to do it, and a similar time to actually do it. Most piano players don't have a clue about how to tune their pianos, though.
        ghayes 6y ago
        Oddly enough, pianists not knowing how to tune a piano is an anomaly in the music world, as most other artists know their instruments inside and out. The Times did a piece on this just the other day: https://www.nytimes.com/2020/11/12/arts/music/piano-tuning.html https://www.nytimes.com/2020/11/12/arts/music/piano-tuning.h...
        bipson 6y ago
        It is not binary in my experience. Most professional musicians know their instrument very well - and still know a man for the "hard" stuff, e.g. for thorough maintenance or repairs that require craftsmanship. And there are obviously variants. The guys that fix their instruments regularly and experiment with e.g. cooking your stings, and musicians that hand them in for the tiniest, easiest tasks.
- feisuzhu 6y ago
  > In the end git is not in production Git ends in my production multiple times. 1. In my side project game, auto update and replay system is based on Git. For every update, there will be a commit appended to the code repo which is the most recent update. If a player wants to replay a game in previous version, just checkout the appropriate commit, and run the replay using exact the same code. I'm freed from backward compatibility issue & update subsystem which handles diffing, compression, transporting by a single decision. https://github.com/feisuzhu/thbattle/blob/master/src/autoupdate.py https://github.com/feisuzhu/thbattle/blob/master/src/autoupd... 2. Another project written by me, which is a monitoring system, distributes it's rules by a git repo. Monitoring agents in the nodes cares about authenticity of distributed rules. So I just sign the tree hash and embed the signature in commit message, which will be later validated by monitoring agents. https://github.com/leancloud/satori/blob/master/satori-rules/sign https://github.com/leancloud/satori/blob/master/satori-rules...
- bipson 6y ago
  That's a very shortsighted view on the world. Particularly if you're working with other people. Once you are collaborating, there is simply more to good code than what you our your peers know about the code or the language. Working well and effective with others has a huge impact on you, your peers, the "company" and in the end the product. Further, I know a lot more about my cars than just how to change the tires. E.g. there are know issues with certain popular car models. Knowing about them does help, not every random mechanic does. Also, if my car does certain things (surprise, they do all the time, they are complex nowadays) that are easily explainable or even somewhere in the manual, I am not going to ask for help every.single.time. I have stuff to do, be somewhere. I am not going to put my car in the dealership all the time. Git for me is a productivity tool, in particular when I'm working with others. You sound like the guy I once collaborated with that didn't want to use git (because why should he learn it now?) and instead sending the whole code via skype every day.
- quanticle 6y ago
  "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." You're annoyed at them... because they do things that you don't know how to do? How is that their fault? "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." That's a very short-sighted attitude. It's like saying, "I don't want to learn how to operate a bulldozer, because I'd rather be an expert on dirt rather than the tools to move dirt."
- jamienicol 6y ago
  > do annoying things like rewriting commit histories after I made comments in their PRs That's exactly what I'd expect someone to do after I commented on their PR.
  - Supermancho 6y ago
    > ewriting commit histories after I made comments in their PRs > That's exactly what I'd expect someone to do after I commented on their PR. The vast majority of people do not. I certainly wouldn't expect someone to waste time on that.
    - jamienicol 6y ago
      > The vast majority of people do not. That's a very bold claim. It's certainly been the expected workflow everywhere I've worked. You might consider it a waste of time but I'd wager the resulting mess of commits from not doing so wastes far more time in the long run.
      - recursive 6y ago
        I've never worked in an environment where it was expected or used. As far as I can tell, no time has been wasted as a result. How would it cause time wasting?
        jamienicol 6y ago
        Without a clean history it takes longer to find which commit changed things and why.
        recursive 6y ago
        I believe I've really only needed to do that once. git bisect handled it in about 10 minutes IIRC. It's hard for me to imagine how I could achieve a net time savings against that level of commit-hunting.
- lsaferite 6y ago
  Your insistence in purposefully not understanding how to use a tool in your toolbox is frankly saddening. It's literally part of your job. You interact with it presumably daily, yet you have no clue how to be effective with that tool. And you say others are annoying for learning how to use their tools.
ajuc 6y ago
The problem is - if you're not using some feature every month you won't remember how to do it anyway when you finally need to use it. So there's little point reading about exotic features upfront other than to know they exist. And which features are exotic depends on your workflow. It would help if git interface was consistent enough to make remembering this stuff easier. For example I never remember the exact options for git reset because I'm using it just rarely enough to forget them when I need them again.
- tankenmate 6y ago
  I would suggest it's far better to understand the data structures inherent in git and how those data structure changes are tracked and merged. Then almost all operations in git become clear. And as a side bonus it will probably make you a better coder.
  - ajuc 6y ago
    How would knowing the structure (which I already do) help me remembering what was that option called?
    - jeltz 6y ago
      Because most options are named after parts of the underlying structure. At least for me that makes them much easier to remember. There are some exceptions, but in general there is a logical system behind the naming.
- lsaferite 6y ago
  > For example I never remember the exact options for git reset because I'm using it just rarely enough to forget them when I need them again. I would argue the value is in knowing that something is possible using the `git reset` command so you know to go looking for the exact option to do what you want. And more likely you'll remember the operation if it's one you find yourself using frequently.
  - 6y ago

by ghayes 6y ago

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
    You would be surprised how many cooks sharpen their knives themselves. It is also a very wholesome and meditative activity.
  - quanticle 6y ago
    No? Good cooks most definitely sharpen their own knives.
    - Al-Khwarizmi 6y ago
      Cooks and knives are a bad example, because sharpening knives is easy. I am not a cook and sharpen mine too. It takes like 15 minutes to learn how to do it, and a similar time to actually do it. Most piano players don't have a clue about how to tune their pianos, though.
      - ghayes 6y ago
        Oddly enough, pianists not knowing how to tune a piano is an anomaly in the music world, as most other artists know their instruments inside and out. The Times did a piece on this just the other day: https://www.nytimes.com/2020/11/12/arts/music/piano-tuning.html https://www.nytimes.com/2020/11/12/arts/music/piano-tuning.h...
        bipson 6y ago
        It is not binary in my experience. Most professional musicians know their instrument very well - and still know a man for the "hard" stuff, e.g. for thorough maintenance or repairs that require craftsmanship. And there are obviously variants. The guys that fix their instruments regularly and experiment with e.g. cooking your stings, and musicians that hand them in for the tiniest, easiest tasks.
feisuzhu 6y ago
> In the end git is not in production Git ends in my production multiple times. 1. In my side project game, auto update and replay system is based on Git. For every update, there will be a commit appended to the code repo which is the most recent update. If a player wants to replay a game in previous version, just checkout the appropriate commit, and run the replay using exact the same code. I'm freed from backward compatibility issue & update subsystem which handles diffing, compression, transporting by a single decision. https://github.com/feisuzhu/thbattle/blob/master/src/autoupdate.py https://github.com/feisuzhu/thbattle/blob/master/src/autoupd... 2. Another project written by me, which is a monitoring system, distributes it's rules by a git repo. Monitoring agents in the nodes cares about authenticity of distributed rules. So I just sign the tree hash and embed the signature in commit message, which will be later validated by monitoring agents. https://github.com/leancloud/satori/blob/master/satori-rules/sign https://github.com/leancloud/satori/blob/master/satori-rules...
bipson 6y ago
That's a very shortsighted view on the world. Particularly if you're working with other people. Once you are collaborating, there is simply more to good code than what you our your peers know about the code or the language. Working well and effective with others has a huge impact on you, your peers, the "company" and in the end the product. Further, I know a lot more about my cars than just how to change the tires. E.g. there are know issues with certain popular car models. Knowing about them does help, not every random mechanic does. Also, if my car does certain things (surprise, they do all the time, they are complex nowadays) that are easily explainable or even somewhere in the manual, I am not going to ask for help every.single.time. I have stuff to do, be somewhere. I am not going to put my car in the dealership all the time. Git for me is a productivity tool, in particular when I'm working with others. You sound like the guy I once collaborated with that didn't want to use git (because why should he learn it now?) and instead sending the whole code via skype every day.
quanticle 6y ago
"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." You're annoyed at them... because they do things that you don't know how to do? How is that their fault? "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." That's a very short-sighted attitude. It's like saying, "I don't want to learn how to operate a bulldozer, because I'd rather be an expert on dirt rather than the tools to move dirt."
jamienicol 6y ago
> do annoying things like rewriting commit histories after I made comments in their PRs That's exactly what I'd expect someone to do after I commented on their PR.
- Supermancho 6y ago
  > ewriting commit histories after I made comments in their PRs > That's exactly what I'd expect someone to do after I commented on their PR. The vast majority of people do not. I certainly wouldn't expect someone to waste time on that.
  - jamienicol 6y ago
    > The vast majority of people do not. That's a very bold claim. It's certainly been the expected workflow everywhere I've worked. You might consider it a waste of time but I'd wager the resulting mess of commits from not doing so wastes far more time in the long run.
    - recursive 6y ago
      I've never worked in an environment where it was expected or used. As far as I can tell, no time has been wasted as a result. How would it cause time wasting?
      - jamienicol 6y ago
        Without a clean history it takes longer to find which commit changed things and why.
        recursive 6y ago
        I believe I've really only needed to do that once. git bisect handled it in about 10 minutes IIRC. It's hard for me to imagine how I could achieve a net time savings against that level of commit-hunting.
lsaferite 6y ago
Your insistence in purposefully not understanding how to use a tool in your toolbox is frankly saddening. It's literally part of your job. You interact with it presumably daily, yet you have no clue how to be effective with that tool. And you say others are annoying for learning how to use their tools.

ajuc 6y ago

The problem is - if you're not using some feature every month you won't remember how to do it anyway when you finally need to use it. So there's little point reading about exotic features upfront other than to know they exist. And which features are exotic depends on your workflow. It would help if git interface was consistent enough to make remembering this stuff easier. For example I never remember the exact options for git reset because I'm using it just rarely enough to forget them when I need them again.

tankenmate 6y ago
I would suggest it's far better to understand the data structures inherent in git and how those data structure changes are tracked and merged. Then almost all operations in git become clear. And as a side bonus it will probably make you a better coder.
- ajuc 6y ago
  How would knowing the structure (which I already do) help me remembering what was that option called?
  - jeltz 6y ago
    Because most options are named after parts of the underlying structure. At least for me that makes them much easier to remember. There are some exceptions, but in general there is a logical system behind the naming.
lsaferite 6y ago
> For example I never remember the exact options for git reset because I'm using it just rarely enough to forget them when I need them again. I would argue the value is in knowing that something is possible using the `git reset` command so you know to go looking for the exact option to do what you want. And more likely you'll remember the operation if it's one you find yourself using frequently.
- 6y ago