I like the basic philosophy that everything should be inside the code (yes lots of great collaboration and review tools out there with great browser based diffing- it’s just I am thirty years of reading code and writing code in a tool and I kinda get used to the code in the tool
I agree for smaller projects, especially personal ones. For larger projects, approaches like GitHub's web client + terminal interface might be the next best thing since grepping doesn't scale well. For better or worse, GitHub branding also helps make their specific terminal tool an easier sell in large org environments.
GitHub's web client does not scale at all in my opinion. It is very slow to load source large patches, and the code navigation experience is not great, hence why they brought VSCode for Web to the product, but still.
Heh, well GitHub's search doesn't exactly scale well either. They _still_ only index the main branch, so if you want to find anything under active development or on an old tag version you're out of luck, clone + grep is the only way.
Grepping for something “I am sure it was on a development branch somewhere” is always painful.
I do dream of one day tackling a whole load of these developer “gold plated porcelain” problems - everything from a “glimpse” index of every commit in a repo to better Jenkins config and how to set up mTLS the hard way.
It’s “Thedevmanual” and someday I will have time to write it
I don't really understand this argument. It is not like a web based tool is stopping you from seeing the code in your editor. You just check out the code and now you are seeing the code in your fav editor. Which is exactly the same process you would use with this tool.
Comments
I like the basic philosophy that everything should be inside the code (yes lots of great collaboration and review tools out there with great browser based diffing- it’s just I am thirty years of reading code and writing code in a tool and I kinda get used to the code in the tool
I agree for smaller projects, especially personal ones. For larger projects, approaches like GitHub's web client + terminal interface might be the next best thing since grepping doesn't scale well. For better or worse, GitHub branding also helps make their specific terminal tool an easier sell in large org environments.
GitHub's web client does not scale at all in my opinion. It is very slow to load source large patches, and the code navigation experience is not great, hence why they brought VSCode for Web to the product, but still.
Heh, well GitHub's search doesn't exactly scale well either. They _still_ only index the main branch, so if you want to find anything under active development or on an old tag version you're out of luck, clone + grep is the only way.
Grepping for something “I am sure it was on a development branch somewhere” is always painful.
I do dream of one day tackling a whole load of these developer “gold plated porcelain” problems - everything from a “glimpse” index of every commit in a repo to better Jenkins config and how to set up mTLS the hard way.
It’s “Thedevmanual” and someday I will have time to write it
I don't really understand this argument. It is not like a web based tool is stopping you from seeing the code in your editor. You just check out the code and now you are seeing the code in your fav editor. Which is exactly the same process you would use with this tool.