Comment by maccard | Hacker News Reader

Comment by maccard | Hacker News Reader

Parent Full thread

Ther'es a difference between understanding how merge conflicts happen, and understanding how git handles basic operations in order ot be able to use it effectively.

> If you are to be a senior leading others, you should be able to explain this to juniors so they don't shoot themselves in the foot.

Firstly, not all seniors are managers. Secondly, it is not a good use of a senior engineer's time to be teaching fundamentals to a junior developer. I am a decent developer, a passable manager, and a poor teacher. It's much better for me to point my team in the direction of existing tools.

> Do you disagree that it's a fundamental tool to being a developer(today), or do you disagree that it's necessary to know fundamental developer tools to be a good senior developer?

Other VCS tools exist, it's possible to have gone a decade in the industry as an effective developer without using git. Many large companies use Perforce, other companies use internal tools. I disagree that it's necessary to understand the working model of fundamental tools to use them. We don't require truck drivers to understand the difference between the Otto and Diesel cycles to drive a truck, why is it ok to force developers to undersatnd the many, many, many different operations that `git checkout` can perform depending on the state of your repository/what you've asked it to do?

If you’re a senior at a company that uses git, these are all terrible answers.

As a senior you not only should understand how to stash local changes and handle merge conflicts, but also generally use your VCS to elevate your development ability. Finding who added a bug and when with cherry picking. Retroactivity applying changes to all of history with rebasing and branching. All of this git provides if you put in the effort to learn it, and more. It’s an incredibly powerful tool, and to not use its capabilities is simply a waste.

Your “reclone the repo and start again” case is a lot of wasted effort. You could use one or two quick commands to undo your changes. Your ignorance at how the tool works doesn’t undermine its value or purpose.

I’d expect a senior to not only be able to handle these cases, but also show interesting other tools in git and when they’re useful. I wouldn’t expect a senior to not be able to handle simple conflict resolution.

Git isn't the only version control tool widely used, and I've handled hundred+file merge conflicts with other VCS tools before, with significantly more ease than the same conflicts in git.

> but also generally use your VCS to elevate your development ability.

You're moving the goalposts here.

> Finding who added a bug and when with cherry picking

You've made the assumption that cherry picking is the right way to do it. You do you. Meanwhile, for the 3 times a year it matters when it was introduced, I'll just use the history view of my IDE.

> Retroactivity applying changes to all of history with rebasing and branching.

Im firmly in the "version control should be an immutable ledger of what actually happened" camp, but the reason you need to modify history with git is a design decision that everyone needs to be familiar with. Imagine if you told people "hey you need to know the implementation details of transactions in mysql to write a select statement?"

> Your “reclone the repo and start again” case is a lot of wasted effort

Tóg go bog é - you're putting words in my mouth here. Nowhere have I said that reclone and start again is acceptable. I'm saying it's unacceptable that you need a working understanding of the design model and implementation details of git to use it even remotely effectively, and that it's a poorly designed UX around a very powerful tool.

> d expect a senior to not only be able to handle these cases, but also show interesting other tools in git and when they’re useful. I wouldn’t expect a senior to not be able to handle simple conflict resolution.

We expect fresh grads to handle merge conflicts - part of our onboarding requires you to make a change and handle the conflict we enforce with it.

We don't expect everyone on the team to understand the details and reasons around why detached heads exist to be able to develop, or to understand the intricacies of a DVCS to review a coworkers change, and yet I distinctly remember the conversation with my lead a few years ago when he asked me "how do I checkout the branch you've just pushed" which led to this madness [0]. This was the example that stood out to me, but over the years there have been countless things like this (submodules, LFS, checkout vs branch, git commit vs git commit foo.js, reset; all have absolutely wild footguns).

[0] https://stackoverflow.com/questions/1783405/how-do-i-check-o...

If you work with git, you should be proficient with git. All of your points are dancing around the fact that your main point is that “being sloppy with git is OK because I don’t know it and it’s not like what I like using”.

And no, I’m not “shifting goalposts”. A senior should be able to use their VCS to elevate their development powers. I wouldn’t expect a junior to know that, but I would expect them to learn it from seniors and in their practice.

Reply on news.ycombinator.com