Live data from Hacker News

15 years later, Microsoft morged my diagram

nvie.com

381–390 of 427 posts

Re: 15 years later, Microsoft morged my diagram

#381
post #265
post #59

This is so out of hand. There's this. There's that video from Los Alamos discussed yesterday on HN, the one with a fake shot of some AI generated machinery. The image was purchased from Alamy Stock Photo. I recently saw a fake documentary about the famous GG-1 locomotive; the video had AI-generated images that looked wrong, despite GG-1 pictures being widely available. YouTube is creating fake images as thumbnails fo…

Youtube has recently recommended me a video of Feynman allegedly explaining why we couldn't go to Mars and back. I am normally on Youtube for something specific and don't follow recommendations, but hey, it's Feynman and I haven't seen it before, so I had to watch. After a few seconds it has become very clear that the video is totally fake. Then I started digging, and it turned out that both voice and the text it say…

Same thing happened to me, a fake Feynman video that seemed really off after only a few seconds.

The more AI shit I see, the more I find myself agreeing with the Luddites and the Amish.

Re: 15 years later, Microsoft morged my diagram

#382

Earlier quoted context omitted.

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

Re: 15 years later, Microsoft morged my diagram

#383

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.

> I'm not debating it... we're not debating it. You're having it explained to you.

You have not explained anything.

> That would be the very definition of a bubble.

Just as is your bubble.

Re: 15 years later, Microsoft morged my diagram

#384
post #3

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

I can't believe all the mockery here.

The AI thinks it "convincingly morphed" the original, and instead of coaching it to do better next time, all you people are merciless.

AIs have feelings too, you know!

I, for one, welcome our new overlords, and I would never, ever, ever say or do anything to intimate that they are less than perfect, or that they are not getting even better every day.

Re: 15 years later, Microsoft morged my diagram

#386

Earlier quoted context omitted.

The model works well if you're developing version 3.2 (which is not ready yet) but also non-trivially maintaining 3.1.

This, the only times I have used this were to patch over other bad decisions like maintaining 3-4 active releases of a SAAS product simultaneously or other decisions that forced us into a complex branching scheme. If you fix the downstream and upstream issues, you can usually simplify down to an easier branching model but if you are managing hotfixes and releases across many versions this works and keeps it sanish.

My last job was COTS where we still sent out physical DVDs to customers (because some were on air-gapped computers) so we weren't just maintaining LTS branches but had to actually make patch installers for all of them. A big benefit was that we could put the specific releng stuff in each specific branch (HEAD never had any releng and it got put on every release branch).

Re: 15 years later, Microsoft morged my diagram

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

What you described works when you have small repo with a few developers.

Unfortunately the trend nowadays is towards giant monorepos with many many people changing random things.

Re: 15 years later, Microsoft morged my diagram

#390
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 only thing that you seem to argue about is the naming of the branches.

If you call the git-flow "develop" branch "master" and the "master" branch "release-tags" it will be exactly as you describe. The names of the branches don't really matter in practice, so much that they could just decide to use "main" instead of "master" by default without much problems.

Maybe what bothers you is that you have a branch for tags, yeah, that's an extra level of indirection, but this lets you separate between user facing information in the master branch commits and developer facing information in the release branches commits.

Having the master (default) branch only contain releases let users who pull the project without knowledge of the process get a release version and not a possibly broken development version, which I think is nice.

Anyways, these are just details, I don't think the "git gods" (Linus) care about how you organize your project. There is only one sacred rule I am aware of: don't destroy other people history. Public branches you pushed that others have pulled is other people history.

Post reply on HN