I remember learning about how to use this back in the day and what a game changer it was for my workflow.
Today I like to do all of the commits as I’m working. Maybe dozens or more as I chug along, marking off waypoints rather than logging actual changes. When I’m done a quick interactive rebase cleans up the history to meaningful commits quite nicely.
The fun part is that I will work with people sometimes who both swear that “rewriting history” is evil and should never be done, but also tell me how useful my commit logs are and want to know how I take such good notes as I go.
At my company we just use a squash policy in gitlab. Every merge request becomes a single commit to the main branch. Super easy to read the commit log because all commits are descriptive instead of a bunch of “fix MR comments” or “fix pipeline errors”.
Another advice: git reset [commit-id] followed with a git commit -a is a quick way to squash all your commits.
Yes - “Rewriting history” is a Bad Thing - but o argue that’s only on ‘main’ (or other shared branches). You should (IMHO) absolutely rewrite your local history pre-push for exactly the reasons you state.
If you rewrite main’s history and force your changes everybody else is gonna have conflicts. Also - history is important for certain debugging and investigation. Don’t be that guy.
Before you push though… rebasing your work to be easily digestible and have a single(ish) focus per commit is so helpful.
review is easier since concerns aren’t mixed
If a commit needs to be reverted it limits the collateral damage
history is easier to follow because the commits tell a story
I use a stacked commit tool to help automate rebasing on upstream commits, but you can do it all with git pretty easily.
The only other time rewriting history might be bad is when you’re working on a shared branch, which is the point of not rewriting main. If you are working solo on a branch, its history is only what you merge into main so it doesn’t fucking matter at all. If you’re not working solo, maybe you need to adopt a similar process or look at how you’re not working solo. The only time I touch another dev’s branch is at the PR stage and only for quick corrections or missing knowledge so it doesn’t matter if they rebased before or honestly rebase after before the final merge.
This is really the only sane way to do it. I have run into some wonkyness with the commit history of the target branch commits not resembling git log, but that’s usually for commits outside of what I’m trying to merge.
Edit: squashing commits down this way also helps reduce problems with replaying commit history on the actual rebase. In most cases you don’t need all your “microcommits” in the history, and fewer commits just takes less time to reconcile.
Assuming the accounting system this thing links with both does not protect from SQL injection attacks (many don’t, despite it being easy to protect against) and also has a table named “Bills” with a field named “amount”; what this would do is go through every single Bills record and half the value in the amount field. This would completely fuck the system, particularly when it came to billing and tax filing as the numbers for accounts billing and receivable wouldn’t even come close to matching each other. The accounting department would have a hell of a time fixing the damage.
Yup. Rand() chooses a random float value for each entry. By default I believe it’s anywhere between 0 and 1. So it may divide the first bill by .76, then the second by .23, then the third by 0.63, etc… So you’d end up with a completely garbage database because you can’t even undo it by multiplying all of the numbers by a set value.
Also, by dividing by a number between 0 and 1, you increase the amount it looks like it billed. So income will look like it’s higher than outgoing funds, which will raise suspicions of embezzlement. And if someone actually is embezzling, whatever accounting tricks they’ve been using to hide it might just stop working because everything might need to be examined with a fine tooth comb. “Oh, the billing numbers aren’t right, and also it turns out the invoice numbers aren’t right either. Billing issue was tracked to a hack, but what’s going on with these invoices?”
if you’re trying to be malicious, wouldn’t it be better to multiply by Rand() instead of divide by Rand()?
assuming there are a decent number of recorded sales, you’d end up seeing many of the calls to Rand() returning values very close to 0. so, if you’re dividing by those values, you’d end see lots of sales records reporting values in the thousands, millions, or even billions of dollars. i feel like that screams “software bug” more than anything. on the other hand, seeing lots of values multiplied by values close to 0 would certainly look weird, but it wouldn’t be as immediately suspicious.
(of course a better thing would just be to use Rand() on a range other than [0,1])
I imagine they could if they knew exactly what you did and when, but if it doesn’t get discovered until later and nobody knows what happened, it would probably be a bitch to figure out
It seems like it would be fairly easy to find. All you need to do is find out where the price drops massively, and work backwards from there, since it doesn’t change the code going forward.
Pretty sure it would be obvious to anyone working there that chicken tenders are $10 not $5. Even a quick glance at any single bill would show the issue.
Yeah, obviously the issue can be discovered. My point is that it’s not going to be immediately discovered by the cashier or a customer. It’ll probably not get discovered until the accountant comes by and notices the discrepancy.
does not protect from SQL injection attacks (many don’t, despite it being easy to protect against)
Every modern database library automatically protects against SQL injection, usually by using prepared statements (where the query with placeholders, and the placeholder values, are sent as two separate things). so a system would have to be written extremely poorly to be vulnerable to it.
This post is just a joke as developers should hopefully be aware of the OWASP top 10 security vulnerabilities.
Edit: Bad developers will do bad things, but any reasonable developer should be well aware of these risks.
Well no. If the programmer uses prepared statements, they are protected. If they use a prepared statement but actually just put their own unsanitized statement in there and execute it, it's not protected.
Now, I'd like to say it is 2024 and everyone should be using AT LEAST prepared statements for security. I've seen people doing some scary things in my time, and that includes quite recently.
Bad developers will do bad things, but most DB framework documentation points people towards the right way to do things, which is why I said it’s not common any more.
Every modern database library automatically protects against SQL injection,
No. Every modern library allows using prepared statements, but very few (of any) force using them. If the developer doesn’t use them the libraries won’t do shit to protect you.
What I meant is that not many people write raw SQL in product code any more, other than for analytical purposes (which are often in a system like Apache Airflow rather than in product code). ORM systems have mostly taken over except for cases where you really need raw SQL for whatever reason.
First, injection attacks are third on the owasp list, although they do roll xss into it too, which changed the name, since “shit sanitization on input” and “shit escaping before use” are the cause of both. owasp.org/Top10/A03_2021-Injection/
Secondly, SQL injection is freakishly common and easy. I don’t know of any database libraries that prevent you from directly executing an SQL literal, they just encourage parameterized statements.
I have personally run into plenty of systems where people build SQL via string concatenation because for whatever reason they can’t use an orm or “proper” SQL generator.
You can find them in the wild fairly often by just tossing ’ or 1=1;– into fields in forms. If it gets mad in a way that doesn’t make sense or suddenly takes forever, you win!
That one was a treat when I check under critical, since it’s an injection attack that can bypass parameterized query protections for the database driver, which is why “defense in depth” and “always sanitize your fucking inputs” are such key things to remember.
I hope that provided what you’re looking for, and maybe increases your awareness of SQL injection. 😊
its an sql injection attack.
its rather unlikely that it works in a modern app.
assuming this would work,
it injects a command in the sql database.
it is assumed that the app runs a sql querry with the input field as a parameter e.g. INSERT INTO “bills” (item, ammount, tip) VALUES (“steak”, “20,00 $”, “content of the custom tip goes here”);
the semicolon indicates the end of the querry,
so the the text would cause the app to run an unfinished querry, and then start a new querry that messes up the content of the bills table.
Nothing. For one, it won’t let you enter letters. Two, the table structure to these POS systems are more nuanced than a simple bills table with am amounts field.
It’s amusing and all, but it’s not something you can do.
Source: work with, and develop around, these types of POS systems.
No you just do a rebase to bring it in. Assuming you’re making atomic commits you shouldn’t have a ton of merge conflicts. If you have to do this a lot, your branch scope is really bad and the problem isn’t in how you’re using got, it’s in how you’re slicing work.
If you try to pull someone else’s rebased / history rewritten branch, your git will tell you that it’s rejected. You can completely avoid this by merging instead of rewriting history.
You don’t pull rebased work pretty much ever. Rebasing is for feature branches by a single author to craft a high quality history, generally. It’s much, much better than littering your branch with merge commits from upstream.
If for some reason you do need to pull rebased changes, you simply do git pull --rebase. Works without issue.
Merge is taking all the code from the master branch and combining it with the task branch, resulting in a commit for just the merge itself.
Rebase is “re-basing” where your task branch was created from off the master branch. It essentially takes all the commits from master that happened since you branched, REWRITES THE HISTORY of your task branch by inserting those master branch commits before all your existing commits, and effectively makes your task branch look like it was branched yesterday instead of like 4 weeks ago. You changed where your task branch originated on the master. You moved its base.
So, with a merge you basically shuffle in the changes from both branches, but a rebase takes only the changes from one branch and puts it over the other? Edit: no. Read wrong. I should probably watch a vid about it or something
Kind of. Both merge and rebase result in the branches “synced up” but they do it in different ways.
Merge is making a batter for cookies, having a bowl for dry ingredients (task branch) and a bowl for wet ingredients, (master branch) making them separately and then just dumping the dry bowl into the wet bowl (merge).
Rebase is taking a time machine back to before you started mixing the dry ingredients, mix all the wet ingredients first then add the dry ones on top of that in the same bowl.
Merge takes two commits and smooshes them together at their current state, and may require one commit to reconcile changes. Rebase takes a whole branch and moves it, as if you started working on it from a more recent base commit, and will ask you to reconcile changes as it replays history.
That’s pretty cool, might actually do that. Tho, we currently don’t use the history as much anyways, we’re just having a couple of small student projects with the biggest group being 6 people. I guess it’s more useful if you’re actually making a real product in a huge project that has a large team behind it
Or, you know, on your own feature branch to clean up your own commits. It’s much, much better than constantly littering your branch’s history with useless merge commits from upstream, and it lets you craft a high-quality, logical commit history.
I was replying to the other comment, not yours. Though there’s not really a way of using rebasing without force pushing unless it’s a no-op.
Rebasing is really not a big deal. It’s not actually hard to go back to where you were, especially if you’re using git rebase --interactive. For whatever reason people don’t seem to get that commits aren’t actually ever lost and it’s not that hard to point HEAD back to some previous commit.
I know. Answered anyway because I thought of the same thing as you.
Though there’s not really a way of using rebasing without force pushing unless it’s a no-op.
I like to rebase after fetching and before pushing. IMO that’s the most sensible way to use it even in teams that generally prefer merge. It’s also not obvious to beginners since pull is defaulted to fetch+merge.
like to rebase after fetching and before pushing. IMO that’s the most sensible way to use it even in teams that generally prefer merge.
What do you mean? Like not pushing at all until you’re making the MR? Because if the branch has ever been pushed before and you rebase, you’re gonna need to force push the branch to update it.
Personally I’m constantly rebasing (like many times a day) because I maintain a clean commit history as I develop (small changes to things I did previously get commits and are added to the relevant commit as a fixup during interactive rebasing). I also generally keep a draft MR up with my most recent work (pushing at end of day) so that I can have colleagues take a look at any point if I want to validate anything about the direction I’m taking before continuing further (and so CI can produce various artifacts for me).
It’s also not obvious to beginners since pull is defaulted to fetch+merge.
Yeah, pull should definitely be –ff-only by default and it’s very unfortunate it isn’t. Merging on pull is kind of insane behavior that no one actually wants.
What do you mean? Like not pushing at all until you’re making the MR? Because if the branch has ever been pushed before and you rebase, you’re gonna need to force push the branch to update it.
Not everyone works in large orgs that require pull requests. We have a dev branch multiple devs push to and just branch off for test phase. So I commit locally (also interactive rebasing when fixing stuff from earlier). When I’m ready to push, I fetch, rebase and push. I never force push here.
Uh, it’s definitely a bad idea to be concurrently developing on the same branch for a lot of reasons, large org or not. That’s widely considered a bad practice and is just a recipe for trouble. My org isn’t that huge, and on our team for our repo we have 9 developers working on it including myself. We still do MRs because that’s the industry standard best practice and sidesteps a lot of issues.
You can do all that without force push. Just make a new branch and do the cleanup before the first push there. Allowing force push just invites disaster from junior developers who don’t know what they’re doing. If you want to clean up after them, that’s your business, I guess.
That’s exactly the same thing. A branch is nothing more than a commit that you’ve given a name to. Whether that name is your original branch’s name or a new branch’s name is irrelevant. The commit would be the same either way.
A junior cannot actually do any real damage or cause any actual issue. Even if they force push “over” previous work (which again, is just pointing their branch to a new commit that doesn’t include the previous work), that work is not lost and it’s trivial to point their branch to the good commit they had previously. It’s also a good learning opportunity. The only time you actually can lose work is if you throw away uncommitted changes, but force pushing or not is completely irrelevant for that.
Force pushes are perfectly safe if you’re working on your own branch, and even if you’re sharing a branch, you can still force push to it as long as you inform and coordinate with whoever else is working on that branch.
I wouldn’t recommend it. The Git documentation itself doesn’t recommend rebase for more than moving a few unpushed commits to the front of a branch you are updating. Using it by default instead of merge requires you to use --force-push as part of your workflow which can lead to confusing situations when multiple developers end up commiting to the same branch, and at worst can lead to catastrophic data loss. The only benefit is a cleaner history graph, which is rarely used anyway, and you can always make the history graph easier to read with a gui without incuring any of the problems of rebase.
At 10+ YOE, I use rebase almost exclusively. Branch from main, rebase to clean up commit history before putting up a PR. If commits are curated properly you don’t run into conflicts very often. Branches really shouldn’t be shared too often anyway, and the ones that are should be write protected.
Catastrophic data loss isn’t really possible either with git since it’s all preserved and you can git reflog even if you mess up.
Years of experience don’t really matter here, that’s just call to authority, in this case yourself. You might as well be the worst git user ever after 20 years of usage, or the best after 2. We don’t know that.
Anyway, what you’re saying basically requires a perfect world to be true. Feature branch flow is perfectly fine, but you do end up with merge conflicts constantly, unless you have cordoned off areas of the repo for certain users. Two people working on unrelated features, both change a signature of some helper/util method, merge conflict. Nothing serious, can be fixed in a minute, and rebasing or merging won’t help for either.
Merge is perfectly fine. And arguing about which strategy to use is one of those autistic debates we as an industry seemingly love to have. It doesn’t matter, but you’ll find people screaming at each other about it. See Emacs vs. Vi. Same crap.
When rebasing, it applies the changes without the commit history?
Does that mean that when you fast forward your main/dev branch and commit, you then add a single commit that encompasses every changes that were rebase?
No, there are no fast-forwards with rebasing. A rebase will take take the diff of each commit on your feature branch that has diverged from master and apply those each in turn, creating new commits for each one. The end result is that you have a linear history as though you had branched from master and made your commits just now.
If you had branched like this:
<span style="color:#323232;">A -> B -> C (master)
</span><span style="color:#323232;">
</span><span style="color:#323232;"> -> D (feature)
</span>
It would like this after merging master into your feature branch:
<span style="color:#323232;">A -> B -> C (master) -> E (feature)
</span><span style="color:#323232;"> /
</span><span style="color:#323232;"> -> D -------------------> /
</span>
And it would like this if you instead rebased your feature branch onto master:
<span style="color:#323232;">A -> B -> C (master) -> D' (feature)
</span>
This is why it’s called a “rebase”: the current state of master becomes the starting point or “base” for all of your subsequent commits. Assuming no conflicts, the diff between A and D is the same as the diff between A and D’.
This a really bad take and fundamentally misunderstands rebasing.
First off, developers should never be committing to the same branch. Each developer maintains their own branch. Work that needs to be tested together before merging to master belongs on a dedicated integration branch that each developer merges their respective features branches into. This is pretty standard stuff.
You don’t use rebasing on shared branches, and no one arguing for rebasing is suggesting you do that. The only exception might be perhaps a dedicated release manager preparing a release or a merge of a long-running shared branch. But that is the kind of thing that’s communicated and coordinated.
Rebasing is for a single developer working on a feature branch to produce a clean history of their own changes. Rebasing in this fashion doesn’t touch any commits other than the author’s. The purpose is to craft a high quality history that walks a reader through a proposed sequence of logical, coherent changes.
Contrary to your claim, a clean history is incredibly valuable. There’s many tools in git that benefit significantly from clean, well-organizes commits. git bisect, git cherry-pick… Pretty much any command that wants to pluck commits from history for some reason. Or even stuff like git log -L or git blame are far more useful when the commit referenced is not some giant amalgamation of changes from all over the place.
When working on a feature branch, if you’re merging upstream into your branch, you’re littering your history with pointless, noisy commits and making your MR harder to review, in addition to making your project’s history harder to understand and navigate.
Yeah, the image (not mine, but the best I found quickly) kinda shows a rebase+merge as the third image. As the other commenter mentioned, the new commit in the second image is the merge commit that would include any conflict resolutions.
The only difference between a *rebase-merge and a rebase is whether main is reset to it or not. If you kept the main branch label on D and added a feature branch label on G’, that would be what @andrew meant.
What you probably mean by duplicate commits is that it assigns new commit IDs to commits that have been rebased. If you had already pushed those commits, then git status will tell you that the remote branch and your local branch have diverged by as many commits as you rebased.
Well, and what is the “proper history”? If your answer is “chronological”, then why so?
For the rare times that it matters when exactly a commit was created, they’ve got a timestamp. But otherwise, the “proper history” is whatever you make the proper history. What matters is that the commits can be applied one after another, which a rebase ensures.
When you’re working on a branch and you continuously rebase on the branch you want to eventually merge to, then the merged history will look as if you had checked out the target branch and just made your commits really quickly without anyone else committing anything in between.
And whether you’ve done your commits really quickly or over the course of weeks, that really shouldn’t matter.
What is really cool about (supposedly) making commits really quickly is that your history becomes linear and it tells a comprehensible story. It won’t be all kinds of unrelated changes mixed randomly chronologically, but rather related commits following one another.
And of course, you also lose the merge-commits, which convey no valuable information of their own.
you also lose the merge-commits, which convey no valuable information of their own.
In a feature branch workflow, I do not agree. The merge commit denotes the end of a feature branch. Without it, you lose all notion of what was and wasn’t part of the same feature branch.
Well, with a rebase workflow, there should be no merge conflicts during the final merge. That should always be a fast-forward.
Of course, that’s because you shift those merge conflicts to occur earlier, during your regular rebases. But since they’re much smaller conflicts at a time, they’re much easier to resolve correctly, and will often be auto-resolved by Git.
You’re still right, that if you’ve got a long-running feature branch, there’s a chance that a conflict resolution broke a feature that got developed early on, and that does become invisible. On the flip-side, though, the person working on that feature-branch has a chance to catch that breakage early on, before the merge happens.
I tried their experimental Wayland session and it’s still super buggy on high refresh rate/high DPI screens (loads of graphical errors and artifacts) so still a ways to go imo
I tried it for a moment, made games stutter like hell, switched back. I know I need to go in and figure it out at some point, but it’s hard to muster the energy when X, for the most part, works fine.
From what I’ve seen, it probably has to do with my Nvidia GPU.
I’m currently at the point where I blame everything that works on my Laptop but not on my PC on Nvidia, because that’s literally the biggest difference between those two. Like currently my getty isn’t displaying properly, which is surely NVidias fault.
Depends on a few things with your setup: age of your GPU, the resolution/refresh rate of your monitor. I think even the choice of DP/HDMI can have an impact too
Platforms of the same nature like Mastodon.social ? Because no.
Actually, internal reports seem to indicate Twitter under Musk complies with much more takedown requests than it did previously, numbers seem to range from 80% to 98%, including requests from countries like China, Ethiopia, Turkey, etc. When people mention censorship by big tech the top three names are Twitter, Facebook, and Google. The only time I know of that twitter fought censorship was when India wanted them to takedown news about farmers’ protests, and Twitter lost in court, probably owing largely to the fact that he cut staff by 80% and ran the company’s finance into the ground by endorsing hate speech.
JS is absolute chaos programming and I love that way too much. You can just feel all the caffeine ingested by the guy who had to pull long nights to ship JS within 10 days. That’s exactly the vibe I’m going for with my code.
Writes custom parser in python to automate removing semicolons after braces. Figures out a preprocessing hook to execute it automatically from java compiler. Starts extending it for other things. Misses deadline. Extends it for more things. Gets fired. Ends up with a full python -> java compiler. Posts project on github. Gets made fun of.
Python supports both, it’s just not pythonic. It’s not the way it’s meant to be written but you can write them if you want/are a masochist, because of the syntax’s flexibility.
programmer_humor
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.