Just curious - what do you see as being a viable alternative to the current git paradigm?
I want an experience more like Google Docs and less like emailing diffs to a mailing list.
You stop then test.
I'm sure you have good ideas about better workflows here but I don't think they're as obvious to other people as you maybe assume?
So you make a branch, a bunch of you discuss and edit in real time. Once everyone is ready, you stop and test.
> So you make a branch, a bunch of you discuss and edit in real time. Once everyone is ready, you stop and test
What if you want to test your work out, and don't want to wait until everybody else has finished with their work and stopped working to test? What if you don't want to try to coordinate 100 different instances of "everybody stop working (but also make sure the build isn't broken), I want to run tests" per day?
So now you have to get everyone into the same headspace at the same time and schedule coding sessions across timezones?
What if two people independently feel like doing some quick incompatible changes late at night? Do they have to message everyone on the team to see if it’s OK? Or do they make a branch of the branch of the branch to test it by themselves? How is that more convenient? And in that world, how can you do those tests privately, without everyone on the team (plus the service you’re using) being able to see them? And what happens when you don’t have an internet connection (or your service is down) but you want to continue working?
I agree with the parent comment, there are too many unanswered questions in your proposed scenario.
The whole blog post in general feels incongruent, and it’s not surprising to me you’re getting conflicting feedback. You’re conflating different scenarios and proposing broad vague ideas which are not only impractical for a multitude of scenarios, they remove user agency and give more power to corporations, which is exactly the opposite of what we should be doing.
Your “one person” rebuttal doesn’t work, because one person is not sabotaging themselves in other files of the same project.
I've seen teams develop on a single target system, all of them bashing on the same source code base at once. It sort of works with a well-tuned team, that communicates well, and is capable of dealing with the resulting inconveniences, up to maybe 3 or 4 developers. Probably helps to have dynamic scripting languages in use by most of the devs so you aren't trying to time your compiles with each other's actions. And they still stepped on each other more than I would have been able to tolerate. There's no way this scales.
For non-code documents, by all means share. English prose doesn't crash if you start editing page 5 while someone else has an incomplete sentence fragment they're in the process of changing on page 2. But trying to edit code that way doesn't scale for squat.
From this point of view, whether it's "files" or "a database" or whatever that's being developed on isn't relevant. The point is that I actively do not want somebody else's half done work randomly getting integrated with what I'm working on right now.
This is fine in text documents (to an extent, obviously references to sections of text that no longer exist can happen) because different sections are not as inextricably linked to each other.
Not having a private playground is one of the big drawbacks of all the modern cloud SaaS stuff. If I want to play around and learn something, suddenly that affects everyone else. It shouldn't.
edit: I've see the author's reply, and I guess the original piece was mainly a call to develop better ways of doing things, rather than a claim that they already exist and we should hurry up and start using them. I'd still be interested in more detail on what is fixably wrong with git, though (as opposed to the annoyances that are corollaries of necessary features)