Git is amazing! Or Not!!
-
For those of you who don’t know who he is, he is the CTO and the only dev of Azure.
I wonder what part of Git got to him.
-
@stillwater said in Git is amazing! Or Not!!:
the only dev of Azure.
Huh?
Anyway, classic Poe-or-Noe shit-posting:
-
@topspin It’s a long running joke. Anyways the shitpost reply is top tier. Not surprised.
-
-
@topspin wtf am I even looking at!
-
@stillwater interestingly, the other day there was an article saying “Azure CTO says <hot take>”, and I’m like who cares? Then the article said “Mark Russinovich” and I thought “oh, that’s him? Why didn’t you say so earlier!”
-
@topspin It was some shit about how c++ and c shoidk die and we should start using Rust going forward. Can’t be arsed to dig deeper though
-
@stillwater that’s the one.
-
@stillwater said in Git is amazing! Or Not!!:
For those of you who don’t know who he is, he is the CTO and the only dev of Azure.
I wonder what part of Git got to him.
I sometimes wonder if I’m blessed or just read the manual because I never seem to have such a hard time with git. I will concede it is one of those tools that you have to bend to though. There's no fitting it to your flow. It's very much you fit to it's flow.
Mark always struck me as a decent developer but considering the shit show Azure appears to be I might have to revaluate that opinion.
-
@DogsB said in Git is amazing! Or Not!!:
Mark always struck me as a decent developer
Try his novels!
I've only read Zero Day. One would assume he gets better at the trade in later works, but...
-
@DogsB Azure was in full flight for a few years before Mark became its CTO. Probably late enough that the core design decisions were already taken and moving them will take more years yet.
As for having a hard time with Git, it mostly depends how dirty you get - if you just have commits and simple branching, it's not so bad. But the moment you start doing anything about manipulating branches (cherry picks, rebases, intentionally detached HEADs) things get messy fast if you're not fluent with what you're actually attempting to do.
-
@topspin said in Git is amazing! Or Not!!:
Azure CTO
Yeah, I didn't know that's who he was. I just know him for all the SysInternal tools.
-
FWIW, I’ve watched his talks and read his blog and books. They’re top notch. As far as how much role he had in making Azure the dumpster fire it is, I have no idea.
-
@Arantor said in Git is amazing! Or Not!!:
@DogsB Azure was in full flight for a few years before Mark became its CTO. Probably late enough that the core design decisions were already taken and moving them will take more years yet.
I hope he starts with firing or upskilling the Linux and java people. I hear that once you get past licensing stuff their own stuff isn't too bad. Saying that, friends with more experience, say they're better than google.
As for having a hard time with Git, it mostly depends how dirty you get - if you just have commits and simple branching, it's not so bad. But the moment you start doing anything about manipulating branches (cherry picks, rebases, intentionally detached HEADs) things get messy fast if you're not fluent with what you're actually attempting to do.
I suspect it's a not reading the manual problem. That stuff should be second nature but I understand
. The only reason I'm fluentish in git is vindictiveness. In my younger days I decided to out git the git person. I became the git. It really should have been a lesson but the same shit is happening to me now with AWS.@Applied-Mediocrity I'll add him to the list.
-
@DogsB said in Git is amazing! Or Not!!:
I hope he starts with firing or upskilling the Linux and java people.
So Azure became 'generally available' in 2010; Mark became CTO in 2014.
From personal experience it was still a dumpster fire for hosted infrastructure as of 2020.
For context, Company^-2 mostly was an AWS shop; they had a 'shared private cloud' that they let smaller clients use, hosting bill on that was five-figures a month, bigger customers paid their own bill and Company^-2 was essentially the configurer/manager of the infra. Several of Company^-2's prospective customers were like 'we want what you sell but we'd like it on Azure because MS are offering us steep discounts' because of which industry they're in, so the infra was adapted from AWS to build out small K8s clusters with pods running the software and all was... meh. It ran acceptably, never as well as it did on AWS, certainly not for comparable pricing, and on multiple occasions it blew up spectacularly and even MS themselves couldn't explain what went wrong.
I suspect it's a not reading the manual problem.
The manual has the same problem that most technical documentation has: it's written by someone intimately familiar with the technical gubbins who has no idea how to explain it to someone who doesn't.
As in, it makes sense if you already know what it says but if you don't, you're fucked until you can build your own mental model.
Tell you one thing about Git, I tend to give https://learngitbranching.js.org/ to new Git users to learn how to do it and not entirely fuck it up, has turned out alright in practice so far.
-
@topspin said in Git is amazing! Or Not!!:
@stillwater said in Git is amazing! Or Not!!:
the only dev of Azure.
Huh?
Anyway, classic Poe-or-Noe shit-posting:
That's a keeper.
Git gets easier once you understand branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.
-
@boomzilla endofunctor? I hardly know 'er
-
@boomzilla though I initially misread as homeoerotic and I don't think I'll ever remember it any other way.
-
@boomzilla said in Git is amazing! Or Not!!:
Git gets easier once you understand branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.
He's right, you know.
ed. degenerate
Sure is, Ed!
-
@stillwater said in Git is amazing! Or Not!!:
I wonder what part of Git got to him.
Probably the part with the
git. I find most of your problems start there.
-
@Parody and if they don't start there, they start with the inevitable "Initial commit."
-
@Arantor said in Git is amazing! Or Not!!:
As for having a hard time with Git, it mostly depends how dirty you get - if you just have commits and simple branching, it's not so bad. But the moment you start doing anything about manipulating branches (cherry picks, rebases, intentionally detached HEADs) things get messy fast if you're not fluent with what you're actually attempting to do.
This.
Also, Raymond Chen's series about avoiding cherry-picks spoke to me. Why I was like "aaAAH! A talking series of posts!"
-
Git always reminds me of that bit in the Red Letter Media review where Plinkett rearranges the letters in "Sith" to spell something else...
-
@Zenith said in Git is amazing! Or Not!!:
Git always reminds me of that bit in the Red Letter Media review where Plinkett rearranges the letters in "Sith" to spell something else...
This?
-
@Zenith Hits?
-
-
@Arantor said in Git is amazing! Or Not!!:
The manual has the same problem that most technical documentation has: it's written by someone intimately familiar with the technical gubbins who has no idea how to explain it to someone who doesn't.
It's a reference manual, not a training manual. They're entirely different.
-
@dkf sure but people still get pointed to it as if it’s a training manual and expected to figure it out, as far too many platforms/systems/etc do. Open source tends to be worse about this in general.
-
@Zenith said in Git is amazing! Or Not!!:
Git always reminds me of that bit in the Red Letter Media review where Plinkett rearranges the letters in "Sith" to spell something else...
For anyone not in the know, it's here: (the joke is 20 seconds long at 3:37 into the video, you don't need to watch the whole thing) (but you should if you haven't):
-
@Arantor My experience is that people find it hard until they internalise a mental model of branching. Without that, git's extremely difficult to understand. (The "distributed" part is just "some branches are only known in some places", but that's much easier to grasp than the idea that not everyone is looking at exactly the same thing.)
-
@Arantor beats "copied from CVS"
-
@dkf said in Git is amazing! Or Not!!:
just "some branches are only known in some places", but that's much easier to grasp than the idea that not everyone is looking at exactly the same thing.
Ah, they naturally expect to see the same thing when looking in different places? I don't think I should like to work where you do...
-
@Gribnit said in Git is amazing! Or Not!!:
@Arantor beats "copied from CVS"
It wouldn't surprise me if Linus built a special routine into git that runs
rm -rf /* --no-preserve-rootwhenever you try, out of pure spite for CVS. Subversion is not treated so badly, it would only scramble half your files.
-
@dkf said in Git is amazing! Or Not!!:
people find it hard until they internalise a mental model of branching.
Filed under: "just a monoid in a category of endofunctors"
-
I'm reminded of this ten year old article:
A common response I get to complaints about Git’s command line complexity is that “you don’t need to use all those commands, you can use it like Subversion if that’s what you really want”. Rubbish. That’s like telling an old granny that the freeway isn’t scary, she can drive at 20kph in the left lane if she wants. Git doesn’t provide any useful subsets – every command soon requires another; even simple actions often require complex actions to undo or refine.
Here was the (well-intentioned!) advice from a GitHub maintainer of a project I’m working on (with apologies!):- ....
- ....
- ....
- ....
- ....
- ....
- ....
- ....
Translation: “It’s easy, Granny. Just rev to 6000, dump the clutch, and use wheel spin to get round the first corner. Up to third, then trail brake onto the freeway, late apexing but watch the marbles on the inside. Hard up to fifth, then handbrake turn to make the exit.”
-
@JBert but what about GitHub?
-
@boomzilla said in Git is amazing! Or Not!!:
@boomzilla though I initially misread as homeoerotic and I don't think I'll ever remember it any other way.
Pounded In The Butt By The Lambda Calculus
(if this already exists, you have to create the non-Mike-Patton group - I don't make the laws...)
This is close, but it looks like it doesn't support arbitrary recursion.
-
@Gribnit looks like primitive recursion to me. Pounded in the butt by Ackermann would be stronger than that.
Filed under: gaze into the abyss
Filed under2: For god’s sake, leave the beavers out of this!, South Park
-
-
@boomzilla said in Git is amazing! Or Not!!:
@Gribnit said in Git is amazing! Or Not!!:
I don't make the laws.
Something we're all grateful for.
I’m pretty sure ignorantia juris non excusat could not possibly apply in that scenario.
-
@topspin said in Git is amazing! Or Not!!:
@boomzilla said in Git is amazing! Or Not!!:
@Gribnit said in Git is amazing! Or Not!!:
I don't make the laws.
Something we're all grateful for.
I’m pretty sure ignorantia juris non excusat could not possibly apply in that scenario.
Oh, it still would.
-
@stillwater said in Git is amazing! Or Not!!:
wtf am I even looking at!
Sounds like something @Gribnit would write
-
@Arantor said in Git is amazing! Or Not!!:
Tell you one thing about Git, I tend to give https://learngitbranching.js.org/ to new Git users to learn how to do it and not entirely fuck it up, has turned out alright in practice so far.
Does it also teach the 3-way merge algorithm and the art of conflict resolution?
In my experience that is the biggest hurdle for most people. They just consider the merge operation magic, so when it fails, they are at loss. And they stare at the conflicted changes and try to understand what they mean, but because they don't really see the changes that did not conflict, they often throw up their hands, pick something and then try to fix the code and that's massive pain. Instead, the correct answer is almost always to slavishly follow the same three-way merge algorithm, just with a bit more understanding of the structure of the code than the automated line-based implementation has.
In it's heart, the three-way merge takes the three versions — base, ours and theirs and tries to apply both the changes base→ours and the changes base→theirs. Which in the simple line-oriented form simply means if base and ours match, use theirs, if base and theirs match, use ours, if all three are different, declare a conflict.
So when you got a conflict, you just do the same thing, just with better understanding. Usually each side changed different argument to a function or something, so you just do the two changes. Don't think what they mean unless the code was completely kicked apart and reassembled.
And then there is one more bit to understand: that applying a patch and 3-way merge are the same thing except for different way of marking conflicts. The base and theirs are the
-and+part of the patch, and ours is the file you are applying to. Which transforms cherry-pick to the previous case.Long, long ago, darcs had a “patch algebra” description that described this rather formally. Which I liked, because I am a graph theory guy. But generally I find this missing from explanations of version control, and think it is critical to get a good hang of branching and merging.
-
@Bulb not very deeply IIRC, but the reality is that the folks I do this with inevitably don’t conflict that hard because inevitably we don’t do anything that deep or complex.
-
@Arantor What I occasionally see is that people reject the conflicting changes, thinking they don't need them now, without realizing that such rejections are permanent. And then wonder why the change isn't there since they are sure they did it.
-
@Bulb said in Git is amazing! Or Not!!:
@Arantor said in Git is amazing! Or Not!!:
Tell you one thing about Git, I tend to give https://learngitbranching.js.org/ to new Git users to learn how to do it and not entirely fuck it up, has turned out alright in practice so far.
Does it also teach the 3-way merge algorithm and the art of conflict resolution?
In my experience that is the biggest hurdle for most people. They just consider the merge operation magic, so when it fails, they are at loss. And they stare at the conflicted changes and try to understand what they mean, but because they don't really see the changes that did not conflict, they often throw up their hands, pick something and then try to fix the code and that's massive pain.
People really have trouble with that? Developer people?Maybe I'm just lucky, but I have not actually met anyone like that. Or maybe this kind of people just refused to use git and quit the job rather than switch. In that case, it is a plus for me.
Long, long ago, darcs had a “patch algebra” description that described this rather formally. Which I liked, because I am a graph theory guy. But generally I find this missing from explanations of version control, and think it is critical to get a good hang of branching and merging.
Yeah, that one is neat, but when I dug into it, I was disappointed to find that it does not actually describe the changes itself (= the diff), so it does nothing to actually prevent conflicts.
-
@Kamil-Podlesak said in Git is amazing! Or Not!!:
@Bulb said in Git is amazing! Or Not!!:
@Arantor said in Git is amazing! Or Not!!:
Tell you one thing about Git, I tend to give https://learngitbranching.js.org/ to new Git users to learn how to do it and not entirely fuck it up, has turned out alright in practice so far.
Does it also teach the 3-way merge algorithm and the art of conflict resolution?
In my experience that is the biggest hurdle for most people. They just consider the merge operation magic, so when it fails, they are at loss. And they stare at the conflicted changes and try to understand what they mean, but because they don't really see the changes that did not conflict, they often throw up their hands, pick something and then try to fix the code and that's massive pain.
People really have trouble with that? Developer people?Maybe I'm just lucky, but I have not actually met anyone like that. Or maybe this kind of people just refused to use git and quit the job rather than switch. In that case, it is a plus for me.
Yes. Actually I observed it well before git. Back in that day it usually manifested in the some people panicking when they needed to merge something, or sometimes even when it was just mentioned that some integration involving merging will have to be done.
Git made this worse as the distributed version control (and monotone, git, hg, bzr, brz, fossil etc. are all basically the same) means you are always working on a branch.
… which also didn't change from before. In cvs or svn the checkout is effectively a branch¹, just one that can't have multiple revisions on it, and when you do update, exactly the same 3-way merge operation happens as when you pull in DVCS. Just then the version control tool effed up the checkout, the affected developer cursed it to hell's hell and went on to redo their changes from memory.
Now that git is so explicit about it, and since it allowed workflows with feature branches become prevalent, those developers either express hate towards git up front, or they plod along, botch the next conflict resolution, and then express hate towards git. But I strongly suspect there is nothing specific to Git here. That it would be the same if they were to use mercurial or fossil or any other distributed version control system and feature-branch based workflow.
¹ The only exception I know of is ClearCase (
) with its dynamic view and exclusive checkouts. Really, the whole ClearCase () is a manifestation of the do not want mentality towards merges. And even that had UCM where it gave each developer a private branch, negating the shared nature, because it was actually unworkable. ClearCase () wasis an exercise in working around bad design through and through.
-
@Kamil-Podlesak said in Git is amazing! Or Not!!:
@Bulb said in Git is amazing! Or Not!!:
Long, long ago, darcs had a “patch algebra” description that described this rather formally. Which I liked, because I am a graph theory guy. But generally I find this missing from explanations of version control, and think it is critical to get a good hang of branching and merging.
Yeah, that one is neat, but when I dug into it, I was disappointed to find that it does not actually describe the changes itself (= the diff), so it does nothing to actually prevent conflicts.
It does have, or used to have, a special kind of patch for global token replacement, but I have no idea how well it actually worked. My guess would be it didn't.
Either way, the problems are that
- you can't solve all conflicts anyway, because if the two patches change exactly the same place to different results, well, that cannot be merged automatically, and
- some conflicts could be solved automatically by using finer granularity, but then you'd be increasing the risk that there is a semantic conflict anyway.
So there isn't really much that could be done. Well, you can introduce format-aware merge for some file formats, but that's about it.
-
@Bulb said in Git is amazing! Or Not!!:
So when you got a conflict, you just do the same thing, just with better understanding. Usually each side changed different argument to a function or something, so you just do the two changes. Don't think what they mean unless the code was completely kicked apart and reassembled.
And when the code really doesn't match up nicely, you need to understand the changes on each side to know how to reapply them. For example,. if one side is doing an internal API rewrite and the other is adding safety code, chances are you should accept the API changes and redo the safety code on top of that.
The bits I dislike are when the diff algorithm gets hung up on minor details and ends up effectively saying that the whole file is a colliding change; the merge algorithm is only as good as the diff generation algorithm's inputs. That's when it would be better if the differ knew the structure of what it was diffing (e.g., if you have that, you can sensibly do small changes to JSON, YAML and XML files).
-
@Bulb said in Git is amazing! Or Not!!:
Yes. Actually I observed it well before git. Back in that day it usually manifested in the some people panicking when they needed to merge something, or sometimes even when it was just mentioned that some integration involving merging will have to be done.
One person I worked with years ago had a simple solution to this (in SVN, but that's not important to this): always do a force-commit.
When I discovered that that was happening, I actually shouted at them on a project main telecon; it was the only time I've really lost my cool in a professional setting.
Git man page generator
salajander 🛩️ on Twitter
Amazon.com
