> the strong aversion people have for things not being "proven" by western science
What does “western” have to do with anything? There is plenty of pseudoscience, snake oil and magical thinking in the west. I’d wish people were much more skeptical of anything not scientifically proven.
Or do you imply there is a racist component to it? That could certainly be true.
> There is plenty of pseudoscience, snake oil and magical thinking in the west
This is it exaclty. These folks always forget that it's not the only idea we've heard today. It's basic cost/benefit. This takes 45 minutes to an hour to try out. If it works you "feel better" where "better" is hard to define. Cost = 45 minutes. Benefit = Meh.
Since there are about 1 billion things in the world that claim to make me "feel better" at a cost of 45 minutes each I have to really narrow my focus. I can't spend 45 billion minutes for "Meh."
In my case this made enough sense that I tried it when I was young and liked it. A lot of folks spent those 45 minutes on something else that seemed more likely to succeed. It's perfectly rational.
Things that don’t get concrete results for people tend not to survive 2000+ years, like meditation, taichi/qigong/whatever; so i don’t think some things really need scientific proof. Even then, how do you scientifically prove if something makes you feel better who really cares if it’s x or y receptor or brainwave pattern or whatever?
This is simply an "Appeal to Tradition" fallacy. People do lots of things for thousands of years that are worthless, wrong, or pointless. However, this also doesn't mean that just because we've done these things for a long time that they are in fact pointless.
There are methods to prove subjective things like "feeling better." There is in fact a lot of research that shows that meditation and exercise like Taichi is good for you.
It gives people some comfort and motivation, same as religions do. I’m not saying everything that lasted so long has scientifically verifiable benefits, but they clear have some societal or mental benefits otherwise people wouldn’t do em
Ok, then let's put it all together and say that people are interested in whether or not yoga has concrete benefits above and beyond comfort and motivation, which, while obviously valuable, are not the stated benefits.
Survival of the fittest is "that which reproduces more successfully, continues". In biology, this is genetics. In ideas, it's memetics. I suppose this means that our most powerful ideas from the internet generation are Rickroll, Doge, and Grumpy Cat.
One could claim it is a self reflection tool where the point is not the claims at face value, but the value lies in the activity itself of focusing, of directing your mind to look at and feel your existence from a different/wide perspective. Which is true about many pedagogical tools.
The concrete results would thus be highly specific to the subject and their learning process on what they themselves deem relevant.
Prayer has been around a lot longer than that, and no objective blind tests have ever been able to prove any verifiable results.
Longevity of ideas is not correlated with usefulness. Our belief systems are not optimized; they are, like genetic evolution, just 'good enough' to allow survival.
There is plenty a browser could do to compete, from blocking modern popups (which now occur within the window, putting a gradient over the content forcing you to interact with their "subscribe to our mailing list" or "join our site to socialize" prompt that you would have to waste time clicking past, auto-pausing looping videos in unfocused tabs, throttling crypto mining tabs, providing uBlock Origin, handling WiFi Terms of Service click through, etc.
Think of the plethora of instances where you wish your browser made minor changes to make browsing easier
There are plenty of things to compete on: efficiency (startup time, memory use), security (from ad blocking on sites to extensions to the app itself), customization (both in looks and behavior)
And the decision to risk years of his life spent on a project that might not pan out. IIRC he was largely supported by his girlfriend during development and he worked in a cinema. That's in contrast to a job at a studio where you get a salary for your time whether it succeeds or not.
Overselling is only the tip of the iceberg. The real problem is that a lot of managers base their decision to introduce language models into business processes on cutting edge Pro edition demos, but what is, of course, actually used in production is some cheap Nano/Flash/Mini version.
I tried asking for a list of the most common gameboy color games not compatible with the original dmg gameboy. Chatgpt would over and over list dmg compatible games instead. I asked it to cross reference lists of dmg games to remove them and it ”reasoned” for a long time before it showed what sources it used for cross references, and then gave me the same list again.
It also insisted on including ”Shantae” in the list, which is expensive specifically because it is uncommon. I eventually forbid it from including the game in the list, and that actually worked, but it would continue mentioning it outside the list.
To get a commit history that makes sense. It’s not supposed to document in what order you did the work, but why and how a change was made. when I’m knee deep in some rewrite and realize I should have changed something else first, I can just go do that change, then come back and rebase.
And in the feature branches/merge requests, I don’t merge, only rebase. Rebasing should be the default workflow. Merging adds so many problems for no good reason.
There are use cases for merging, but not as the normal workflow.
That is just not true. Merging is so much less work and the branch history clearly indicates when merging has happened.
With rebasing, there could be a million times the branch was rebased and you would have no idea when and where something got broken by hasty conflict resolution.
When conflicts happen, rebasing is equivalent to merging, just at the commit level instead of at branch level, so in the worst case, developers are met with conflict after conflict, which ends up being a confusing mental burden on less experienced devs and certainly a ”trust the process” kind of workflow for experienced ones as well.
The master branch never gets merged, so it is linear. Finding a bug is very simple with bisect. All commits are atomic, so the failing commit clearly shows the bug.
If you want to keep track of what commits belongs to a certain pr, you can still have an empty merge commit at the end of the rebase. Gitlab will add that for you automatically.
The ”hasty conflict resolution ” makes a broken merge waaaay harder to fix than a broken rebase.
And rebasing makes you take care of each conflict one commit at a time, which makes it order by magnitudes easier to get them right, compared to trying to resolve them all in a single merge commit.
No. There is a conflict during a rebase, you resolve it, and then it’s like there never was a conflict.
Even if you do it properly, the workflow is erasing history of that conflict existing and needing to be resolved. It leaves no trace of what has been worked on, when, and by whom.
Meanwhile, in another branch B created off main, someone else commits changes to the same part of the same file.
That other branch B gets merged to main.
Now, rebase branch A onto main.
The rebase stops at the commit 1 due to a conflict between main and branch A.
Fix the conflict and commit. This erases commit 1 and creates new commit 1' where the conflict has never existed. History has been rewritten.
Rebase successfully completes, branch A now contains different commits than previously, so it will need to be force-pushed to remote if it already exists there. The protocol has resistance against changing history.
Merge branch A to main.
No commit in main now contains any information that there was a conflict that was fixed.
Had a pull request workflow been used, the ”merge main to A” merge commit message would detail which files were conflicting. No such commit is made when using a rebase workflow, chasing those clean fast-forward merges.
I’m sure you’re here to educate me, but this is not about criss-cross merges between two different work branches, this is about whether it’s better to rebase a work branch onto the main branch, or to pull the changes from the main branch to the work branch.
I have an early draft of a blog post about them :) as a source control expert who built both these systems and tooling on top of them for many years, I think they're the biggest and most fundamental reason rebases/linear history are better than merges.
> whether it’s better to rebase a work branch onto the main branch, or to pull the changes from the main branch to the work branch.
The problem with this is that the latter has an infinitely higher chance of resulting in criss-cross merges than the former (which is 0).
It's definitely not 0 because rebase heavy workflows involve the rerere cache which is a minefield of per-repo hidden merge changes. You get the results of "criss-cross merges" as "ghosts" you can't easily debug because there aren't good UI tools for the rerere cache. About the best you can do is declare rerere cache bankruptcy and make sure every repo clears their rerere cache.
I know that worst case isn't all that common or everyone would be scared of rebases, but I've seen it enough that I have a healthy disrespect of rebase heavy workflows and try to avoid them when given the option/in charge of choosing the tools/workflows/processes.
To be honest I've used rebase-heavy workflows for 15 years and never used rerere, so I can't comment on that (been a happy Jujutsu user for a few years — I've always wondered what the constituency for rerere is, and I'm curious if you could tell me!) I definitely agree in general that whenever you have a cache, you have to think about cache invalidation.
rerere is used automatically by git to cache certain merge conflict fixes encountered during a rebase so that you don't have to reapply them more than once rebasing the same branch later. In general, when it works, which is most of the time, it's part of what keeps rebases feeling easy and lightweight despite capturing in the final commit output sometimes a fraction of the data of a real merge commit. The rerere cache is in some respects a hidden collection of the rest of a merge commit.
In git, the merge (and merge commit) is the primitive and rebase a higher level operation on top of them with a complex but not generally well understood cache with only a few CLI commands and just about no UI support anywhere.
Like I said, because the rerere cache is so out-of-sight/out-of-mind that's why problems with it become weird and hard to debug. The situations I've seen that have been truly rebase-heavy workflows with multiple "git flow" long-running branches and even sometimes cherry picking between them. (Generally the same sorts of things that create "criss-cross merge scenarios".) Rebased commits start to bring in regressions from other branches. Rebased commits start to break builds randomly. If what is getting rebased is a long-running branch you probably don't have eyes on every commit, so finding where these hidden merge regressions happen becomes full branch bisects, you can't just focus on merge commits because you don't have them anymore, every commit is a candidate for a bad merge in a rebased branch.
Personally, I'd rather have real merge commits where you can trace both parents and the code not from either parent (conflict fixes), and you don't have to worry about ghosts of bad merges showing up in any random commit. Even the worst "criss-cross merge" commits are obvious in a commit log and I've seen have had enough data to surgically fix, often nearly as soon as they happen. rerere cache problems are things that can go unnoticed for weeks to everyone's confusion and potentially a lot of hidden harm. You can't easily see both parents of the merges involved. You might even have multiple repos with competing rerere caches alternating damage.
But also yes rerere cache problems are so generally infrequent that it might also take weeks of research, when it does happen, just to figure out what the rerere cache is for, that it might be the cause of some of your "merge ghosts" haunting your codebase, and how to clean it.
Obviously by the point where you are rebasing git flow-style long runnning branches and using frequent cherry picks you're in a rebase heavy workflow that is painful for other reasons and maybe that's an even heavier step beyond "rebase heavy" to some, but because the rerere cache is involved to some degree in every rebase once you stop trusting the rerere cache it can be hard to trust any rebase heavy workflow again. Like I said, personally I like the integration history/logs/investigatable diffs that real merge commits provide and prefer tools like `--first-parent` when I need "linear history" views/bisects.
You have to turn rerere on, though, right? I've never done that. I've also never worked with long-running branches — tend to strongly prefer integrating into main and using feature flags if necessary. Jujutsu doesn't have anything like rerere as far as I know.
Hmm, yeah looks like it is default off. Probably some git flow automation tool or other sort of bad corporate/consultant disseminated default config at a past job left the impression that it was default on. It's the solution to a lot of papercuts working with long-running branches as well as the source of new problems as stated above; problems that are visible with merge commits but hidden in rebases.
A ton of websites don’t even track users but have the cookie popup because they think that’s what you’re supposed to do.
reply