5 ms·
Author here, thanks for sharing your thoughts. Some of this is a product of the newness of the service, rather than a deliberate design choice. The latest commi
by Sir_Cmpwn 8y ago
Author here, thanks for sharing your thoughts. Some of this is a product of the newness of the service, rather than a deliberate design choice. The latest commit used to be here, but I removed it for performance reasons and will have to swing around later with a better approach. I haven't had time to implement git blame, though I want to.
>straight edit
Editing on the web _is_ a deliberate omission, and I consider this an anti-feature. Web edited commits on GitHub are notorious for failing to compile or pass tests, disregarding the style guide, etc - and raising the barrier to entry that little bit more helps to filter out this kind of noise.
>On example : making visual note of the currently selected tab, "Tree", I then click on "Log" to get this information. I then instinctively click on "Tree" again to come back, only to be greeted by the whole file tree. I have to manually press the browser's back button twice.
Hmm, this is a good point. I filed a ticket about this:
https://todo.sr.ht/~sircmpwn/git.sr.ht/188 https://todo.sr.ht/~sircmpwn/git.sr.ht/188
Thanks for the feedback!
- folkrav 8y ago> Editing on the web _is_ a deliberate omission, and I consider this an anti-feature. I prefer liberty of choice rather than such opinionated decisions, but that's not up to me. There's a rationale and I respect this. It's just convenience: I've honestly just been happy to be able to update some of my project's READMEs of wiki on my phone. As for failing tests or disregarding style guide, IMHO it's more up to the project to enforce these things rather than to my code hosting platform to limit possibilities. Again, this is largely preference. > Hmm, this is a good point. I filed a ticket about this: Will happily follow this!