this post was submitted on 24 Oct 2023
0 points (50.0% liked)

Emacs

311 readers
3 users here now

A community for the timeless and infinitely powerful editor. Want to see what Emacs is capable of?!

Get Emacs

Rules

  1. Posts should be emacs related
  2. Be kind please
  3. Yes, we already know: Google results for "emacs" and "vi" link to each other. We good.

Emacs Resources

Emacs Tutorials

Useful Emacs configuration files and distributions

Quick pain-saver tip

founded 1 year ago
MODERATORS
[email protected]
[email protected]
0
Magit: cloning for worktrees (alien.top)
submitted 1 year ago by [email protected] to c/[email protected]
7 comments fedilink hide all child comments
 

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 [email protected]: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?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 1 year ago (2 children)

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.

[–] [email protected] 1 points 1 year ago (2 children)

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.

[–] [email protected] 1 points 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.

[–] [email protected] 1 points 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.

[–] [email protected] 1 points 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.