Comment by prettyStandard | Hacker News Reader

Comment by prettyStandard | Hacker News Reader

This looks fantastic!

I think this is what we need more of for new git users. I struggled for the longest with git until I came across learngitbranching[0]. I believe having an interactive/visual experience while I typed in commands is what I needed, and what most people need.

I tell junior developers they should take a day to learn this and more often than not they dismiss me. Meanwhile these people will run into git conflicts or something and their strategy is to "save their work somewhere else and redownload the repo"[1]. I know of a "senior developer" that will do that. I basically told him, in my eyes, if you don't know how to use git, you are not a senior. Or a bad senior at a minimum. See the stack overflow survey. Git is used basically by all developers. How do you expect to be a good developer by dismissing such a ubiquitous tool. I think I can make an exception for people who aren't using git at their current company and any company before.

[0]: https://learngitbranching.js.org/

[1]: https://xkcd.com/1597/

> save their work somewhere else and redownload the repo

Not that there's anything wrong with that, is there?

As a "bad senior developer" who uses git daily, one of the things that I love about git is that in the end everything is regular files. So there's nothing wrong with just copying your git repository elsewhere, re-cloning it, and fixing your fuckup by hand. No need to feel guilty about it.

Your comment sounds like criticizing somebody that does not know all the keyboard shortcuts that you do.

Do you understand how merge conflicts happen in the first place? 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.

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?

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.

Because most problems like merging and resolving correctly, or rebasing or squashing if needed don't get resolved by cloning a new repo. If you avoid learning the tool and you just clone a new repo when you have a problem you won't be able to do any non-trivial task in git.

Thanks for checking it out!

Would be great to get any feedback you might have if you get the chance to install/test it out.

Will do!

Reply on news.ycombinator.com