9 ms·

Try using git worktrees: https://geekmonkey.org/rethink-your-git-workflow-with-git-worktree/ https://geekmonkey.org/rethink-your-git-workflow-with-git-wo...

CorrectHorseBat 5y ago
What is the advantage of using worktrees over another checkout in another folder?
- 0xdky 5y ago
  You will need a full repository in other directory to checkout and this will waste storage unless you share objects via alternate.
- ossusermivami 5y ago
  Optimizations and management really
- halfdan 5y ago
  Duplicate storage as already mentioned, but you will also lose the ability to merge / doff cross branches if you have separate checkouts.
  - cortesoft 5y ago
    Why would you lose that ability? You can just pull from the other checkout as an upstream, right?
    - jonathanlydall 5y ago
      Worktree allows you to checkout other branches, stashes or commits which are local only / not yet pushed. What’s also great is that you don’t need to do a pull in the other folder. Before I discovered worktree, I had my repository checked out in two places, so was either pulling both constantly, or when I needed the alternate, it was often very far behind and I had to pull a lot.
  - CorrectHorseBat 5y ago
    Hmm, I tried it once and iirc I couldn't see commits/branches of the other workspace without pushing and fetching so I really didn't see any difference. With different checkouts you can also easily do that by adding the other checkout as a remote.
    - dataflow 5y ago
      Something probably got messed up on your setup (or maybe you checked out a commit instead of a branch?) because you definitely can see all worktrees' branches from inside each other when using git worktree.
      - CorrectHorseBat 5y ago
        That makes sense. Now I think about it, The issue probably was that I was working in a submodule and those branches are probably not shared.
        jonathanlydall 5y ago
        Yes, as per my other comment, I’ve noticed with submodules that the references are isolated between the different folders, but they do share the same objects in the .git folder, so you still get efficiency there in not needing to store or pull duplicate data.
    - jonathanlydall 5y ago
      Not sure what you were doing wrong, but I use worktree regularly and you can absolutely see the same commits from both the primary and worktree side. The great thing about worktrees is that everything local is still available in the worktree and vice-versa, you can even stash push on the one side and pop on the other. You also don’t need to push or pull on either side first. I have noticed that for submodules, although they share the .git folder, they don’t share references, so you can’t see local branches and stashes between the worktrees, but sub module pulls are still quicker since they share objects so those don’t need re-pulled on the other folder.
- jomar 5y ago
  When you're done with a worktree, you just delete it (via `git worktree remove`). Any additional branches or stashes etc are part of the repository that the worktree was part of, and they (of course) remain. When you're done working in a separately cloned repository in another folder, if you're anything like me, before deleting it (via `rm -rf`) you'll want to check very carefully for additional branches, unpushed work, anything stashed. Deleting an entire repository that's been around for a while is a risky operation in that it may have accumulated other unrelated work in addition to the current branch (which was the primary reason for the clone), and you'll want to check carefully before deleting the whole lot. Additional worktrees within the same repository are great for medium-term ephemeral separate strands of work. They can be created and removed without concern.
pjc50 5y ago
Surprise limitation: you cannot have two worktrees set to the same branch, or at least that confronted me when I tried it.
- halfdan 5y ago
  That's not correct. You can use --force to to create a duplicate worktree pointing to the same commit-ish: https://git-scm.com/docs/git-worktree#Documentation/git-worktree.txt-addltpathgtltcommit-ishgt https://git-scm.com/docs/git-worktree#Documentation/git-work...
- hpfr 5y ago
  Can you elaborate on why you would want two worktrees set to the same branch? I think if I were trying to compare two approaches involving incompatible changes, creating a branch for one approach would feel more natural anyway, and then I'd be able to use the worktrees.
- jomar 5y ago
  If you had two worktrees set to the same branch and made a new commit in one of them (thus changing the commit the branch ref points to), what would happen in the other worktree? Either it wouldn't have the right commit checked out anymore, or git would have to miraculously change what files are checked out in it -- which would likely come as a big surprise to whatever you were doing in that working tree. Ergo, it is forbidden. I periodically find myself creating a new (temporary) branch referring to the same commit when I want a new worktree looking at the same place, or just create a new worktree with a detached HEAD looking at the same commit.
  - Too 5y ago
    Git could hide this for you and just make it look like you cloned the repo twice. What happens if you make a commit in dir1 and dir2 is on the same branch. Absolutely nothing, until you fetch, and worktrees could work the same way. If there is any ambiguity left you could prefix the branch names similar to the remotes origin/master, worktree2/master. The only sane way to use worktrees today is, like you say, with detached heads. Which well…isn’t that sane for many other reasons.
