Yea, curious too about some more rules e.g. both parties has to contribute to the discussion (:
58 karma · joined December 25, 2016
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).
Fully agree!
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.
Yes, I think it's a reasonable option if you use vscode on all your dev machines.
We discussed this in another thread: https://news.ycombinator.com/item?id=45898167
Oh yes, I use lazygit as a separate binary (brew installed) from separate terminal shell all the time. No need for nvim!
Great to hear you can neatly configure similar UX (popup) with tmux!
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.
Yet, it is on top of HN (: Humans are interesting!
* 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 (:
Great job. Looking forward to exploring this more in the Prometheus and CNCF Ecosystem.
The underneath library used (https://github.com/segmentio/parquet-go) looks amazing too!
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).
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?
Let's create a CONFIGURATOR language (and secretly hide Go underneath)!
That's why IMO we should separate those. (:
> Templating systems are much more approachable for people who have a lot of experience configuring things via big blobs of text.
I have mixed feelings about this statement. How reading or using jsonnet is easier? I am a principal engineer and I am struggling to work with this, how less expierience people can deal with that efficiently? (:
I totally see this being difficult. To enforce DevOps/Ops to actually do code reviews, and versioned, type-safe configuration, but once you accomplish it - the profits are really worth it!
I really don't see why so many weird, unreadable languages like jsonnet or CUE were created, if there is already a type safe, script-like (Go compiles in miliseconds and there is even go run command), with full pledged IDE autocompletion support, abstractions and templating capabilities, mature dependency management and many many more.. Please tell me why we are inventing thousands weird things if we have ready tools that helps with configuration as well! (: