Live data from Hacker News

15 years later, Microsoft morged my diagram

nvie.com

421–427 of 427 posts

Re: 15 years later, Microsoft morged my diagram

#421

Earlier quoted context omitted.

> 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. Neve…

I'm not debating it... we're not debating it. You're having it explained to you. >If I go by my experience That would be the very definition of a bubble.

This is one of the most ridiculous comments I've ever read on Hacker News. You really think git became popular because someone wrote up a branching convention for it?

Git became popular because it was one of the first two open source distributed version control systems. Compared to the least-bad open source (non distributed) version control system before, SVN, the native branches and the ability to have a local copy of the whole tree were self evidently a revolution.

(The other one was Mercurial by the way, released at almost exactly the same time as git. Partly git won that race because of the cachet of being written by Torvalds and being used for the kernel, but I suspect mainly it was due to the existence of GitHub.)

Aside from the above, it's also just clearly not true that git flow was particularly common. It's no good claiming anyone that disagrees is in a bubble. We all have access to GitHub! Look for yourself at some random repos (and make sure you sample a few different languages). It will verify my experience of looking at dozens, probably hundreds, of repos over many years: the number of people using git-flow is, to a first order approximation, roughly zero.

Re: 15 years later, Microsoft morged my diagram

#422

Earlier quoted context omitted.

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. Espec…

At work, we do what I wrote frequently, and it works very well and adaptions are rather the outlier than the norm, especially as we focus on backporting only important bug fixes and especially security fixes. We do also pour quite a bit of effort into separating changes into actual sensible commits (not just PRs), which is a bit of work but pays off dramatically if one has older releases they want to provide security and (grave) bug fix support. I.e., this is not just some random thought experiment, my staff and I successfully employ this approach for well over a decade (and about another decade before my time at the company).

Sure, not all workflows are a good fit for this, that's why I started with a disclaimer. But, if you want to do stable release in general, then it's IMO better to adapt the general workflow to that (which provides other benefits too, like on bisecting or when writing actually good release notes), than trying to force that on a not so compatible workflow.

But I'd be happy to hear alternatives, like how you solve this; always interesting to read others perspectives that lay out their solutions (not just why mine doesn't work 1:1 for you, which is basically a given for any non-trivial project).

Re: 15 years later, Microsoft morged my diagram

#423

Earlier quoted context omitted.

"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. Espec…

At work, we do what I wrote frequently, and it works very well and adaptions are rather the outlier than the norm, especially as we focus on backporting only important bug fixes and especially security fixes. We do also pour quite a bit of effort into separating changes into actual sensible commits (not just PRs), which is a bit of work but pays off dramatically if one has older releases they want to provide security…

Not sure I need to give any example solutions, because you've already explained that your solution isn't great, "mine doesn't work 1:1 for you, which is basically a given for any non-trivial project", and that applies for most solutions. But I will:

* GitFlow isn't perfect, but works for many, especially projects with lots of contributors working concurrently, and double especially if there are release gates that keep a human (release engineers) in the CI/CD loop for accountability, which is not uncommon in real world commercial projects. * GitHubFlow works for lots, but not all. Pretty good for moderate team sizes with some but not so much concurrent overlapping work, and perhaps a dedicated release engineer to handle those "potential adaptations". * TBD works for some, but can be inappropriate for many, especially when there are long-lived stable branches with commitments to ongoing security and bugfixes and the team size is smaller such that dedicated release engineers are not a thing.

This list is obviously not comprehensive, and just pulls from some workflows commonly presented elsewhere in this post.

Basically, I was just saying that one _can't_ just "[fix] on master first and cherry-pick that fix then directly to the stable branch with potential adaptions", because in most projects (non-trivial, as you said, which probably means anything with more than a couple contributors and an actual concept of a "stable branch") there will always be adaptations that need to be considered to maintain the stableness of that stable branch. And that's stableness from the user/customer/client PoV of "it acts the same but with less undefined behavior [read: bugs]", not just the dev PoV of "tests pass and it doesn't crash".

Re: 15 years later, Microsoft morged my diagram

#424

Earlier quoted context omitted.

I'm not debating it... we're not debating it. You're having it explained to you. >If I go by my experience That would be the very definition of a bubble.

This is one of the most ridiculous comments I've ever read on Hacker News. You really think git became popular because someone wrote up a branching convention for it? Git became popular because it was one of the first two open source distributed version control systems. Compared to the least-bad open source (non distributed) version control system before, SVN, the native branches and the ability to have a local copy…

The time you spent writing this comment you could have been googling.

I know it's within HN's nature to be contrarian for the sake of being contrarian but this is absurd.

Re: 15 years later, Microsoft morged my diagram

#425

Earlier quoted context omitted.

This is one of the most ridiculous comments I've ever read on Hacker News. You really think git became popular because someone wrote up a branching convention for it? Git became popular because it was one of the first two open source distributed version control systems. Compared to the least-bad open source (non distributed) version control system before, SVN, the native branches and the ability to have a local copy…

The time you spent writing this comment you could have been googling. I know it's within HN's nature to be contrarian for the sake of being contrarian but this is absurd.

[deleted]

Re: 15 years later, Microsoft morged my diagram

#426

Earlier quoted context omitted.

This is one of the most ridiculous comments I've ever read on Hacker News. You really think git became popular because someone wrote up a branching convention for it? Git became popular because it was one of the first two open source distributed version control systems. Compared to the least-bad open source (non distributed) version control system before, SVN, the native branches and the ability to have a local copy…

The time you spent writing this comment you could have been googling. I know it's within HN's nature to be contrarian for the sake of being contrarian but this is absurd.

Your previous comment was ludicrously arrogant and overconfident ("You're having it explained to you.") especially given that you're wrong.

Rather than lower myself to your level, I carefully explained the reality of the situation, complete with a mention of how I actually did check what you said (despite having overwhelmingly enough experience of version control to already be certain it's nonsense).

Clearly you didn't do the reasonable thing of rethinking your understanding or checking for yourself because you took your arrogance up a notch by telling me to do a Google.

Please get a grip on yourself.

Re: 15 years later, Microsoft morged my diagram

#427

Earlier quoted context omitted.

The time you spent writing this comment you could have been googling. I know it's within HN's nature to be contrarian for the sake of being contrarian but this is absurd.

Your previous comment was ludicrously arrogant and overconfident ("You're having it explained to you.") especially given that you're wrong. Rather than lower myself to your level, I carefully explained the reality of the situation, complete with a mention of how I actually did check what you said (despite having overwhelmingly enough experience of version control to already be certain it's nonsense). Clearly you didn…

>I carefully explained the reality of the situation

No you didn't, because it's not factual lol.

Post reply on HN