Live data from Hacker News

15 years later, Microsoft morged my diagram

nvie.com

291–300 of 427 posts

Re: 15 years later, Microsoft morged my diagram

#291
post #249

Earlier quoted context omitted.

Yeah I've been collecting some of the weirdest ones I've seen floating by. It's really the only thing that has me visiting linkedin. https://www.marginalia.nu/junk/linked/games.jpeg https://www.marginalia.nu/junk/linked/json.png https://www.marginalia.nu/junk/linked/syntax.png (and before anyone tells me to charge my phone, I have one of those construction worker phones with 2 weeks battery. 14% is like good for a co…

The red apple streams one is good. It shows how developers chase shiny new stuff with no respect for fundamentals. They will say it's less code, and then show you more code.

>> apples.stream()

>> .filter (a -} ajsRed());

>> .forEach(giveApple); [sic]

> The red apple streams one is good. It shows how developers chase shiny new stuff with no respect for fundamentals.

The problem isn’t streams, it’s slop.

Re: 15 years later, Microsoft morged my diagram

#293

Earlier quoted context omitted.

I'm not sure what you mean, what does "tag a bugfix", "tag the bugfix branch" or "ensure the bugfix ends up in the remote main branch as well as the release" even mean? What are you trying to achieve here, or what's the crux? I'm not 100% sure, but it seems you're asking about how to apply a bug fix while QA is testing a tag, that you'd like to be a part of the eventual release, but not on top of other features? Or i…

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.

With branching of stable branches as needed the git history gets less messy and stays more linear, making it easier to follow and feels more like a "only pay for what you actually use" model.

Re: 15 years later, Microsoft morged my diagram

#294

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…

> everything is moving very fast right now Now that's an interesting comment for him to include. The cynic in me could find / can think of lots of reasons from my YouTube feed as to why that might be so. What else is going on at Microsoft that could cause this sense of urgency?

From the beginning, one of the advertising tricks they have used for AI is FOMO. I presume that is so they can sell you as much of it as they can before you realize its flaws.

Everybody's so worried about getting in on the ground floor of something that they don't even imagine it could be a massive flop.

Re: 15 years later, Microsoft morged my diagram

#295
post #10

LinkedIn is also a great example of this stuff at the moment. Every day I see posts where someone clearly took a slide or a diagram from somewhere, then had ChatGPT "make it better" and write text for them to post along with it. Words get mangled, charts no longer make sense, but these people clearly aren't reading anything they're posting. It's not like LinkedIn was great before, but the business-influencer incentiv…

[deleted]

Re: 15 years later, Microsoft morged my diagram

#297
post #10

LinkedIn is also a great example of this stuff at the moment. Every day I see posts where someone clearly took a slide or a diagram from somewhere, then had ChatGPT "make it better" and write text for them to post along with it. Words get mangled, charts no longer make sense, but these people clearly aren't reading anything they're posting. It's not like LinkedIn was great before, but the business-influencer incentiv…

Yeah I've been collecting some of the weirdest ones I've seen floating by. It's really the only thing that has me visiting linkedin. https://www.marginalia.nu/junk/linked/games.jpeg https://www.marginalia.nu/junk/linked/json.png https://www.marginalia.nu/junk/linked/syntax.png (and before anyone tells me to charge my phone, I have one of those construction worker phones with 2 weeks battery. 14% is like good for a co…

Minecraft JAVA --------> C++

that one gave me an actual lol.

Re: 15 years later, Microsoft morged my diagram

#298
post #271

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…

If what they described is "trunk based development", then "git flow" is just "trunk based development where the trunk is called develop and there's a branch which always has the latest release". Is that it?

Nope. Gitflow is not trunk based development.

Re: 15 years later, Microsoft morged my diagram

#299
post #179
post #162

Earlier quoted context omitted.

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).

I think you're barking up the wrong tree here.

What?

This is how it works. There are too many people here like the op that make assumptions on what the process is/should be.

Re: 15 years later, Microsoft morged my diagram

#300
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…

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…

> but I think git-flow was popular largely because of the catchy name and catchy diagram.

It was because Git showed up in the era of SVN / CVS where those branching models were created because of the uh... let's just call it technical mishaps of those source control systems.

Git did not have the hang ups of SVN / CVS / etc but people stuck with what was familiar.

Post reply on HN