61–70 of 233 posts
" It also means that you can always check out a different commit without first explicitly committing the working copy changes (you can even check out a different commit while resolving merge conflicts)." That's really interesting. Having to manage stashes is annoying.
That's quite impressive, congratulations! The git comparison docs have: > Start working on a new change based on the branch -- jj co main Did you consider the recent git nomenclature change to use "switch" for branch operations, and "co" for file operations? I actually can't tell from so deep in my "git Stockholm syndrome" whether that distinction is really hard on new users or not, but the fact that git expended the…
Thanks! > Did you consider the recent git nomenclature change to use "switch" for branch operations, and "co" for file operations? Actually, isn't "restore" for file operations? My impression was that everyone agrees that `git checkout` does too many different things. In particular, it's both for switching branches and for restoring file content. So they added the new `git switch` and `git restore` with limited scope…
(I post this somewhat selfishly, as I'm basically describing how I wish git worked ;)
“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.
Earlier quoted context omitted.
> 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…
> With Jujutsu, you'd instead use jj split to split the working copy commit into two commits. This is more confusing? Often times when debugging/writing a fix I would have extraneous code that I wouldn't want to commit. With an index I'm always sure if what I commit, but with this workflow you have to keep track of such stuff all the time and if you forget that stuff makes it in? Not to mention that another benefit o…
i often have temporary files that i do not want to commit, nor do i want to add them to .gitignore (because i want to commit them later)
but then, i'll have to spend some time using jj split. if it is powerful enough then maybe the end result is just that those files only live in the last commit.
also, what happens on push? i'd never ever want the working copy to be pushed to the remote repo. i could not find anything in the documentation about that.
(according to the answer here: https://news.ycombinator.com/item?id=30399554 the working copy is not supposed to be pushed)
Earlier quoted context omitted.
Try using git worktrees: https://geekmonkey.org/rethink-your-git-workflow-with-git-wo...
What is the advantage of using worktrees over another checkout in another folder?
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…
What you are describing sounds as if you want worktrees: https://git-scm.com/docs/git-worktree
This looks like an interesting project, and I'm glad that people are still thinking about how to improve on version control. That said, building a version control system seems like a problem similar to a social network: the network affect causes an enormous amount of friction. i.e. most people don't want to use it until other people are using it. A vicious cycle. The fact that it's compatible with git as a backend is…
> For example, "when the working copy is automatically committed," where does it go? It becomes a regular git commit with a git ref called something like `refs/jj/keep/9f1a0fb0-a0aa-4a4b-922f-d6d48687996a` pointing to it (to prevent GC). It won't get fetched or pushed by default, except with `--mirror`, I think. > If I'm hacking on an ffmpeg script and I (temporarily) copy a 4GB mp4 file into the working directory so…
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)"?
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.