71–80 of 233 posts
Earlier quoted context omitted.
What is the advantage of using worktrees over another checkout in another folder?
Duplicate storage as already mentioned, but you will also lose the ability to merge / doff cross branches if you have separate checkouts.
Earlier quoted context omitted.
Duplicate storage as already mentioned, but you will also lose the ability to merge / doff cross branches if you have separate checkouts.
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.
Earlier quoted context omitted.
Duplicate storage as already mentioned, but you will also lose the ability to merge / doff cross branches if you have separate checkouts.
Why would you lose that ability? You can just pull from the other checkout as an upstream, right?
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.
Earlier quoted context omitted.
I remember that well too (along with Rational Clearcase), and you may totally be right, but git does feel different because it works so well with all sorts of projects, big and small. There were always operations that required hacks. With git that doesn't feel the case to me,perhaps with one exception (but I don't think this is git's fault as much as it's mine for not knowing git well enough to use the tools it provi…
I totally agree. Back when I used Subversion it felt to me like there obviously must be a better way to version control and that the tool got in my way all the time. Git on the other hand almost always can solve my problems and while some things could be improved (confusing UX, a bit too complex, plus bad handling of conflicts) it is much closer to the right tool for VCS than Subversion ever was.
Earlier quoted context omitted.
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.
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.
“Powerful” has become to me a shibboleth for people who are full of it. I can’t recall the last time a coworker who liked things because they were powerful didn’t end up being untrustworthy. Even dangerous. It’s like nobody remembers the Principle of Least Power. That said, I will take someone obsessed with “powerful” over “flexible” any day of the week.
Hm, I guess for tools like this I always read "powerful" as "flexible" - as in: this tools has strictly more power/capabilities making it more flexible. In terms of "dev tool marketing speak" I guess it's the opposite of "robust" meaning: fewer features that are less likely to break on you.
The Leatherman is part of my EDC, along with an LED flashlight with some respectable lumens so I don't have to use my phone to see in the dark.
In software this is known as the Unix Philosophy, but we violate it quite often, and call those tools 'powerful' or 'flexible'. Everything is a Swiss Army Knife all the time, and we aren't self-aware enough to see how consistently - and sometimes badly - we struggle with this.
But you can't tell an addict they're an addict. They will fight you to the death about how they Don't Have a Problem.
Earlier quoted context omitted.
If you can rewrite the history that actually got committed, do you really need a temporary pre-commit staging area?
The index is mostly useful to me to split a commit in multiple ones. You do that with a sequence of "git add -p" and "git commit" commands. I am interested in how to do this with jj, because otherwise it looks like a very interesting tool.
> It combines features from Git (data model, speed), Mercurial (anonymous branching, simple CLI free from "the index", revsets, powerful history-rewriting), and Pijul/Darcs (first-class conflicts), with features not found in either of them (working-copy-as-a-commit, undo functionality, automatic rebase, safe replication via rsync, Dropbox, or distributed file system). You lost me at "free from the index". The index i…
> You lost me at "free from the index". If you click the link that text points you to (i.e. https://github.com/martinvonz/jj/blob/main/docs/git-comparis... ), there's an explanation there for how to achieve the same workflows. I get that it's different , but I don't think it's worse. I consider myself a (former) git power user (I think I have ~90 patches in Git itself) and I've never missed the index since I switched…
Also, I often rebase and `edit` commits to split them or undo parts of them.
Rebase and all this is all about making commits that have just the right content, and keeping history clean and linear. The tools have to make this possible and easy.
I get that git feels... barebones for this. You really have to understand what you're doing when using git like I do, so I get that it's not very accessible.
Better UIs are great, but on the other hand, we need to be able to get down to the low level.
IMO.
Earlier quoted context omitted.
Duplicate storage as already mentioned, but you will also lose the ability to merge / doff cross branches if you have separate checkouts.
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.
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.