181–190 of 233 posts
Earlier quoted context omitted.
Seems irrelevant to me. Why do you care about the language choice?
People do tend to see tools written in a systems language in another light than tools written in a glue language. Did you read it as "rust (not C)" or did you read it as "rust (not Python)"?
Interesting ideas! I especially like the automatic rebasing and associated ideas. It's a bit strange to see "jj st" will automatically add all files to the "working copy" commit. This means that when I initially create my project, run "npm install" to install 500 MB of dependencies, and then run "jj st" to figure out what to include in my first commit, the command is going to copy all of that into a commit object for…
Perhaps that's a good time to use the undo operation.
Earlier quoted context omitted.
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…
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 det…
I did not say that was the only sane way to use worktrees. I frequently use them for separate strands of ongoing work (on separate branches per work strand, named appropriately). Less common (for me) is the use case of easy reference to older versions, with more ephemeral worktrees checking out a tag, a new branch (created for the purpose, and short-lived), or a particular commit (viewed as a detached HEAD).
This is the biggest thing keeping me using mercurial, the fact that it has subrepos that work.
I can't find it mentioned anywhere, but does jj support submodules? And does it make them actually work, unlike the broken mess git has? This is the biggest thing keeping me using mercurial, the fact that it has subrepos that work.
Earlier quoted context omitted.
> just commit everything in their working directory But that's what they've tested. I've had far more problems in the other direction, where the commit doesn't contain the complete set of things that it's supposed to but because all the tooling - every single IDE and compiler - is looking at the working directory not the index, I've missed something. The index is definitely confusing for new users and users of other…
Like I said, I’m not sold on git’s specific implementation. But breaking things into smaller, focused commits is—in my experience—a hallmark of good development practice. There should absolutely be better tooling around it, so that these piecemeal commits can be tested in isolation from one another. That’s a far better approach than just throwing up our hands and committing everything in the working tree, even if hal…
Earlier quoted context omitted.
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…
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 det…
The way I use worktrees I'd say the majority are read-only anyhow, so abiding by restrictions because it might get confusing if a commit were made is pretty annoying.
Earlier quoted context omitted.
Try using git worktrees: https://geekmonkey.org/rethink-your-git-workflow-with-git-wo...
Surprise limitation: you cannot have two worktrees set to the same branch, or at least that confronted me when I tried it.
Earlier quoted context omitted.
It puts those deps in your source tree, sure, but no one advocates committing them to your repository except in few specific scenarios. This kind of thing is also pretty much standard for most programming languages today.
Isn’t parent explicitly trying to avoid committing the node_modules?
Earlier quoted context omitted.
This is the default behavior of npm. The most popular package manager on the planet. It might not be technically the most superior way to do things, but given the widespread use, tooling around it need to be compatible.
It puts those deps in your source tree, sure, but no one advocates committing them to your repository except in few specific scenarios. This kind of thing is also pretty much standard for most programming languages today.
No, it is not. Have a look at java, golang or rust. None of those languages advocate for embedding deps in your source tree as it's quite clearly a terrible anti-pattern to follow.
I wouldn't consider how JavaScript does stuff a good example.