BiteCode_dev 5y ago
How do you use worktrees with an IDE ? Do you have one project per tree ?

CorrectHorseBat 5y ago

What is the advantage of using worktrees over another checkout in another folder?

0xdky 5y ago
You will need a full repository in other directory to checkout and this will waste storage unless you share objects via alternate.
ossusermivami 5y ago
Optimizations and management really
halfdan 5y ago
Duplicate storage as already mentioned, but you will also lose the ability to merge / doff cross branches if you have separate checkouts.
- cortesoft 5y ago
  Why would you lose that ability? You can just pull from the other checkout as an upstream, right?
  - jonathanlydall 5y ago
    Worktree allows you to checkout other branches, stashes or commits which are local only / not yet pushed. What’s also great is that you don’t need to do a pull in the other folder. Before I discovered worktree, I had my repository checked out in two places, so was either pulling both constantly, or when I needed the alternate, it was often very far behind and I had to pull a lot.
- CorrectHorseBat 5y ago
  Hmm, I tried it once and iirc I couldn't see commits/branches of the other workspace without pushing and fetching so I really didn't see any difference. With different checkouts you can also easily do that by adding the other checkout as a remote.
  - dataflow 5y ago
    Something probably got messed up on your setup (or maybe you checked out a commit instead of a branch?) because you definitely can see all worktrees' branches from inside each other when using git worktree.
    - CorrectHorseBat 5y ago
      That makes sense. Now I think about it, The issue probably was that I was working in a submodule and those branches are probably not shared.
      - jonathanlydall 5y ago
        Yes, as per my other comment, I’ve noticed with submodules that the references are isolated between the different folders, but they do share the same objects in the .git folder, so you still get efficiency there in not needing to store or pull duplicate data.
  - jonathanlydall 5y ago
    Not sure what you were doing wrong, but I use worktree regularly and you can absolutely see the same commits from both the primary and worktree side. The great thing about worktrees is that everything local is still available in the worktree and vice-versa, you can even stash push on the one side and pop on the other. You also don’t need to push or pull on either side first. I have noticed that for submodules, although they share the .git folder, they don’t share references, so you can’t see local branches and stashes between the worktrees, but sub module pulls are still quicker since they share objects so those don’t need re-pulled on the other folder.
jomar 5y ago
When you're done with a worktree, you just delete it (via `git worktree remove`). Any additional branches or stashes etc are part of the repository that the worktree was part of, and they (of course) remain. When you're done working in a separately cloned repository in another folder, if you're anything like me, before deleting it (via `rm -rf`) you'll want to check very carefully for additional branches, unpushed work, anything stashed. Deleting an entire repository that's been around for a while is a risky operation in that it may have accumulated other unrelated work in addition to the current branch (which was the primary reason for the clone), and you'll want to check carefully before deleting the whole lot. Additional worktrees within the same repository are great for medium-term ephemeral separate strands of work. They can be created and removed without concern.

pjc50 5y ago

Surprise limitation: you cannot have two worktrees set to the same branch, or at least that confronted me when I tried it.

halfdan 5y ago
That's not correct. You can use --force to to create a duplicate worktree pointing to the same commit-ish: https://git-scm.com/docs/git-worktree#Documentation/git-worktree.txt-addltpathgtltcommit-ishgt https://git-scm.com/docs/git-worktree#Documentation/git-work...
hpfr 5y ago
Can you elaborate on why you would want two worktrees set to the same branch? I think if I were trying to compare two approaches involving incompatible changes, creating a branch for one approach would feel more natural anyway, and then I'd be able to use the worktrees.
jomar 5y ago
If you had two worktrees set to the same branch and made a new commit in one of them (thus changing the commit the branch ref points to), what would happen in the other worktree? Either it wouldn't have the right commit checked out anymore, or git would have to miraculously change what files are checked out in it -- which would likely come as a big surprise to whatever you were doing in that working tree. Ergo, it is forbidden. I periodically find myself creating a new (temporary) branch referring to the same commit when I want a new worktree looking at the same place, or just create a new worktree with a detached HEAD looking at the same commit.
- Too 5y ago
  Git could hide this for you and just make it look like you cloned the repo twice. What happens if you make a commit in dir1 and dir2 is on the same branch. Absolutely nothing, until you fetch, and worktrees could work the same way. If there is any ambiguity left you could prefix the branch names similar to the remotes origin/master, worktree2/master. The only sane way to use worktrees today is, like you say, with detached heads. Which well…isn’t that sane for many other reasons.

BiteCode_dev 5y ago

How do you use worktrees with an IDE ? Do you have one project per tree ?