61–66 of 66 posts
A question: I prefer jumping into the command line for most of my git work. But, I'm intrigued by this discussion and wonder: how well do these tools work within an editor? I am using Zed, which IMHO has poor git support anyway. I'm curious if the experiences here are mostly from people who do not use their editor as their main point of contact with the code repository they are working on.
Earlier quoted context omitted.
What do you mean both versions? They are all different versions. You have N versions between your endpoints, and you test log(N) of them. You don't test any single version more than one time.
For certain applications and bugs it may be helpful to see a version of the application with the bug running side by side with a version without the bug. By "both versions" I meant the versions checked out in both workspaces. See: https://martinvonz.github.io/jj/latest/working-copy/#workspa...
FYI git has "worktrees": https://git-scm.com/docs/git-worktree
At work I’ve been using jj for the internal Standard Chartered monorepo (6.5 MLOC). I didn’t ask anyone, just installed and started using it. Git compatibility is a killer feature. (if anyone from SC is reading this -- search our wiki for "Jujutsu" and come say hi!) Pretty much a strictly better experience than git so far — I’m not going back. `jj undo` is something that I expect in every program now and get vaguely…
I did some profiling & it looks like the issue lies with `libgit2`, but I haven’t been able to replicate the issue outside of that work codebase[0].
[0]: https://github.com/martinvonz/jj/issues/1841#issuecomment-23...
Earlier quoted context omitted.
For certain applications and bugs it may be helpful to see a version of the application with the bug running side by side with a version without the bug. By "both versions" I meant the versions checked out in both workspaces. See: https://martinvonz.github.io/jj/latest/working-copy/#workspa...
But you don't know in advance whether a given version has the bug, that's kind of the reason for bisecting. Or do you mean you have 3 versions side-by-side: the last-known-bad, last-known-good, next-unknown-to-test? FYI git has "worktrees": https://git-scm.com/docs/git-worktree
At work I’ve been using jj for the internal Standard Chartered monorepo (6.5 MLOC). I didn’t ask anyone, just installed and started using it. Git compatibility is a killer feature. (if anyone from SC is reading this -- search our wiki for "Jujutsu" and come say hi!) Pretty much a strictly better experience than git so far — I’m not going back. `jj undo` is something that I expect in every program now and get vaguely…
have you experienced particularly slow pushes with large repositories at all, and if so were you able to resolve them? I did some profiling & it looks like the issue lies with `libgit2`, but I haven’t been able to replicate the issue outside of that work codebase[0]. [0]: https://github.com/martinvonz/jj/issues/1841#issuecomment-23...
Earlier quoted context omitted.
> You don't need to manage the stash or index, those are just expressed as commits, You can also avoid managing the stash in Git. By not using it.
But you still need to deal with a dirty working copy somehow. This blog post from today happens to describe one scenario where it's nice not to have to worry about changes in the working copy: https://drewdevault.com/2024/12/10/2024-12-10-Daily-driving-...