Submodules work fine but yeah, it's frustrating that lfs is taking so long. But there seems to be some momentum recently https://github.com/jj-vcs/jj/pull/9068

The git compatibility page states that submodules are not supported

https://docs.jj-vcs.dev/latest/git-compatibility/

What "not supported" means with submodules specifically is that jj doesn't have commands to manage them. You can use git commands to manage them, and it does, in my understanding, work. There's just no native support yet.

This is sort of similar to how you can create lightweight tags with jj tag, but you need to push them with git push --tags.

> and it does, in my understanding, work.

I use submodules with jj, and jj saves and restores submodule hashes perfectly. What it doesn't do is manipulate the sub-repository from its parent. You can do that yourself using jj or git of course, which is what I ended up doing using a few scripts. The result ended up being more reliable than using git's submodule commands directly.

They can take all the time in the world to implement submodules as far as I'm concerned. jj's implementation of workspaces removes all of the hairs of git's worktrees. git submodule implementation has even more hairs than worktrees. If the jj developers need time to do as good a job on submodules as they did with workspaces, then I say give it to them.

Gotcha, thank you for the context.

I use vimium in Firefox and so my default key bindings are the plug-in ones. I push 't' to create a new tab, for instance. If I want to use the website key bindings I have to to into "insert mode" ('i'), or I opt into specific keys by site.

I do like when websites use ctrl-k -- it means nothing to my plug-in so websites always get it, plus it helps with key binding discovery.

Share your private thoughts and gratitude with your private group, plus the good people at grateful.so, their partners, their service providers, the processor of os notifications, anyone who buys the assets of grateful.so once it goes under, plus any script kiddie who cares to point an LLM at the vibe coded server base...

Damn I'm jaded by our industry...

Yes absolutely this. I've put so much effort into making sure I tick all the boxes and yet I constantly wonder if my email is getting delivered. This feels anti competitive to me. It's Google constantly telling me, give up, you know deep down you should just use Gmail.

I think Gmail doesn’t want you to use their service for sending email; they want you to have to advertise ‘with’ them.

we switched email providers from our all-EU stack to gmail... just as a last desperate attempt at not being marked as spam for actually sending low volume (crazy, right).

well, now we're stuck with gmail for a year, and no, it haven't improved anything!

Oh I made one of these once! In mine you play against other people. https://1dchess.igor47.com/

Oh cool I used to use https://web.hypothes.is/ for this but they never had a good Firefox extension so I stopped. How do you annotate with friends using Margin? Does everyone need to be on the same at proto server?

All the examples are fetching data from a server, and in such cases I think tanstack query already does all the hard part. I feel like people under-use react query and put too much state in their FE. This might be relevant if your app has some really complicated interactions, but for most apps they should really be a function of server, not client, state. Of course this exact reasoning is why I moved off react altogether and now use htmx in most of my projects

It's not just react query, you can make a quick useFetch and useMutation hooks (or claude can), it's not that complex. If you don't need more advanced features (eg caching), you can easily cut down on 3rd party dependencies.

    import { useState, useEffect } from "react";

    function useFetch(url) {
      const [data, setData] = useState(null);
      const [loading, setLoading] = useState(true);
      const [error, setError] = useState(null);

      useEffect(() => {
        const controller = new AbortController();

        fetch(url, { signal: controller.signal })
          .then((res) => res.json())
          .then((json) => {
            console.log("Data:", json);
            setData(json);
          })
          .catch((err) => {
            if (err.name !== "AbortError") {
              console.error("Fetch error:", err);
              setError(err);
            }
          })
          .finally(() => setLoading(false));

        return () => controller.abort();
      }, [url]);

      return { data, loading, error };
    }







    function App() {
      const { data, loading, error } = useFetch("https://jsonplaceholder.typicode.com/todos/1");

      if (loading) return <p>Loading...</p>;
      if (error) return <p>Error</p>;
      return <pre>{JSON.stringify(data, null, 2)}</pre>;
    }

Yeah, fetching data from a server in useEffect is a widely acknowledged and documented antipattern.

It's a widely documented anti-pattern, while also not giving a convenient alternative.

Is it? I have never had any issues doing it this way.

This post explains it pretty well: https://dev.to/deveshsangwan/stop-using-useeffect-for-data-f...

I am not convinced. Have been using this pattern for years without issue.

You can lead a horse to water...

I have been drinking water for years. You are trying to tell me water is an antipattern and I should drink gatorade instead. No thanks.

I've been waiting for people to have common sense in this domain for decades. The short term always wins

But that's what has changed. Even short term solar is becoming the obvious solution. Look at countries like Pakistan and their solar hyper growth.

Everybody thought it has to be western countries (mostly europe) switching to solar first. But west might actually be last to get off fossil because they can afford it and populist politics will force fossil. It's like burning fossil for nostalgia.

Ya, look at what happened in Nepal, poor access to oil via India, who imports it themselves, but lots of hydro potential. China being next door with an actual rail and truck connection, and cheap EVs.

The developing world has the potential to achieve developed living standards for a much cheaper price, while the west rots away catering to vested interests.

Well, reading the study, I'm not sure more patients could rescue it from methodological bias. They assumed the premise basically -- we should find a biomarker, which is kind of what this thread is discussing. Then they went trawling for biomarker in a sea of millions of biomarkers. They did this by training an model that produced the desired result, using a grid search for hyper parameters that even further expanded the available degrees of freedom here beyond what they had from the biology. No pre-registration; There are millions of places where the researchers could have made a different decision -- would they still have gotten a publishable result? Oh plus the authors mostly work for the company whose data they use, which is hoping to sell a diagnostic test.

I'm giving you a thorough response because I'm detecting a cavalier anti scientism which I think is sadly becoming more common. This stuff is hard; are you sure you understand it enough to have an informed opinion?

I cannot endorse mise more highly. I commit it to my repos to make sure every engineer has the same environment. I use it in CI for consistency there as well. I keep all commands that would normally be documented in a readme as mise tasks. I use mise to load the environment, independent of language specific tools like dotenv. I use a gitignored mise.local to put real creds into the environment for testing.