Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

15 years later, Microsoft morged my diagram

nvie.com

Post reply on HN
Print view View original

411–420 of 427 posts

Re: 15 years later, Microsoft morged my diagram

#411

Post by just6979 »

m12k wrote: post #137

Regarding the original git-flow model: I've never had anyone able to explain to me why it's worth the hassle to do all the integration work on the "develop" branch, while relegating the master/main branch to just being a place to park the tag from the latest release. Why not just use the master/main branch for integration instead of the develop branch - like the git gods intended - and then not have the develop branc…

The dev branch can be useful with larger team sizes where there might be lots of overlapping work being done. Or a shop that isn't fully into automated continuous delivery, ie: a human needs to press the button to actually deploy to prod. Not unheard of for high security things or anything where the accountability chain needs to be very explicit. The dev branch allows you to go full CI-CD-automation-everywhere to get changes into dev/sandbox deployment quickly, and then once it's fully and completely vetted there it can be merged to main and deployed to prod.

It can certainly be done without the dev branch, but you usually end up with lots of extra rules around merges and [ab]uses tags like branches in weird way. And it's way harder to revert things if it comes down to that. In short, if you need a semi-waterfall, less devops-ish, release process, the dev branch can assist that. If not, then it's just extra merges to manage and adds a bunch of work on keeping things in sync, especially with any kind of hotfixes in the picture.

Re: 15 years later, Microsoft morged my diagram

#412

Post by just6979 »

embedding-shape wrote: post #150
choeger wrote: post #144

Earlier quoted context omitted.

I am working with main/master for years now, and there's one problem you don't have with develop: Whenever you merge something into master, it kind of blocks the next release until its (non-continuous) QA is done. If your changes are somewhat independent, you can cherry-pick them from develop into master in an arbitrary order and call that a release whenever you want to.

> Whenever you merge something into master, it kind of blocks the next release until its (non-continuous) QA is done. That's what tags are for, QA tests the tagged release, then that gets released. Master can continue changing up until the next tag, then QA has another thing to test.

and Git Flow and similar day "that's what merges to main or for". GF and TDB really are way more similar than anyone wants to admit. It's basically "branch for release" vs "merge for release". There are benefits and downsides to both. IE: fully continuous and non-blocking QA/testing is non-trivial, and GF can help with keeping development on "the next thing" moving along without having the dreaded potential huge rebase looming overhead if QA comes back with lots of changes needed. Or just if some requirement changes come down from proect management.

For smaller projects with tests, something like TBD is great: easy to reason about, branches are free, tags are great. For bigger things with many teams working on overlapping features, keeping a TBD setup "flowing" (pun intended) can require a bit more fore-thought and planning. Release engineering, in other words. TBD vs GF is kind of just "do you want your release engineering at the beginning or at the end"?

Re: 15 years later, Microsoft morged my diagram

#413

Post by just6979 »

tlamponi wrote: post #293
franktankbank wrote: post #252

Earlier quoted context omitted.

It means you need a bugfix on your release and you don't want to carry in any other features that have been applied to master in the meantime.

In that case one can just branch off a stable-x.y branch from the respective X.Y release tag as needed. It really depends on the whole development workflow, but in my experience it was always easier and less hassle to develop on the main/master branch and create stable release or fix branch as needed. With that one also prioritizes on fixing on master first and cherry-pick that fix then directly to the stable branch…

"with potential adaptions relevant for the potential older code state there"

