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

351–360 of 427 posts

Re: 15 years later, Microsoft morged my diagram

#351

Post by [deleted] »

whoknowsidont wrote: post #340
throwaway150 wrote: post #337

Earlier quoted context omitted.

> Yup, there would have been much less Git buy-in if it weren't for git flow I don't buy this. I've never used git-flow in life. No team I've worked for has ever used git-flow. Yet all of us have been using Git for ages. Git has been hugely successfully independently and different teams follow different Git workflows. Its success has got very little to do with git-flow.

>I don't buy this. It's not really debatable. Git flow came about because of SVN / CVS practices and was the first and for many still is THE branching model they use. >Yet all of us have been using Git for ages You say "all of us" but then you completely ignore the primary branching model the vast, vast majority of people use on Git. Just for the record, this isn't being stated in support of git-flow it's just a hist…

[deleted]

Re: 15 years later, Microsoft morged my diagram

#352

Post by dxdm »

p_ing wrote: post #299
dxdm wrote: post #179

Earlier quoted context omitted.

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.

My dog does this thing where she picks a stick and gets you to pull on it, and she will pull on her end, too. She gets very focused on it. Pulling on the stick is the most important thing to her in that moment, when in fact it's just a stick she chose to turn into this tug of war.

That's not entirely unlike what you're doing here. You latched onto a misunderstanding of OP's intent, and by making a thing out of it got people to pull back, and now you also keep tugging on your end.

Except she does it on purpose and enjoys it, while I think you did it inadvertently and you do not seem that happy. But then, you're not a dog, of course.

You could stop pulling on the stick. I do enjoy these doggy similes, though. :)

Re: 15 years later, Microsoft morged my diagram

#354

Post by csours »

idop wrote: post #333
fnands wrote: post #128

Earlier quoted context omitted.

Another similar story: My aunt passed away last year, and an acquaintance of my cousin sent her one of those "hug in a box" care packages you can buy off Amazon. Except when it was delivered, this one said "hug in a boy" and "with heaetfelt equqikathy" (whatever the hell that means). When we looked up the listing on Amazon it was clear it was actually wrong in the pictures, just well hidden with well placed objects i…

Reminds me when one Valentine's Day or whatever a new booth popped up at the mall where my gym was. They sold these nice heart-shaped chocolate boxes. I bought one for my sister. When she opened it, she found one piece of chocolate, and the rest of the box was filled with blocks of Styrofoam... The next day the booth was gone.

Damn, that sounds like a bit that would be cut from a romantic comedy for being too on the nose.

Re: 15 years later, Microsoft morged my diagram

#355

Post by dsego »

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…

We've been using feature flags but mostly for controlling when things get released. But feature flags carry their own issues, they complicate the code, introduce parallel code paths, and if not maintained properly it gets difficult to introduce new features and have everything working together seamlessly. Usually you want to remove the flag soon after release, otherwise it festers. The production branch is also ok, but committing out of order can break references if commits are not in the same order as master, and patching something directly to prod can cause issues with promoting changes from master to prod, it requires some foresight to not break builds.

Re: 15 years later, Microsoft morged my diagram

#356

Post by 16bytes »

flurdy wrote: post #214
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…

LOL, calling Scott Hanselman a 'VP of something' is funny. Been listening to his stuff for years, even when I despised MS. Always seems genuinely nice. Probably one of the main reasons I these days have a more positive image of Microsoft.

I thought the same thing. Scott is basically CEO of devrel at Microsoft.

Maybe we're of a different age to remember when Scott was super influential as a blogger / conference speaker, but even now he's not some random VP.

Re: 15 years later, Microsoft morged my diagram

#357

Post by throwaway150 »

whoknowsidont wrote: post #340
throwaway150 wrote: post #337

Earlier quoted context omitted.

> Yup, there would have been much less Git buy-in if it weren't for git flow I don't buy this. I've never used git-flow in life. No team I've worked for has ever used git-flow. Yet all of us have been using Git for ages. Git has been hugely successfully independently and different teams follow different Git workflows. Its success has got very little to do with git-flow.

>I don't buy this. It's not really debatable. Git flow came about because of SVN / CVS practices and was the first and for many still is THE branching model they use. >Yet all of us have been using Git for ages You say "all of us" but then you completely ignore the primary branching model the vast, vast majority of people use on Git. Just for the record, this isn't being stated in support of git-flow it's just a hist…

> It's not really debatable.

Very weird for you to start a reply like this when we are literally debating it.

> You say "all of us"

Yes, I mean those of who don't use git-flow. That's what I meant by "all of us".

> ignore the primary branching model the vast, vast majority of people use on Git.

Do you live in a git-flow bubble or what? I've been using VCS since the dark ages of CVS. Moved to SVN. Mercurial. Git. Never worked in a team using git-flow. Never used git-flow myself. Never met anyone IRL who uses git-flow. I only read about these things on HN and blogs.

What kind of stats do you have to claim that this is the primary branching model. If I go by my experience, it's a minority branching model that only people living within the bubble care about.

> it's just a historical fact that's not really debatable.

What is a historical fact? That people use git-flow. Nobody is contesting that. What I am contesting is that the success of Git is not connected to git-flow like the grand-grand-parent comment said.

Re: 15 years later, Microsoft morged my diagram

#358

Post by keithnz »

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 branching strategy we use is features are branched off master, as features are finished we then pick what ones we want to bundle into a release, create a release branch from master, merge features into it, we go through QA, when that release is ready, we merge to master. Meanwhile new features are still being worked on based off master. This works really well as it gives you a lot of control over when things get released and manage testing impact / user impact. This also makes it really easy to back out of a feature without it polluting a "develop" branch that other features have branched off. All features are based on code that is actually deployed.

Re: 15 years later, Microsoft morged my diagram

#359

Post by Mixtape »

alex_suzuki wrote: post #353

For context: > At Microsoft, we're working to add articles to Microsoft Learn that contain AI-generated content. Over time, more articles will feature AI-generated text and code samples. From: https://learn.microsoft.com/en-us/principles-for-ai-generate...

Great. As if Learn articles weren't already a mess to begin with.

A few weeks ago, I needed some syntax information to help with building out a PowerShell script. The input and output parameter sections each included "{{ Fill in the Description }}"[1] in lieu of any meaningful content. There wasn't even a link to the data type's description elsewhere in the Learn database. I was ultimately able to get done what I needed to do, but it really irked me that whoever developed the article would publish it with such a glaring omission.

[1] https://learn.microsoft.com/en-us/powershell/module/microsof...

Re: 15 years later, Microsoft morged my diagram

#360

Post by dcrazy »

QuercusMax wrote: post #310
disruptiveink wrote: post #218

Earlier quoted context omitted.

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.

Until you have a customer that must stay on v.previous for extra time for some reason.
Post reply on HN