Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

People complain constantly about how painful git is when their simple workflows break down. It is legendarily complicated and difficult to use.

But when an alternative comes along and long-term git users try to tell people how much better it is? Everyone immediately forgets all their issues and frustrations. It’s honestly kind of bizarre.



Anecdata: I have no issues with my simple git workflow that I’ve used at the previous 3 companies I’ve worked for. As long as communication is solid across teams/people, merge conflicts and rebasing isn’t that big of a pain to introduce an un proven tool to an org.

My thought would be that most people are happy and it’s the <5% of people who complain the loudest that are heard.


> to introduce an un proven tool to an org

Your org doesn’t have to adopt the tool. Nobody on my team needs to know or care that I use jj instead of git. The only people who do know or care have themselves switched when I showed it off to them.

I’ve worked too many places where I’ve helped fix too many coworkers’ broken git repos to believe in a simple git workflow. Basically everyone uses the same fetch/branch/commit/merge-to-main approach and people still constantly run into problems. None of the people with some claimed simple workflow are doing anything meaningfully different than what everyone else is doing.

It’s just astonishingly easy to internalize all the fixes and band aids we’ve adopted to smooth the sharp edges and forget how often we have to work around them.


But I don’t see the complaints that were claimed. I help people as well. They learn, and we move on. If they don’t learn then we have another problem to solve.

I will admit there is occasional call where I have to get someone out of a twisted pretzel, but that is few and far between.


You don’t deal with rebase conflicts? You don’t ever unstash to the wrong branch? Or to the right branch, but it was changed and now it’s applied uncleanly? You don’t ever want to go fix a previous commit? You don’t ever need to do linear work that gets merged one piece at a time into the trunk?

All of these things (and others) can be worked around with varying levels of annoyance ranging from just living with it to new commands that help out to changing your workflow to completely avoiding some workflows. But in my experience nearly everyone deals with those annoyances on a semi-regular basis.


With a proper workflow and communication, only the first one (rebase conflicts) is a semi-regular occurrence (once a month). The others I have never had to do while working on a team. We establish a clear way of working and everyone abides by it.

And before you say well this doesn’t work with a bigger team, my team is 8 and the org is 50 on the same codebase. At “google scale”, I understand this might not be the same case.

If someone has to go out of that workflow to fix a previous commit on main, they submit a pr on top of latest.

Again, I don’t see the major complications here. It seems to me to be fixing a communication issue in an org more than anything.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: