> Similarly the whole concept of needing to specify “origin” at all is a bit bonkers and does no favors. Why is it that I can pull from a remote branch, commit some changes, run ‘git push’ and git has no idea what branch I want to push to.
Git actually works like that. (Though you might have to set push.autoSetupRemote to true in the config?)
However, when you have multiple remotes, it's only natural that you will sometimes need to specify which one you want.
> And yeah you can forgive all this by quibbling that git was written in a time when internet access was not ubiquitous, and of course all these decisions make sense because x, y, or z advanced edge case for advanced users only, and I’m a shitty engineer because all of this complexity secretly makes my life better and I’m just too simpleminded to appreciate it.
Git was explicitly written for Linux kernel development.
You are right that almost all other projects are simpler.
> Really though, if you rewrote git from a principles first approach (with developer experience being one of those principles), it certainly would not look like how it looks today.
I agree that git's UI is lacking. You don't need a from-scratch rewrite of whole system. You can just rewrite the UI only and think carefully about the defaults in the config.
Eg 'git checkout' is an incoherent mess of barely related features. 'git switch' is a later addition, and goes in the right direction.
> Treat it like a proper distributed system, perhaps even backed by a real database.
Git is very much backed by a real database. That's actually one of the stronger points of its design. You can see that the guy who started git, Linus Torvalds, has a lot of experience writing filesystems (which are also a kind of database).
Git is also very much a distributed system with no trust between the nodes necessary, including no central trusted authority. How would you 'treat' it even more 'like a proper distributed system'?
> It’s not special because the data is code. The fact that it’s treated as such is the reason it feels so weird.
Where do you get that impression from?
The main influence of being designed for code first comes in the form of the default merge driver being line oriented. But you can plug in your own merge drivers for your own data formats.
But most everything else works the same, whether you stick C source code or funny cat pictures into your repository.
Git actually works like that. (Though you might have to set push.autoSetupRemote to true in the config?)
However, when you have multiple remotes, it's only natural that you will sometimes need to specify which one you want.
> And yeah you can forgive all this by quibbling that git was written in a time when internet access was not ubiquitous, and of course all these decisions make sense because x, y, or z advanced edge case for advanced users only, and I’m a shitty engineer because all of this complexity secretly makes my life better and I’m just too simpleminded to appreciate it.
Git was explicitly written for Linux kernel development.
You are right that almost all other projects are simpler.
> Really though, if you rewrote git from a principles first approach (with developer experience being one of those principles), it certainly would not look like how it looks today.
I agree that git's UI is lacking. You don't need a from-scratch rewrite of whole system. You can just rewrite the UI only and think carefully about the defaults in the config.
Eg 'git checkout' is an incoherent mess of barely related features. 'git switch' is a later addition, and goes in the right direction.
> Treat it like a proper distributed system, perhaps even backed by a real database.
Git is very much backed by a real database. That's actually one of the stronger points of its design. You can see that the guy who started git, Linus Torvalds, has a lot of experience writing filesystems (which are also a kind of database).
Git is also very much a distributed system with no trust between the nodes necessary, including no central trusted authority. How would you 'treat' it even more 'like a proper distributed system'?
> It’s not special because the data is code. The fact that it’s treated as such is the reason it feels so weird.
Where do you get that impression from?
The main influence of being designed for code first comes in the form of the default merge driver being line oriented. But you can plug in your own merge drivers for your own data formats.
But most everything else works the same, whether you stick C source code or funny cat pictures into your repository.