Hacker News Reader

Comment by ramraj07 | Hacker News Reader

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.

View on HN

"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."

> 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/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...

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.

> 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.

> 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.

> 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.

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?

Without a clean history it takes longer to find which commit changed things and why.

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.

I envy you then. I spend a great deal of time looking through history to find bugs.

An unclean history is less likely to work well with bisect too, as the individual commits may be broken.

> I spend a great deal of time looking through history to find bugs.

You mean when where and how a change was introduced? I dont think bugs are located in the history, since bugs are operational failures on a deployed branch.

Yes, I phrased that badly. Let's say looking through history to understand the context of when bugs were introduced and how to fix them

No one I work with does that. They do one of two things.

1) argue that they really don't need to change anything 2) push more commit(s)

Why would it be better to rewrite history?

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.

Before undertaking his craft, the artisan first sharpens his tools.

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.

You would be surprised how many cooks sharpen their knives themselves.

It is also a very wholesome and meditative activity.

No? Good cooks most definitely sharpen their own knives.

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.

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.h...

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.

Reply on news.ycombinator.com