I love git worktrees. It took me a while to change my workflow and get used to doing things differently, but it is so much better. I never have to think “oh my repo is in inconsistent state, I can’t switch my focus and start reviewing this PR, I need to first stash/commit/stage/etc. my stuff…”

I also love how Magit lets me create a worktree from a PR or an Issue (some of that is built-in, some I extended to fit my workflow). One thing is still missing though.

Cloning or starting a new repo in a practical way to be used with worktrees, for me, always requires some manual process.

First, I need to follow the recommendation I borrowed from this blogpost: How to use git worktree and in a clean way. It boils down to:

mkdir my-awesome-project
$ cd my-awesome-project
$ git clone --bare git@github.com:myname:my-awesome-project.git .bare
$ echo "gitdir: ./.bare" > .git

But when I do that, git doesn’t see remote branches anymore. So some stuff won’t work as normally expected. For that, I have to follow this advice from SO, basically adding to ./bare/config:

[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*

And now I’m thinking, before I try to automate this. Maybe Magit already does the right thing and I just never knew about it? Or maybe it’s much simpler than that and all that manual hocus-pocus is not needed?

How do you use worktrees with Magit? And if you don’t use worktreees, why is that? Is there even a better way?

  • github-alphapapa@alien.topBEnglish
    1·
    1 year ago

    I don’t use worktrees very often, but when I do, I just use them simply: I make a worktrees subdirectory in the repo root, then use Magit to check out worktrees into subdirectories of that.

  • noooit@alien.topBEnglish
    1·
    1 year ago

    I stopped using worktree completely. It’s basically fancy git clone and it’ll leave unnecessary path histories and I have to index the project from scratch as well.

    I think git checkout is enough unless you work in a repo where git checkout causes huge recompilation. It’s also a good moment to make a commit to the working branch for reflog when I checkout some PR.
    I never use stash either unless i intend to pop the stash within a minute.

    • ilemming@alien.topOPBEnglish
      1·
      1 year ago

      Worktrees is a tool. Tools don’t provide answers or teach you how to live your life. If a tool doesn’t work for you, that’s fine.

      I don’t use worktrees in every project. However, for the main project where I’m collaborating with numerous other people and constantly having to shift focus from one problem to another, worktrees are indispensable. When my teammate asks me a question about one of the three PRs I or someone else has made, I need to quickly inspect the code in my REPL. With worktrees, I can have multiple REPLs running, each connected to a separate worktree. I can run tests in one, while inspecting some code in another. I can even jump from one to another without having to save files.

      Also, excuse my pedantics, but worktrees technically aren’t just fancy git clones. Git worktrees don’t recreate the entire clone for each branch, thus they are faster.

      • paretoOptimalDev@alien.topBEnglish
        1·
        1 year ago

        With worktrees, I can have multiple REPLs running, each connected to a separate worktree.

        I’ve been wanting this workflow of never having to wait as well.

        Deep seamless integration of work trees with project.el, history, etc would be valuable.

      • noooit@alien.topBEnglish
        1·
        1 year ago

        Worktrees is a tool. .

        It’s a git command option actually.

        excuse my pedantics.

        No i won’t. It’s a fancy git clone by not fully cloning the repo from the existing clone. It’s just space efficient with some extra command options.

    • paretoOptimalDev@alien.topBEnglish
      1·
      1 year ago

      I think git checkout is enough unless you work in a repo where git checkout causes huge recompilation.

      I’d wager this is a very common case.