Archive for January, 2024

I just thought of a neat way to avoid git conflicts

Sunday, January 14th, 2024

I think git is a technological marvel. I think it very well suits the problem it was designed to fix: lots of random people contributing random junk to try and get it into the linux kernel, and for that it is great.

But everybody else uses git too, apparently private companies, which never quite made sense to me, because everybody is [supposed to be] on the same team.

You’re not going to reject somebody’s pull request because they’re trying to put insecure code into your codebase, or whatever other reasons prs against the linux kernel are rejected. You work for the same company, probably on the same team trying to make the product better, why would you compete? You don’t, that’s not how companies work.

It seems to me that git is an overengineered heavy handed way to do source control among a group of people who are all striving for roughly the same goal.

Yet it seems to be the most popular hotness so everybody uses it. It is what it is.

One of my larger beefs with git is the merge conflict problem it creates.

Now I honestly can’t remember how we dealt with the problem, which must have existed, in the days of cvs and subversion, but somehow we managed, but I don’t remember being as frustrated with cvs as I am with git conflicts.

Firstly all git conflicts could be avoided with a little application of intelligent logistics. If you just order the work to be done such that two people don’t work on the same piece of code at the same time, there will be no conflict. All a conflict is, is a waste of time cause by poor time management. I’ve never heard of anybody enjoying resolving merge conflicts, and they’re easy to avoid but… nobody does.

But this morning, I had an idea, a stupid easy way to avoid git conflicts and help with the time management problem at the same time.

Now the technology to make the idea viable didn’t exist until fairly recently, so it wouldn’t have been workable, but now it does exist and it’s easy to use and nobody’s going to do it, because nobody likes change and people have been using git forever, and git is good and right and nobody really wants to make things better. If they did, they’d follow this easy solution: Use live shared editing.

Google docs lets two people edit the same file at the same time, and I believe vscode live share does something similar, so the technology exists.

If two people needed to work on the same code at the same time, they could. Forking/branching your own copy is what causes the conflict problem so… don’t do it. Everybody works on the live repo in main.

There are other things that can be done to make the experience better, like warn both or all parties when people start working to close to each other on the same code, and you could still use branches to segment units of work. I’m sure other tools could be invented to make this style of code editing more useful, but the basic concept, is that everybody actually edits the same file at the same time, and sees what the other editors are doing and naturally stays away when somebody else is working here. When you walk down the hallway and see somebody coming right at you, do you keep walking right at them? No, you make way. And so do they. Real simple.

As a result, one person may very well back off and go work on something else until the first person is done, thus avoiding creating conflicting code. Look at that: self driven logistics and time management.

Yes it would make writing tests a little harder because you’d have to wait for the other person to finish before you could run your test but… again, time management, find something else to do, so there’s no conflict. As annoying as it may seem, it’s way less annoying than having to always deal with conflicts or fear the git pull because you don’t know how much work you’re in for just to make your code work again.

The shiny new editor tools can put up little marker notifications annotating the editor saying things like: “so-and-so touched this a few minutes ago, they might not be done.”
Or the programmer can mark it complete while they go work on tests or move on to something else, indicating to the next person they’re free to work on this stuff.

Will it solve all the problems? No, it will solve the git conflict problem which is unquestionably a waste of resources time suck for all involved. There has to be a better way. This is one possible option.