I think a lot of memes are missing the main point of how it was caught, the exploit caused a spike in CPU usage for a network call. That made no sense to the guy Messiah who found/reported it. FOSS software’s strength is the number of critical eyes looking over each line of code you put out!
Right but the joke is that most developers aren’t of that quality, and are now going to put leredditor super sleuth eyes on every application they build
In a nutshell, a backdoor was intentionally planted by a malicious actor in xz Utils, an open-source data compression utility widely used in Linux and other Unix-like operating systems. This discovery was made by Andres Freund, a developer and engineer working on Microsoft’s PostgreSQL offerings. He was troubleshooting performance problems on a Debian system. Specifically, SSH logins were consuming excessive CPU cycles and generating errors with Valgrind, a memory debugging tool. Through sheer luck and Freund’s careful eye, he eventually discovered that these issues were the result of updates made to xz Utils. Upon closer inspection, he found that updates to xz Utils were the result of a maliciously inserted backdoor. The backdoor, present in xz Utils versions 5.6.0 and 5.6.1, manipulated the sshd executable, allowing anyone with a predetermined encryption key to upload and execute arbitrary code on affected devices.
I worked for a client where we had successfully delivered a working FOH site and booking/order system. A new head of marketing joined, and from the first meeting this guy proclaimed himself as a “tech lead” and evangelist. He wanted “full FTP access” within the first 5 minutes of our meeting. We told him we didn’t use FTP as everything was deployed via our CI pipeline, and he kicked off.
After some crisis meetings, he said he wanted to change the entire CMS to be HTML boxes, threatening to ditch us if we didn’t give him what we wanted. They were paying lots for this change, so in the end we obliged. He proceeded to delete basically everything we’d built, and tried to replicate all functionality using a A/B injection tool and a HTML field. Clients were pissed, because none of it worked, and they lost some serious money from it.
In the end, we rolled back and said “fuck it, full git access, you’re a dev now”, and at midnight he brought the site down because he decided to rewrite some db transaction logic to write data to another store. To him, transactions were “outdated tech”, and he tried to clean it up by just performing destructive changes on their own…
In the end, they ditched us, and we were glad to be gone (they bought out their own contract). Sadly, he got his way, changed his title to “lead tech director”, hired a team, and their site went from fairly slick to looking like something from Geocities. That company no longer exists, and sadly, I can’t remember his name so I can’t see where he failed upwards to.
stuff like this makes me so pissed that it’s so difficult to get into leadership positions for most people, those with connections and money are free to fail upwards and ruin things, but the average joe can be the genius of our age and be stuck working at starbucks for minimum wage their entire life…
It’s also frustrating that a lot of baffling corporate decisions aren’t even excusable as being for profit, it’s just some executive being a moron and no one stops them! If it was for profit i could at least feel nihilistic about it, but this is just corporations actively choosing to continue letting things happen that benefit no-one.
I always think about stuff like this whenever libertarians talk about how much more efficient corporations are than government. I’m like, “Have you ever worked for a corporation?” Organizations are just huge dumpster fires in general, because they’re all run by humans.
They’re not dumpster fires because they’re run by humans, but because they’re run by unaccountable hierarchies. Humans are perfectly capable of running a sustainable and efficient operation if we only stopped to consider how better to make decisions collectively.
Can you give some examples of well run organizations and the techniques they use? I legitimately want to know if it’s possible to do better than most of our current governments, companies, and societies in general. This world is a mess and I have half given up on it ever getting better.
Wikipedia - While the Wikimedia Foundation itself is hierarchical, it manages Wikipedia through a process of community-led governance. Every article is maintained by a community of volunteers who engage in open debate to decide on content moderation policies. Wikipedia remains one of the few popular websites to avoid the recent internet enshittification.
Food Not Bombs - An activist organization that serves free food. FNB has no central organizing body, instead operating as a loose-knit group of independent collectives who voluntarily cooperate and exchange information and resources with one another. One specific collective, “A Food Not Bombs Menu,” has taken to coordinating the global activities of FNB collectives and helping people start new ones, but has no power over any others.
IWW - The Industrial Workers of the World, while hierarchical, ensures a hierarchy that is accountable to its’ rank and file members by means of a robust democratic process, as well as the right of any member union or individual member to leave at anytime and go it alone.
There are many more, but it’s late and it took me a while to pick out what I think are good representative examples of different ways an organization can be run well.
Reality is a team sport, to some people. All they know is loyalty to hierarchy. If you’re below them and disagree, not only are you wrong, you are personally threatening them. Reasons do not exist.
A box that allows someone to write HTML and JS and have it appear verbatim on a web page.
A horrific idea, and one that’s surprisingly hard to implement, as any sane CMS will stop you executing random code onto a web page, and any sane framework would stop you building a form in a free text box to POST data.
Every time we tried to fight this he would say “but WordPress would let you do this”. He tried to petition his boss to rewrite an entire web site and application we’d just built and delivered to spec and on budget in WordPress because “it would be better”.
He sounds like someone who read a Wired Magazine article and figured that made him an expert.
That company no longer exists
Not surprising if they’re putting people like that dumbass in charge. It’s just unfortunate that idiots like that end up costing everyone else their jobs too.
What’s funny is that this wasn’t a small company either. I won’t name it because it’ll be very easy to find this person, but they landed a leadership position with very little experience - think a few years working as a dev, and maybe one as a manager.
In my eight years working in consultancy, I’ve seen plenty of examples of this. I could write a book on some of the mental shit I’ve seen, from workplace wellness app owners trying to bully me online for having a single bug in their app, to finding several GB of fake Katy Perry nudes stored in a production database for a major company. Tech is totally fucked.
Cool, so sunrise is at 8 PM now. Or maybe there’s just no consistent relationship between what a clock on the East and West coast of America say, and a call can’t be scheduled between them.
The real problem with time and date is that it has to fit social and natural systems as well as actual passage of time. A lot of nuance is unavoidable.
Or maybe there’s just no consistent relationship between what a clock on the East and West coast of America say, and a call can’t be scheduled between them.
If you get rid of timezones they all say the same time, no? If you want to schedule a call you just say the time and save the timzone offset fiddling.
The real problem with time and date is that it has to fit social and natural systems as well as actual passage of time.
Can you give any more concrete examples? None come to mind beyond habit, which is not an immutable thing.
The problem is that the date changes in the middle of the day. 00:00 (“midnight”) should occur around the middle of the night, so that one day (sunrise to sunset) has a single date assigned to it.
In my opinion it would make more sense to set 00:00 at slightly before sunrise (roughly 4:00 by my clock), that way one night “belongs” to the day that preceded it. But for whatever reason they decided that the date changes in the middle of the night. That’s fine. Middle of the day would not be fine.
The fact that you give a preference to change something here which you give as an example for something that shouldn’t be changed because it would be problematic is deeply ironic to me.
Also, again, I don’t really see the problem with changing the date in the middle of the day. It’s virtually the same as changing it at 00:00 or 04:00, you change the date once every 24 hours. Right now you have a situation where one persons 3rd of the month could be another persons 2nd or 4th, depending on where on the globe they are. That’s not really ideal either, especially for that call scheduling example by the GP.
Don’t you think it makes sense for the date to change while ~everyone is asleep?
International light-speed communication is what we internet dwellers are used to but it’s not most people’s experience. Most people rarely talk to people from another continent.
Oh don’t get me wrong, I see how it makes sense. I’m just saying that 1) it is arbitrary nonetheless and 2) it doesn’t outweigh the benefits that could be gained by using a single global timezone. Incidence angle of solar radiation is hardly something most people need or even want to track beyond a certain degree (dawn, noon, dusk, midnight), and the times that would coincide with at your latitude and longitude can be easily learned.
I guess I disagree about the benefits of a single global timezone. We already have that for technology to use - the unix timestamp. All potential benefits of a unified timezone could be (and are) gained by having software convert times to whichever timezone you need.
Maybe I’m missing something. What do you think the benefits would be?
We already have that for technology to use - the unix timestamp.
A unix timestamp is an offset to a UTC date, not a timezone. But fair enough, there is UTC. It’s not used by default however, except by scientists and programmers maybe.
Maybe I’m missing something. What do you think the benefits would be?
Removing ambiguity from casual language. Currently when you state a time you are almost always implying your local timezone applies, which might be unknown information to the recipient, especially with written sources like these comments here. With everybody using the same timezone instead you would always make an unambiguous statement about the specific time by default.
Currently when you state a time you are almost always implying your local timezone applies, which might be unknown information to the recipient, especially with written sources like these comments here.
In most people’s everyday life that’s really rare. And when it does happen it’s usually clarified. In more automated contexts (e.g. a scheduled YouTube premiere) the software converts it automatically - the author inputs the date and time in their own timezone, and viewer sees the converted date and time in their own timezone.
When it does happen it reminds us that the date and time falls on a different time of day for different participants.
With everybody using the same timezone instead you would always make an unambiguous statement about the specific time by default.
22:00, midday.
Person A: “Meet me here tomorrow at 01:00”
Person B: “Sure no problem”
… three hours later …
Person A: “Ugh, I told him to be here at 01:00, where is he?”
… 24 hours later …
Person B: “Ugh, he told me to come here at 01:00, where is he?”
And when it does happen it’s usually clarified. In more automated contexts (e.g. a scheduled YouTube premiere) the software converts it automatically - the author inputs the date and time in their own timezone, and viewer sees the converted date and time in their own timezone.
My point exactly though, this is a whole lot of complexity we could just get rid of by using a single timezone, with the added benefit of that working without any automation or clarification. Next Tuesday 14:00? Same time for everybody, regardless of locality. Everyone will know what part of the solar day that is for them by habit.
When it does happen it reminds us that the date and time falls on a different time of day for different participants.
The complexity of coordinating different solar cycles is there either way and unavoidable. So why not use the simpler system?
Meet me here tomorrow at 01:00
Yes, semantic drift in these terms would be unavoidable, but I still see the long-term benefits to clarity outweighing the short-term costs in it.
Anyone who works nights, or an evening job that runs late like a bar or something, is currently used to having the date change in the middle of their “day”. I don’t think it’s really that big of a deal. It would be super weird at first, but kids who grew up with it would find our current system just as bananas as we would find this.
Yeah but you still mentally consider it to be the same day as the preceding day, until you go to sleep. (Unless you stay up all night but that’s very uncommon, my sympathy to night shift workers)
If the date changes in the middle of the day, does that make the latter half of the day “tomorrow” from the first half? That’s absurd to me.
It’s not that simple as people has this urge to associate 12pm to noon and 12am to midnight. Just look at china where the whole country is under a single timezone despite spanning from UTC+05:00 to UTC+09:00. People on xinjiang ended up using their own unofficial timezone (UTC+06:00) for their daily activities instead of using china’s official timezone (UTC+08:00) because it’s inconvenient to them.
people has this urge to associate 12pm to noon and 12am to midnight
Yeah but that is exactly what I mean with habitual. It’s a learned association of questionable utility. It can be unlearned and replaced with 0400 is noon or 1600 is noon based on your longitude just as well. Dawn and dusk are dependent on latitude and have to be learned for anything not smack-dab on the equator anyway.
I can see why that would be inconvenient to people, but I would maintain that is only so due to them clinging to a habit.
It could be worse. What would happen on people that live in UTC+12:00 ? When your friend say “lets meet on Tuesday”, which Tuesday it is (because the day changes at noon)? People will resist such majorly inconvenience changes unless the benefit of switching is clear for them. Forcing unpopular changes will guarantee people using unofficial timezone which cause even more confusion down the line.
What would happen on people that live in UTC+12:00 ? When your friend say “lets meet on Tuesday”, which Tuesday it is (because the day changes at noon)?
Given how +12 is at the front of the “date wave” currently they would probably take it to mean the Monday/Tuesday noon.
People will resist such majorly inconvenience changes unless the benefit of switching is clear for them. Forcing unpopular changes will guarantee people using unofficial timezone which cause even more confusion down the line.
Yeah fair. To me the benefit is clear, there is no good rhyme or reason to timezones as a totality, we should come up with a better system. A straightforward approach like using UTC offsets seems best.
They just gave an example though of people who made up their own timezone because the official one was bad.
These systems exist for people and if no one other than programmers wants to do the internal calculus of “The sun is setting and they’re a quarter of the earths rotation Eastward, so that means they’re probably in bed” every time you want to call someone, then we shouldn’t make the standard that way.
You also get some things that become way more complicated, like “send the user a notification at the start of the normal working day”.
Right now you just look up the timezone in their profile and send it at 9:00, but without timezones, you need a “database of regional conventions for coordinating business hours”, which is just a worse way of having timezones.
Timezones exist because they have a purpose. UTC exists because having some sort of coordinated universal time is helpful and people (outside of Greenwich) don’t use it because it isn’t helpful to them, except in specific circumstances.
It’s like abolishing everything except latin1 because Unicode is a pain. Wanting to write your name in your traditional alphabet is just a habit that people can break.
They just gave an example though of people who made up their own timezone because the official one was bad.
Yeah, and in reply I argued that they did this out of not wanting to change their habit of associating 12 o’clock with noon. Which is in my opinion an understandable impulse but not a good reason to preserve the status quo.
and if no one other than programmers wants to do the internal calculus of “The sun is setting and they’re a quarter of the earths rotation Eastward, so that means they’re probably in bed” every time you want to call someone, then we shouldn’t make the standard that way.
But the standard is like that right now, worse even with DST and other complexities.
Right now you just look up the timezone in their profile and send it at 9:00, but without timezones, you need a “database of regional conventions for coordinating business hours”, which is just a worse way of having timezones.
Well no you need an offset. Like the user has set +8:30 as their offset, so send the notification at 00:30 UTC. That’s not worse than having timezones, that’s having timezones but simpler.
Timezones exist because they have a purpose.
Yeah, and some of those purposes are bonkers.
It’s like abolishing everything except latin1 because Unicode is a pain.
More like getting everyone to use Unicode, but whatever. Like I said I see why it would be unpopular to the point of being unenforceable, but that doesn’t mean an unambiguous way of communicating time as the default would be entirely undesirable.
My point is we have that unambiguous system you want. People don’t use it except in specific circumstances. Instead of saying those people are wrong, you can look at why they don’t use UTC for everything.
People don’t use UTC because people aren’t usually interested in universal time, they’re interested in time of day, which is fundamentally tied to the position of the sun and people’s day night cycles.
The people in China who made their own bootleg timezone illustrate that perfectly.
We don’t currently have to reason about where someone is physically located to know if they’re likely asleep. I’m in UTC-4. It’s 15:30. It’s 19:30 in London. I know the evening is advanced enough that I shouldn’t call my coworker there, but early enough that I can if it’s an emergency. I forgot California’s timezone, so I googled it, and it’s UTC-7, so it’s 12:30 there. I should probably wait half an hour to call to avoid the typical lunch hour.
Otherwise I use a tool to look up and see that solar noon in California is around 20:00, so people are probably doing their midday routines then. Except that California shifted business hours so that they’re offset an hour from solar noon to reduce energy consumption, which I didn’t know.
And what do we do about places like Texas where solar noon varies by more than an hour on different ends of the state? For simplicity, most regions like to synchronize working hours inside their contiguous economic sphere. So I can assume that the state would pass a law relating to what time was considered “convention”, since we need schools, businesses, banks and government services to be consistent inside a jurisdiction.
It’s important we have stuff like that be uniform, because jurisdictions have laws about stuff like preventing teens from working during school hours, or preventing schools from starting class so early it interferes with children’s sleep or staying in session so long it interferes with their evenings.
Texas can just mandate that standard business hours are 14:00 to 22:00.
Thank God they didn’t end up having to mandate that the standard business day is split across two different calendar days like California. Imagine the hell of child labor laws when you have to stipulate that teens can’t work between the hours of 15:00 and 1:00 the next day unless said scheduled interval begins on a weekend.
Business hours being posted as 00:00 - 03:00, 17:00-00:00 for things like Sandwich shops is my favorite though. “I closed for the night today at 3, but I’ll be open again later today in the morning at 17” just has a delightfully complicated inhuman ring to it.
There’s a reason people like their days to line up with their days, and we like to base our clocks around how we live our lives where we are, not where the sun in in Greenwich.
I fundamentally disagree that a system that’s identical to how we work with timezones but non-standard, like a UTC offset system you describe, is simpler than timezones, which are standardized UTC offsets. At best it’s timezones with a different name and more of them.
Latin1 is far simpler than Unicode, and doesn’t have conversion issues. It’s static and very difficult to get wrong. It’s clearly a better match for comparison to UTC-only. It’s only downside is that it leaves everyone outside of a small segment of the worlds population to build their own janky system for dealing with their silly human need to reason about time in an intuitive sense/write their names.
TL;DR - as long as people generally prefer to sleep when it’s dark and wake when it’s light (and they always will in general) time zones are basically needed as a form of lookup table for when to try to communicate with other places.
Well the essay has a lot to discuss, part of which is already (or will be) addressed up and down thread, so towards your TL;DR:
Yes of course, I’m not suggesting to disrupt circadian rhythms. And yes, lookup tables for solar days will always be required, but I would argue this is an inherent complexity to how we measure time in relation to our behavioural patterns and environment. However doing that by using variously large timezones that do not quite match solar days at their edges anyway, with a lot of them changing their offsets by an hour for half the year, and some of them using half-hour offsets throughout the year, that is complexity added for administrative reasons which are partly obsolete and largely irrelevant to the question off what would benefit humanity as a whole the most.
If everybody were to use one single timezone you would memorise your relative offset to noon/midnight pretty fast. Like it’s one number to remember, e.g. where you are 4:40am is noon, 4:40pm is midnight, your offset is -7:20. Having those times be (roughly) 12 (for half the year) is just tradition and something we have every child learn. We could teach them about solar offsets just as well. It’s not even really more complex, arguably much less so since you remove the need to confuse them with the chaos that global timezones have grown to be historically.
Subjective. It seems like it would be a bit confusing, though, if you had to relearn times whenever you travel somewhere (edit: and dates could flip over in the middle of a work day). But maybe you’d prefer that.
If you get rid of timezones they all say the same time, no?
Before they were invented, it was literally just anarchy. People set it to match people they knew. That’s what I was thinking of, but it could also just be one place where noon is at 12:00 PM.
Can you give any more concrete examples? None come to mind beyond habit, which is not an immutable thing.
Well, there’s not a round number of second in a day, or days in a year, for example, since they’re all naturally occurring and arbitrary. And then the Earth turns at a subtly non-constant rate, and people have settled on a seven day week. If you do have timezones, it doesn’t make sense to be inflexible with them when they run up against geography or trade and cultural ties, so they’ll be curvy, and geopolitics will itself change over decades and someone will want to change which one they’re in. All of this is a headache if you just want to do a calendar calculation.
It seems like it would be a bit confusing, though, if you had to relearn times whenever you travel somewhere (edit: and dates could flip over in the middle of a work day). But maybe you’d prefer that.
I’d prefer that over having to change clocks when you travel, and having to have knowledge about the location and possibly having to flip the date when you encounter a reference to a specific time, yes.
Before they were invented, it was literally just anarchy. People set it to match people they knew. That’s what I was thinking of, but it could also just be one place where noon is at 12:00 PM.
Yes, you would obviously do the latter. No sense it going back to the bad old days.
Well, there’s not a round number of second in a day, or days in a year, for example, since they’re all naturally occurring and arbitrary.
Days in a year ok (except leap years). But seconds in a day are round (discounting days with leap seconds). 24 * 60 * 60 = 86400, which is divisible by two. Did you mean they are not based on the decimal system? I’d be up for a decimal based time system and a reorganised calendar, but that wasn’t the topic of discussion here.
And then the Earth turns at a subtly non-constant rate, and people have settled on a seven day week.
Yeah but none of that has much impact on the timezone debate.
If you do have timezones, it doesn’t make sense to be inflexible with them when they run up against geography or trade and cultural ties, so they’ll be curvy, and geopolitics will itself change over decades and someone will want to change which one they’re in.
Fair enough. I acknowledged this point in my other post, that there are historical reasons for timezones mostly rooted in administrative requirements. But I don’t think this is a good reason to not adopt a better system per se.
All of this is a headache if you just want to do a calendar calculation.
Exactly! So out with the old, in with the new. Sure this will create some other headaches, especially given how deeply rooted some of the relevant nomenclature is in most languages, but the sooner we change this the less it will hurt. I see that it might be a non-starter given the inertia and disunity of globalised society working against it, but it still seems desirable nonetheless, to me at least.
Days in a year ok (except leap years). But seconds in a day are round (discounting days with leap seconds). 24 * 60 * 60 = 86400, which is divisible by two. Did you mean they are not based on the decimal system? I’d be up for a decimal based time system and a reorganised calendar, but that wasn’t the topic of discussion here.
Oops, I thought seconds were defined by the meter at some point. Nope, a pendulum 1/40000 of the distance from the pole to the equator just happens to measure the second near-perfectly, but the second stayed defined by astronomical motions until the atomic standard. Still, do to said variability of the Earth’s rotation since then it’s 86400.002, so even if it stopped changing we’d need leap seconds.
The point being that even if you get rid of timezones the calendar will still suck to work with. I question whether we should even have fixed days, months and years, if the time doesn’t relate to the position of the sun in the sky. You might as well just go with Unix epoch, and leave days to be informal. Of course, then you’d have to calculate multiples of 86400 a lot to set appointments. Maybe we need a new decimal second as well.
Yeah, tbh the “no timezones” approach comes with its own basket of problems that isn’t necessarily better than the “with timezones” basket. The system needed to find a balance between being useful locally, but intelligible across regions. Especially challenging before ubiquitous telecommunications
Imagine having to rethink the social norms around time every time you travel or meet someone from far away. They say “Oh I work a 9-to-5 office job” and then you need to figure out where they live to understand what that means. Or a doctor writes a book where they recommend that you get to bed by 2:00PM every night, and then you need to figure out how to translate that to a time that makes sense for you.
We’d invent and use informal timezones anyway, and then we’d be writing Javascript functions to translate “real” times to “colloquial” times, and that’s pretty close to just storing datetimes in UTC then translating them to a relevant timezone ad hoc, which is what we’re already doing.
That’s what my rational programmer brain says. My emotional programmer brain is exactly this meme.
My emotional brain thinks we should just give up and climb back into the trees.
Funny enough, a story just broke about a lunar timezone, which would lose a second or so every year relative to Earth due to relativity. If space travel becomes a big thing we’re going to have to choose a frame of reference, and probably just go with Unix epoch in that frame as the universal time. Hopefully it doesn’t happen to pass through a black hole, because there’s no consistent way to define a frame of reference that’s not subject to gravity.
China uses a single timezone where similar width countries use three or more. So some parts start the day at 8am, others start at 10am
If we used a single timezone in the west it would be UTC which is practically on the other side of the world to me - I’m in +11 now, +10 when we go back to standard time in a week. That would make it reasonably easy here, the clock would be out by near enough to 12 hours (if you prefer light in the evening) that you’d be fine on a 12 hour clock just inverting am and pm
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 want a strongly pro-vaccine culture, but whether or not to have vaccines mandated by the government is a tough dilemma for me.
I expect America’s overall health to improve and catch up with the rest of the world under RFK Jr. because of his support for vaccine/drug testing that’s free from corporate capture and his ambition to mitigate chronic disease.
I can respond to your point about conspiracy theories if you’re more specific.
If all of your supporters think vaccines cause diseases, if you're elected you're going to need to satisfy them by acting on those beliefs.
I think, in the abstract, you're right - having any sort of health procedure mandated by the govt is extremely problematic. However hugely communicable diseases are a big caveat to that principle, and we have been doing something about that for a long long time.
Typhoid Mary
was forcibly detained because, over and over again, she kept spreading the disease. Several different times, bird flu was halted before it could get too widespread because of govt mandated culls. Smallpox was completely eradicated because of vaccine efforts.
Imagine if in any of those cases people said 'freedom' was primary and prevented coercion for vaccines. The death and injury toll would be much higher by today, including those of the young and the immunocompromised.
Right now my gut reaction is that local governments, but not higher levels of authority, should be able to do what was done to Typhoid Mary, until we have sufficiently convenient and effective ways to be protected from contagious diseases without the cooperation of other people.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.