Dessalines@lemmy.ml to General Programming Discussion@lemmy.ml · 1 month agoWorktrees: Git's best kept secret (and why you should use them) | Tom Upswww.tomups.comexternal-linkmessage-square20linkfedilinkarrow-up125arrow-down11
arrow-up124arrow-down1external-linkWorktrees: Git's best kept secret (and why you should use them) | Tom Upswww.tomups.comDessalines@lemmy.ml to General Programming Discussion@lemmy.ml · 1 month agomessage-square20linkfedilink
minus-squareSpaceNoodle@lemmy.worldlinkfedilinkarrow-up5·1 month agoWhat benefits does this provide over a cloned copy of the repository?
minus-squareatzanteol@sh.itjust.workslinkfedilinkEnglisharrow-up4·1 month agoIt’s more space efficient - you don’t get another full copy of the repo. The worktree points back to the same .git directory. And since it’s in the same repo you can diff between branches with other worktrees without needing to setup remotes for each of them.
minus-squareSpaceNoodle@lemmy.worldlinkfedilinkarrow-up1·1 month agoYou can already diff between branches in a single worktree.
minus-squareatzanteol@sh.itjust.workslinkfedilinkEnglisharrow-up2arrow-down1·1 month agoYes, that’s what I said.
minus-squareSpaceNoodle@lemmy.worldlinkfedilinkarrow-up1·edit-21 month agoThen why mention setting up remotes?
minus-squareatzanteol@sh.itjust.workslinkfedilinkEnglisharrow-up3arrow-down1·1 month agoThe question I was answering was about worktrees vs. multiple clones. With multiple clones you need to setup remotes to share branches between directories. With worktrees sharing a working copy you don’t.
minus-squareDessalines@lemmy.mlOPlinkfedilinkarrow-up3·1 month agoNo need for another full git history copy, nor submodules and settings.
minus-squareeldavi@lemmy.mllinkfedilinkEnglisharrow-up2arrow-down1·1 month agoevery time i do this, i have to annotate the old copy somehow. i usually use a date and months later i have no clue why i made the copy.
minus-squareSpaceNoodle@lemmy.worldlinkfedilinkarrow-up3·1 month agoYes, you should name directories descriptively. I don’t think that’s unique to repository clones.
minus-squareeldavi@lemmy.mllinkfedilinkEnglisharrow-up2arrow-down1·1 month agodefinately not since that’s the way i learned. the problem is that a directory named master-hotfix-vgpool01-05022022 is very difficult to remember why it was created if you looked at it today.
minus-squareSpaceNoodle@lemmy.worldlinkfedilinkarrow-up2·1 month agoThen clearly it was poorly named.
minus-squareeldavi@lemmy.mllinkfedilinkEnglisharrow-up1arrow-down1·1 month agoso what would you name it?
minus-squareSpaceNoodle@lemmy.worldlinkfedilinkarrow-up1arrow-down2·1 month agoSomething that clearly communicates its purpose.
What benefits does this provide over a cloned copy of the repository?
It’s more space efficient - you don’t get another full copy of the repo. The worktree points back to the same .git directory.
And since it’s in the same repo you can diff between branches with other worktrees without needing to setup remotes for each of them.
You can already diff between branches in a single worktree.
Yes, that’s what I said.
Then why mention setting up remotes?
The question I was answering was about worktrees vs. multiple clones. With multiple clones you need to setup remotes to share branches between directories. With worktrees sharing a working copy you don’t.
No need for another full git history copy, nor submodules and settings.
every time i do this, i have to annotate the old copy somehow.
i usually use a date and months later i have no clue why i made the copy.
Yes, you should name directories descriptively. I don’t think that’s unique to repository clones.
definately not since that’s the way i learned.
the problem is that a directory named master-hotfix-vgpool01-05022022 is very difficult to remember why it was created if you looked at it today.
Then clearly it was poorly named.
so what would you name it?
Something that clearly communicates its purpose.