Same here, atuin is such a time-saver, especially when it comes "oh dang, I ran this command on another host but I need it here now". It just works as you'd expect!
150 karma · joined August 5, 2016
I am using vim/neovim for almost 15 years now. I was introduced to vim within _days_ after I started programming. I have a workflow where I open and close my editor several times per minute (although I'm now slowly moving away from this workflow) - startup speed matters a lot for this, of course. I never bothered to learn another editor or IDE because of the speed I get with (neo)vim. Moving my hands away from the homerow for interacting with IDE features just feels like driving a Porsche in a 10mph zone. I have muscle memory in my hands for over 10 years now!
I switched from vim to neovim at around neovim 0.5 mostly for ideological reasons, but I stayed for lua based plugins and a IMO better community. I rewrote my complete neovim configuration (which I took over from vim of course) about a month ago to be pure Lua and to be more streamlined... I don't consider this work or hoop-jumping at all, but optimizing my editing environment to safe time when actually editing source code (or emails fwiw).
On a side-note, I also use vim-ish bindings for everything else, for me DE/WM, Email client (which uses neovim to write emails actually), etc etc. I just don't see a point in un-learning all this.
Same here. Have been using git for over 10 years now though, so this might be an "experts view" kind of thing.
I see where this is coming from. That's why I do not let neovim hit me with completions all the time, but only when I request them. Most of the time, I can work with the (neo)vim builtins, like "complete word" or "complete line" and do not even use the language-server provided semantic autocompletion. But when I need to, it is only two keystrokes away.
With "I don't give a f..."-style I mean basically the idea that just committing away with some "wip"-style messages and then squash them all together before merging, or squash-merging them. This _kills_ all traceability and all future options to find out what was happening and _why_ (the whole reason git exists)!
In constrast, my workflow:
- Branch off of master
- Develop things, commit cleanly (which sometimes means 10s of lines of commit message for less than 10 lines of change!)
- Before everything goes into review, I revisit each commit. If there has to be formatting done, I create fixups for the individual commits and `--autosquash` them into the PR commits. Sometimes I even do something like `git rebase master -x "cargo fmt && git commit --amend --no-edit -a"` to automatically format each patch in the PR before submitting (or if I just missed to do it).
- Submit PR
- For each review comment, I create a fixup commit. As soon as I addressed all of the comments, I push the commits to the PR
- Repeat the step above until everyone is satisfied
- `git rebase master -i --autosquash` or, if master changed, sometimes even `git rebase $(git merge-base master HEAD) -i --autosquash`
- Wait for the PR to be merged
When a PR is ready, it could be one patch only, but also easily be 50 patches. Depends on the scope and size of the project and the PR of course.
This is my workflow for contribtions, both private and professional ones, but also for my private repositories (whereas "review" here is my own but also simply CI).
When working on projects on github in my free time, I even stopped submitting patches (after discussion of course) if projects use squash-merge, because if I put much thought and careful crafting into my commits and they just squash them anyways, I feel that they don't actually care and so there's no point in contributing for me.
(Edit: Formatting)
How does that even scale? I would imagine that in a team of 10, you would be rebasing 90% of your day and only 10% doing actual work?
This is what the project I was just hired to work on looks like. Result is a linear history, with multi-thousand-line changes in a commit with message "Implement fixes" and a list of "fix bug", "fix more", "format", "change implementation" in the long-form commit message.
People out there do not even know how to work properly with git, I think it is way too much for them when we start telling them how to "workflow" with git. It is sad, but that's what I see.
Me too, actually I hate conventional commits with a pattern, because I have never seen a "conventional commit message" that actually does a good job. I've recently even written a short article on that subject (https://news.ycombinator.com/item?id=29924976) because it is so annoying to me that people think writing a "conventional commit message" alone results in better quality (hint: it does not).
git is as simple as possible while being as powerful as possible.
What we need is better education! Not only how git works, but also how clean and scaling development workflows work. I've seen too much "Lets just copy the code to the production environment"-workflows in my live already and I do not even have 3 full years of professional experience as a SW dev!
The "pull-request-model" invented by github is an abomination of a workflow. Communities stop scaling because of it (see nixos/nixpkgs) because it does not allow horizontal scaling at all - thousands of "PRs" open, nobody feeling responsible and slowdown overall.
Having a tool that provides only an "overlay" over the workflow git wants to be used with, and that's what sourcehut is, but not a replacement for it (which is what github is), is refreshing and promising!