4 ms·
Thanks for the clarification. I would still see this as an instance of unnecessary complexity in the Git workflow - mostly the workflow for submitting, but not
by vog 9y ago
Thanks for the clarification.
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.
- zellyn 9y agoI 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 https://github.com/Microsoft/GVFS for the project, https://blogs.msdn.microsoft.com/devops/2017/11/15/updates-to-gvfs/ 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.