And there it is. Not "potential adaptations", they will be a 100% necessity for some applications. There are industries outside webdev where the ideals of semver ("we do NOT break userland", "we do NOT break existing customer workflows", https://xkcd.com/1172/) are strongly applied and cherry-picking backports is not a simple process. Especially with the pace of development that TBD/develop-on-main usually implies, the "potential older code state" is a matter of fact, and eliding the backport process into "just cherry-pick it" as you did is simply not viable.

Re: 15 years later, Microsoft morged my diagram

#414

Post by just6979 »

embedding-shape wrote: post #257
franktankbank wrote: post #252

Earlier quoted context omitted.

It means you need a bugfix on your release and you don't want to carry in any other features that have been applied to master in the meantime.

Usually what I've seen is one of two solutions, the former (usually) being slightly favored: A) hide any new feature behind feature flags, separate "what's in the code" from "how the application works" essentially or B) have two branches, one for development (master) and one for production. The production branch is what QA and releasers work with, master is what developers work with, cherry-picking stuff and backport…

The second one you described is basically GitFlow, just substitute "master branch" for "production branch" and "dev branch" for "master branch". I mean, you literally said "master is what developers work with", so why not call it the "development branch"?

Re: 15 years later, Microsoft morged my diagram

#415

Post by CGamesPlay »

crap101 wrote: post #400
jezzamon wrote: post #3

"continvoucly morged" is such a perfect phrase to describe what happened, it's poetic

Xebia slogan should be "Xebia, Morging Tomorrow with AI Today" https://github.com/MicrosoftDocs/learn/commit/e0af64352c7fdb...

Wow, the original was actually the real diagram at a thumbnail-quality resolution, so this was an AI upscaling or something like that.

https://github.com/MicrosoftDocs/learn/blob/c266367ec0eb1f7f...

Re: 15 years later, Microsoft morged my diagram

#416

Post by GreenWatermelon »

The first post this guy has written in years and it's LLM/AI Written.

> The AI rip-off was not just ugly. It was careless, blatantly amateuristic, and lacking any ambition, to put it gently. Microsoft unworthy. The carefully crafted visual language and layout of the original, the branch colors, the lane design, the dot and bubble alignment that made the original so readable—all of it had been muddled into a laughable form. Proper AI slop.

Here we see "not just x" pattern combined with 3-items list. The closing short quip, and an emdash despite the author never having used them in any of his older posts, even the one from 2021. I don't know of he told an LLM to generate a post for the irony effect, or if he just couldn't be bothered to write.

In his (or his LMM's) own words:

> obviously AI-slop-y enough

Proper AI slop.

Re: 15 years later, Microsoft morged my diagram

#417

Post by AlexeyBelov »

LauraMedia wrote: post #99
aftergibson wrote: post #82

Archive.org shows this went live last September: https://web.archive.org/web/20250108142456/https://learn.mic... It took ~5 months for anyone to notice and fix something that is obviously wrong at a glance. How many people saw that page, skimmed it, and thought “good enough”? That feels like a pretty honest reflection of the state of knowledge work right now. Everyone is running at a velocity where quality, craft and…

You are assuming: A) That everyone who saw this would go as far as post publicly about it (and not just chuckle / send it their peers privately) and B) Any post about this would reach you/HN and not potentially be lost in the sea of new content.

They are not assuming everyone would do that.

Re: 15 years later, Microsoft morged my diagram

#419

Post by JasonADrury »

ozim wrote: post #193
wiseowise wrote: post #170

Earlier quoted context omitted.

Can to share some of them? Genuinely curious.

I guess people one would follow on other platforms, plus bunch others posting in my native language. Daniel Stenberg Jason Fried David Heinemeier Hansson Nick Chapsas Laurie Kirk Brian Krebs

> Brian Krebs

Even Krebs has switched to posting uncritical AI slop now.

https://krebsonsecurity.com/2026/02/starkiller-phishing-serv...

A rewrite of slop post at https://abnormal.ai/blog/starkiller-phishing-kit

In the meanwhile, the exploit.in thread where this phishing kit is advertised is just full of users making fun of the author for selling vibecoded garbage. One user seems to have paid for the phishing kit, and says it just doesn't work at all and says the author blocked him on telegram after he complained.

It's a marketing piece hyping up a phishing kit that doesn't exist. Krebs gave up a long time ago, if he gave a shit he'd be more than capable of going on these forums to try and verify this story before uncritically repeating AI company marketing materials.

Re: 15 years later, Microsoft morged my diagram

#420

Post by rasz »

just6979 wrote: post #410

I don't think they "ran it through an AI image generator" to scrub it, I think someone asked an LLM for a description of a git branching model with an image to go along with it. Since there is _a lot_ on the web about GitFlow, it makes sense that the model would get connected to those embeddings, and of course the image is going to be connected as well. I think this just show how plaigarize-y LLMs are. There has been…

>I don't think they "ran it through an AI image generator" to scrub it

I mean they do have original in the repo https://github.com/MicrosoftDocs/learn/blob/c266367ec0eb1f7f...

Post reply on HN