I'd respectfully disagree. In a monorepo the size of Google's (or even Square's, where I work now), there would be a whole schlep to open the file in your editor. Much better to fix right there where you're browsing.
Also, at Google, it's not even Git, or a Git/Github workflow.
Please respect the context of a comment, and refrain from strawman arguments.
This was not about whether or not this feature is good for the Google repo (of course it is, nobody disputed that!). This was about whether and how to apply this to other projects.
Please respect the fact that some of us actually read comments and reply to them thoughtfully. Throwing around trite accusations of “strawman” arguments doesn't help anything.
The comment I replied to was claiming that it was the git workflows (I assume for submitting, but am open to correction) that make this cumbersome. I was pointing out that in an enormous repository (and I did mention my current employer as an example too -- and we use Git, not Google's internal tooling), just getting to the point of having the latest version of some far-flung file that you usually never touch open in your editor is cumbersome enough to make this feature a win, regardless of whether the workflows for submitting the change disappear altogether.
I would still see this as an instance of unnecessary complexity in the Git workflow - mostly the workflow for submitting, but not just that.
Of course, one could also argue that this is by design. Still, I don't see why a lightweight client that is feasible for the web would not also be feasible for the command line.
For example, it would be great to be able to have a checkout with reduced history. You could reduce in time and/or space, i.e. just a subtree and/or just the last 3 months. Even a distributed VCS doesn't need all history and all files as long as it has the relevant checksums.
I totally agree about the unnecessary complexity of the git workflow.
If you haven't seen it before, check out gitless: actual research-backed simplification of the git commandline workflow.
Reduced views of files and history are super useful, but unfortunately don't work in the case where you've browsed your way to a part of the code that you seldom work on, since you're less likely to have loaded them into your narrow slice: it's still nice to be able to fix spelling mistakes far afield, and the web editing helps nicely for that.
What would help with the cases you describe, though, is a synthetic filesystem view, cache-faulted in as needed, like the one Microsoft is building. I'm pretty excited about where that's heading. https://github.com/Microsoft/GVFS for the project, https://blogs.msdn.microsoft.com/devops/2017/11/15/updates-t... for the announcement they're going to be working with Github. Pretty cool stuff.
Also, at Google, it's not even Git, or a Git/Github workflow.