Quite a thoughtful way to adapt exams to wave of new tools for students and learn on the way.
I wished other universities adapt so quickly too (and have such a mindful attitude to students e.g. try to understand them, be upfront with expectations, learning from students etc).
Majority of professors are stressed and treat students as idiots... at least that was the case decade a go!
What! I was git gui user for decade and didn't notice this feature =D But yea, git gui is amazing overall. I don't think it's maintained anymore though.
BTW lazygit offers that too and it's a bit easier to discover and use (e.g. you don't need a mouse).
1. Yes, it's been a frustration initially, but it has a nice benefit - it forces you to use native features (e.g. patch based copy/reset). Apparently it's on the radar, but not implemented yet: https://github.com/jesseduffield/lazygit/issues/4365#issueco...
2. Yes, see https://news.ycombinator.com/item?id=45898167 discussion. Using IDE is great if all your machines has this IDE installed (and GUI in general). The stability (graphical layout) is likely changing often though.
That's a great point. I should have mention the IDE Git UIs, def a nice option and sounds like the JB one works well for you!
I do use it heavily for "annotating git blame"!
I've never consider using JB Git UI fully mainly because of the point made earlier, so stability (https://news.ycombinator.com/item?id=45898089). Once you learn, especially visually, you don't want cosmetic changes. IDEs change yearly to stay "consistent".
Another point is portability. E.g. I didn't want to pay for personal use of JB (so rare case), so I have to use different IDE. Separate tools (especially free and OSS) is a big advantage. Not mentioning ability to use it on remote shells or different machines!
lazy git offers 1, but 2 and 3 points are interesting. Wonder if there's an easy way to compare commits and filter commits by user and folder in lazygit. (:
EDIT: Actually, I also use JB for conflict resolutions ;P so not entirely 100% lazygit flow.
I think there's a learning around stability of devtools here. It takes time to get used to things, but once you do you are ultra productive. That's why IDE Git UIs are not ideal, because the graphics change so often, confusing you more than helping etc.
I got stuck to git gui / gitk for so long for this reason, I couldn't parse other UIs e.g. for diffs until I forced myself to have a less productive time to learn new UI.
I hope lazygit is stable - I think I might need to construct some stable config for visuals / colors to ensure this! (:
This is epic prove that we can still learn a lot from developers in 1980! Recently wrote "Effient Go" book and there were tons of valuable info from that era, and we usually skip this knowledge thinking it's irrelevant.
Amazing write up! Something I would add as open source maintainer:
* Feedback is needed. After years I built up a filter to annoying users, and I would simply ignore their feedback, but +1 and mentioning the feature would be useful is invaluable (and why you cannot use workarounds). Please do that in a nice, productive way (:
* It might be that the feature you and others are asking for was in paid version of the project, thus maintainers actively ignored it. Not the healthiest thing to do, but this happens, business matters, especially if governance is poor (single vendor behind the project).
* I think it would be useful to mention that if it's just a work needed and not other blocker, anyone would be welcome to create PR for the needed feature or at least moving it forward 10%. Sometimes faster that motivating your rights in issues (:
(Bartek here: I co-started Thanos and maintain it with other companies)
Thanks for this - it's a good feedback. It's funny you mentioned that, because we actively try to reduce the number of running pieces e.g while we design our query sharding (parallelization) and pushdown features.
As Cortex/Mimir shows it's hard - if you want to scale out every tiny functionality of your system you end up with twenty different microservices. But it's an interesting challenge to have - eventually it comes to trade-offs we try to make in Thanos between simplicity, reliability and cost vs ultra max performance (Mimir/Cortex).
Great initiative! Thank you for doing this, it's definitely nice from your side to spend time on community, especially if you have strong opinions on README look.
I wonder only, how to scale it (: Is there a way for anyone to help with this effort, while not spending O(n) time. Automation?