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

301–310 of 427 posts

Re: 15 years later, Microsoft morged my diagram

#301

Post by p_ing »

mcv wrote: post #285
p_ing wrote: post #166

Earlier quoted context omitted.

Did the one MSFT employee that “reviewed” it know of this image? If not, it doesn’t matter how many people “on the Internet” recognized this image. I’ll never understand the implied projection. (I don’t think this was reviewed closely if at all)

I would hope that the person who reviews their training on gitflow, knows something about gitflow. And if you know something about gitflow, it's not that strange to expect to recognise the most iconic gitflow diagram. But even if you don't recognise the original, at least you should be able to tell that the generated copy is bullshit.

Again, I don't think this was reviewed. It was an assignment to a vendor 'write document and I'll hit publish'. There's a great chance the MSFT document _owner_ has no experience in the relevant area.

Re: 15 years later, Microsoft morged my diagram

#302

Post by LoganDark »

andai wrote: post #272

https://en.wiktionary.org/wiki/morg Morg doesn't seem to be a word in English (though it is in Irish!), but it sounds like it should be. This is one aspect of AI I will miss, if we ever figure out how to make it go away. The delightful chaos. It invented a word here, without even meaning to. For example, I vibe coded a QWOP clone the other day, and instead of working human legs, it gave me helicopter legs. You can't…

> Morg doesn't seem to be a word in English (though it is in Irish!), but it sounds like it should be.

Maybe because English also has 'morgue'.

Re: 15 years later, Microsoft morged my diagram

#303

Post by bombcar »

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…

"git-flow" makes a lot more sense when you realize the "develop" branch doesn't have to be a branch "on the git server" and instead is your master branch you're fuddling with.

Re: 15 years later, Microsoft morged my diagram

#304

Post by GrinningFool »

p_ing wrote: post #162
AlienRobot wrote: post #151

Earlier quoted context omitted.

But if there are no gates, doesn't that mean the people who should have put the gates in there screwed up?

There is no singular publishing org at MSFT. Each product publishes its own docs, generally following a style guide. But the doc process is up to the doc owner(s).

That seems to further make the case that it's a systemic problem.

The organization would have more guardrails in place if it prioritized "don't break things" over "move fast".

Re: 15 years later, Microsoft morged my diagram

#306

Post by GrinningFool »

prmoustache wrote: post #68
anonymous908213 wrote: post #32

Microsoft employee (VP of something or other, for whatever Microsoft uses "VP" to mean) doing damage control on Bluesky: https://bsky.app/profile/scott.hanselman.com/post/3mez4yxty2... > looks like a vendor, and we have a group now doing a post-mortem trying to figure out how it happened. It'll be removed ASAFP > Understood. Not trying to sweep under rugs, but I also want to point out that everything is moving very f…

> In either case -- no review process, or a failed review process -- the failure is definitionally systemic. Ortho and grammar errors should have been corrected, but do you really expect a review process to identify that a diagram is a copy from another one some rando already published on the internet years ago?

I would personally expect review to evaluate for correctness. Such a review would have stopped this from being published. This diagram as published is literal nonsense.

Re: 15 years later, Microsoft morged my diagram

#308

Post by marssaxman »

zahlman wrote: post #74
marssaxman wrote: post #31

It seems to me rather less likely that someone at Microsoft knowingly and deliberately took his specific diagram and "ran it through an AI image generator" than that someone asked an AI image generator to produce a diagram with a similar concept, and it responded with a chunk of mostly-memorized data, which the operator believed to be a novel creation. How many such diagrams were there likely to have been, in the tra…

Yes, but from OP's perspective this is a distinction without a difference.

Clearly, but OP would be well advised to apply Hanlon's razor. The victimhood narrative does not improve understanding, which is necessary to work for better outcomes.

Re: 15 years later, Microsoft morged my diagram

#309

Post by ryukoposting »

QuiCasseRien wrote: post #256

This is the type of diagram that horrified me. It's a very very hard and time consuming task for dev to maintain hotfix for previous releases ! Yeah, easier for users, they don't have to care about breaking changes or migration guide. They just blindly update to the nearest minor. But as the time goes on, the code for dev ends up being a complete mess of git branches and backports. Dev finally forgot some patches and…

Yes, the original git-flow post aggregates several widely-held intuitions about git, and then shoves a bunch of fluff in the middle to make it look more appealing to middle management.

I have seen firsthand how the original git-flow post convinced management to move off SVN. In that regard, it's an extremely important work. I've also never seen git-flow implemented exactly as described.

...and frankly, there are better ways to use git anyway. The best git workflows I've seen, at small scale and large, have always been rebase-only.

Re: 15 years later, Microsoft morged my diagram

#310

Post by QuercusMax »

disruptiveink wrote: post #218
iainmerrick wrote: post #200

Earlier quoted context omitted.

You’re right. I think what you’re describing is “trunk based development” and it’s much better. Maybe I’m overly cynical but I think git-flow was popular largely because of the catchy name and catchy diagram. When you point out that it has some redundant or counter-productive parts, people push back: “it’s a successful model! It’s standard! What makes you think you can do better?” There’s a nice write-up of the trunk…

Correct. If you can always either fix it forwards or roll back, which you should be able to unless you're building software that needs to go out in releases with versions tracked separately that need to keep getting fixes, trunk-based development simplifies everyone's lives greatly. I've never seen an organisation that insists on release branches and complicated git merge flows to release their web-based software gai…

I've done branchy development to good effect for user-installable software, where we committed to maintain e.g. 3.2.x for a certain time period, so we had to keep release branches around for a long while.

But for continuously deployed SaaS or webapps, there's no point.

Post reply on HN