Couldn't agree more. I guess we _are_ getting old after all.
I've been using git since ~2014, never really thought about changing it: it's clear, well documented, and ok difficult learning curve but hey that's the fun part.
Don't want to sound old school, but git works perfectly fine.
The learning curve might be a bit difficult, but afterwards everything makes sense. And let's be honest, you just need a few actions (pull, add, reset, branch, commit) to use it in 95% of the cases.
git rebase -i lets you reorder commits easily, as long as they don’t have conflicts. If they do, you’re in for a rough time. I struggle to see how a vcs could help with that, even if I’d be happy to be proven wrong.
One cool tip to help with conflicts is the revert trick. If you have a conflict that you need resolved earlier in your commit chain, you can commit a cleanup that hides the conflict, revert it instantly and reorder the commits with interactive rebase to insert the revert first. It’s a bit hard to explain without an example, once you’ve tried it you will understand.
> as long as they don’t have conflicts. If they do, you’re in for a rough time. I struggle to see how a vcs could help with that, even if I’d be happy to be proven wrong.
A vcs can allow you to commit conflicts and then commit their resolutions whenever necessary. This has been pioneered by darcs (IIRC) and jj also allows that.
`git rebase -i` lets you reorder one branch of commits easily
in a stacked PR workflow, after the bottom PR merges, you now want to rebase the whole stack atop the main branch. if that's 3 PRs, that's 3 branches, 3 rebases
one thing `git rebase` doesn't let you do but `jj rebase -s source -d dest` does is move a commit from one branch to another (`git switch dest`, `git cherry-pick source`, `git switch -C source source^`, `git switch dest`)
If you work in a team you need to understand rebasing and squashing, unless you can convince team to never use these features.
A lot of people are religious about rebasing, "clean" commit history. But it's pretty much incompatible with several devs working on a single branch. I.e. when you work on something complex, perhaps under time pressure, git habits bite you in the ass. It's not fine.
As soon as you have the situation of multiple people working on the same branch, forbid force pushes at all times. But it's better to avoid that in the first place, all work should be on its own branch at all times.
For larger features we often have a feature branch with merge requests for various task branches. Limits the review sizes as well.
Of course, you can also then consider to use feature toggles, so there's no feature branch but just your main branch.
Years and years ago I worked on a team where linear commit history was required so every time a merge happened you had to manually rebase and push to Bitbucket. I put a PR in halfway through the sprint, rebased it a dozen times as everybody else's work got merged, and had nothing to show during review because nobody bothered to check mine and the only coworker I had in the same physical office was out on vacation.
When I interview for new roles I always make a habit of asking how work gets done to avoid shops that engage in these types of shenanigans.
bitbucket will merge a PR from your feature branch onto the base branch even if it's not fast-forward from the base branch. as long as you use the "squash" or "rebase" option on the PR interface (instead of the "merge" option), the resulting history will be linear
A lot of the time, multiple devs working on a single branch can be avoided via different decisions made upstream about work that needs done. If my job included more git wrangling as one of my daily tasks I would probably hate my job.
It looks pretty neat! Just wondering, what other languages are supported? English seems pretty natural as it is where GPT-3 thrives, but have you been able to support other languages as well?
Very much agree. I took RAW pictures with my Nikon on a christmas party, and even took the time to properly develop and adjust them.
Still, people complained on how "old and bad" their faces looked (in pretty normal pics, nothing fancy). I attribute this to the fact that everybody is now used to phones completely editing faces and smoothing skin and adding saturation, etc., which makes us more "instagramable" although less human.
I worked on Paint Shop Pro a long time ago, when they first added red eye correction. It did it not by manipulating the image, but by painting an artificial eye over the original. The dialog was hellishly complex since you had to specify not only how the new eye should look but how to make it match the original. But it delivered impressive results. Last I saw, it was scheduled to be replaced with something simpler and more traditional in the next version.
It's already happening. I saw an extreme eye enlarging filter accidentally applied to a video by Matt Risinger (YouTube videos about construction and homebuilding).
I think the iPhone is doing this with the portrait mode. It may just be the smoothing or a bit of lens fish eye creating the illusion, but I swear that all the portrait photos of me and my family have slightly larger eyes than reality.
Bad colleagues tend to come to you with far more problems than solutions. Any colleague that is constantly complaining about everything, but never suggesting solutions (nor wanting to discuss them) is a major flag IMO.
Best colleagues I have had would point out something to be fixed / improved, and immediately suggest a tentative solution. Worst colleagues would just blame others (major red flag) for any issue they encounter, and never put energy in solving them.
Intellij is definitely an amazing tool, but if you are comparing it to Vim, then I don't believe it is a correct nor fair comparison.
Vim is not an IDE, and adding an infinite amount of plugins with the purpose of making it IDE-like, then complaining about how slow it is and how much it crashes, and how much better a proper IDE is, is IMHO a misconception of the true power of such a tool like Vim.
in what was is it not fair? People use Vim to produce software and they use IntelliJ to produce software. IDEs try to do a lot more out of the box than an editor, and editors try to be really extensible
I've been using git since ~2014, never really thought about changing it: it's clear, well documented, and ok difficult learning curve but hey that's the fun part.