No doubt. git rebase is like a very sharp knife. In the right hands, it can accomplish great things, but in the wrong hands, it can also spell disaster.
As someone who HAS used it a fair amount, I generally don’t even recommend it to people unless they’re already VERY comfortable with the rest of git and ideally have some sense of how it works internally.
Yeah it is something people should take time to learn. I do think its “dangers” are pretty overstated, though, especially if you always do git rebase --interactive, since if anything goes wrong, you can easily get out with git rebase --abort.
In general there’s a pretty weird fear that you can fuck up git to the point at which you can’t recover. Basically the only time that’s really actually true is if you somehow lose uncommitted work in your working tree. But if you’ve actually committed everything (and you should always commit everything before trying any destructive operations), you can pretty much always get back to where you were. Commits are never actually lost.
You can get in some pretty serious messes, though. Any workflow that involves force-pushing or rebasing has the potential for data loss… Either in a literally destructive way, or in a “Seriously my keys must be somewhere but I have no idea where” kind of way.
When most people talk about rebase (for example) being reversible, what they’re usually saying is “you can always reverse the operation in the reflog.” Well yes, but the reflog is local, so if Alice messes something up with her rebase-force-push and realizes she destroyed some of Bob’s changes, Alice can’t recover Bob’s changes from her machine-- She needs to collaborate with Bob to recover them.
Pretty much everything that can act as a git remote (GitHub, gitlab, etc.) records the activity on a branch and makes it easy to see what the commit sha was before a force push.
But it’s a pretty moot point since no one that argues in favor of rebasing is suggesting you use it on shared branches. That’s not what it’s for. It’s for your own feature branches as you work, in which case there is indeed very little risk of any kind of loss.
Ah, you’ve never worked somewhere where people regularly rebase and force-push to master. Lucky :)
I have no issue with rebasing on a local branch that no other repository knows about yet. I think that’s great. As soon as the code leaves local though, things proceed at least to “exercise caution.” If the branch is actively shared (like master, or a release branch if that’s a thing, or a branch where people are collaborating), IMO rebasing is more of a footgun than it’s worth.
You can mitigate that with good processes and well-informed engineers, but that’s kinda true of all sorts of dubious ideas.
Pushing to master in general is disabled by policy on the forge itself at every place I’ve worked. That’s pretty standard practice. There’s no good reason to leave the ability to push to master on.
There’s no reason to avoid force pushing a rebased version of your local feature branch to the remote version of your feature branch, since no one else should be touching that branch. I literally do this at least once a day, sometimes more. It’s a good practice that empowers you to craft a high-quality set of commits before merging into master. Doing this avoids the countless garbage fix typo commits (and spurious merge commits) that you’d have otherwise, making both reviews easier and giving you a higher-quality, more useful history after merge.
Why should no one be touching it? You’re basically forcing manually communicated sync/check points on a system that was designed to ameliorate those bottlenecks
No, you divide work so that the majority of it can be done in isolation and in parallel. Testing components together, if necessary, is done on integration branches as needed (which you don’t rebase, of course). Branches and MRs should be small and short-lived with merges into master happening frequently. Collaboration largely occurs through developers frequently branching off a shared main branch that gets continuously updated.
Trunk-based development is the industry-standard practice at this point, and for good reason. It’s friendlier for CI/CD and devops, allows changes to be tested in isolation before merging, and so on.
I have been using something very similar to this. In my team I insisted on people without any git experience working on a separate local branch, than the feature branch
. To ensure screw ups are minimal, we pull and create a local feature branch and then a new local only dummy branch, on top of it. Once the team is more comfortable with git, I am planning to treat the local feature branch as a dummy branch.
So far things have been pretty neat. Spaghetti is no more with minimal conflicts.
The UK press every year makes a huge song and dance in opinion pieces about getting rid of DST. However I’m always horrified to see that people want us to keep British Summer Time instead of Grenwich Mean Time. I understand that there are “longer evenings” in BST; however we literally invented GMT and coerced the rest of the world to adjust their times based on that. From the point of view of being constantly compatible with UTC and having more consistent business hours for international companies it makes more sense to me if we kept GMT.
Also the longer evenings thing can be achieved by simply staying up an hour later. It’s not exactly like an hour is being stolen from you when the times switch, the change of clocks are mainly pointless admin.
Lastly I read an article recently that described a correlation between the incidence of heart attacks and the clocks changing. The theory is that just slightly messing with people’s sleeping patterns can cause additional strain on the body.
No the longer evenings are achieved by work starting and ending an hour earlier. And it’s literally easier to change the time zone than to change corporate culture.
I think I want work to end an hour earlier in the winter because of how early the sun sets, and care much less about the summer. So however it’s done, it would be great if office jobs could happen when it’s dark outside and we could live our lives during daylight.
Mmm yeah I’ve noticed that my retired parents keep telling me what a great summer we’re having every year and I’m completely unaware of it due to being cooped up inside.
Another point for GMT, in the mid '70s, the US went onto DST year round for a couple years. People hated it so much they changed back to switching the time.
If we wanna do away with DST and BST, we need to go back to standard time, as the later sunset in the summer translates to no sunlight for workers in the winter
I know how to use git pull, git push, git commit, git status and git add *. I don’t even know how git commit and git push works I just know you run them in that order. Whenever I break everything I give up and go outside.
I’ve had transactions flagged for (intentionally) leaving large tips before. These large tips were justified for various reasons, such as comped meals.
What makes you think it was flagged for a large tip specifically, rather than just an unusually high transaction?
It still confused me how they would know it was a $20 steak and $80 tip versus 5x $20 steaks and no tip. It would appear the same, a $100 transaction at Bob’s Steakhouse.
The message specifically said it was due to the “unusually large tip”. They wanted me to confirm that it was intended.
If the article linked below is to be believed, the credit card company does indeed know how much of the transaction is a tip due to the way the transaction is processed. Note that this was at a full-service restaurant, not tipping at the counter for fast food or some other thing.
Consider when you pay with a credit card at a sit-down restaurant, they read the card first. Then you write in the tip on the receipt, meaning that they process this part later after the initial card reading. It is probably different with the tabletop self-checkout devices though.
I hate %, give me a option to round up to the nearest 5. This is useful for my financial tracking, and I’m willing to bet a lot of people would like nice round numbers. If I buy a coffee or whatever and it’s $7 I round up to $10, not because I’m trying to give a good tip but because it’s more convenient for me when I’m sitting there doing my finances (I track everything) and while I know that not everyone would universally agree maybe they would only want to round up to the nearest whole dollar the fact remains I feel like most places would actually end up with more total tips overall if that was a one button option
programmer_humor
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.