391–400 of 427 posts
Earlier quoted context omitted.
> 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?
No. I'd expect that "continvouclous morging" gets caught.
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…
They've taken it down now and replaced with an arguably even less helpful diagram, but the original is archived: https://archive.is/twft6
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…
Earlier quoted context omitted.
How you commit plagiarism is less important than the fact that you commit plagiarism.
What difference does that make in solving the actual problem? The real story here is not "some lousy Microsoft employee ripped off this guy's graphic", but "people using AI image generators may receive near-copies of existing media instead of new content, with no indication that this has happened". If this has been discovered once, it must be happening every day. What can we do about that? Perhaps image generators ne…
This has been known for a long time. The main question is how rare something is in the input data, if you're lucky you get substantial chunks of the original input back out.
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 tag…
That's such a marginal niche use case to build your entire organization around… why would you make this the default approach?
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…
These all have separate QA, integration, and release timelines that can -- and often do -- change during the process. As a result, what goes into any given release is sometimes being changed almost right up until we hit the button. Having the ability to roll a release branch from different feature branches and not get miscellaneous work from things that aren't ready is important.
Now, this could also be done with clever use of feature flags, but the platform doesn't play nicely with that concept. Plus, then there would be the work of going back and removing them or leaving in place a mess of conditional statements littered around.
Doing it in version control is architecturally simpler, integrates better with our task and version management tools and is easier to standardize on. There is a cost in how to handle merge conflicts, but that is manageable and can be offset by good task planning and careful work. And the occasional reset
"continvoucly morged" is such a perfect phrase to describe what happened, it's poetic
https://github.com/MicrosoftDocs/learn/commit/e0af64352c7fdb...