martinvonz

8 ms·

1.
by martinvonz 14d ago
If I may ask, how much time have you spent trying to learn use jj? I ask because I've seen a strong tendency for people to who have never used it to argue against it. I see much less arguments against it from people who understand both
2.
by martinvonz 14d ago
The move from martinvonz/jj to jj-vcs/jj happened almost two years ago. https://github.com/jj-vcs/jj/commit/b836e0ae9518154cd52f94e0... (from 2024-12-17) says that it was recent at that time. Google
3.
by martinvonz 5mo ago
I agree, but that doesn't seem relevant. I did not say the jj automatically resolves conflicts.
4.
by martinvonz 5mo ago
Not really very similar at all for the scenario discussed here. Rerere remembers how you have resolved a conflict before. It doesn't let you rebase a stack of commits that result in different conflicts. You will have to stop and resolv
5.
by martinvonz 9mo ago
> To me that counts as commit splitting Correct me I'm I'm wrong but I think were talking about using `git reset HEAD^` for splitting a commit. That will move the current branch backwards one step. With `--mixed`, it will also
6.
by martinvonz 9mo ago
Those were rhetorical questions. I know how to use Git. Sorry that I was unclear.
7.
by martinvonz 9mo ago
I have used both Git and jj. I find it easier in jj. `git reset` by itself doesn't split a commit AFAIK. You need to then `git add -p` and `git commit` (and recover the commit message from the old commit). And what happens if you had o
8.
by martinvonz 9mo ago
You can do that with just `jj split` too. The FAQ entry you linked to is for when you accidentally amended a commit and now you want to restore the bookmark to the old commit and move the changes you amended into a new commit on top instead
9.
by martinvonz 9mo ago
That depends on the forge and the configuration of the forge. See the parent of the comment you replied to. Not everyone uses squash merge.
10.
by martinvonz 9mo ago
Maybe you know this already but it's `jj squash --into @----` whether there are conflicts or not.
11.
by martinvonz 9mo ago
> There is probably some lingering unfamiliarity with git among jj enthusiasts as well. I've heard this a few times. But from what I've seen, it seems like often it's the Git enthusiasts who seem to be unfamiliar with jj.
12.
by martinvonz 9mo ago
Let's say you have this (modified from `git rebase --help`): ``` A---B---C main \ D---E---F feature1 \ \---G---H feature2 \ \---I---J feature3 ``` (sorry
13.
by martinvonz 9mo ago
Mostly, yes. It also covers changes to the working copy (because jj automatically snapshots changes in the working copy). It's also much easier to use, especially when many refs were updated together. But, to be fair, it's kind of
14.
by martinvonz 9mo ago
You can specify a commit, yes, but how do you remember your set of unnamed commits? Once HEAD no longer points to a commit, it will not show up in `git log`. I agree that Git could gain an operation log. I haven't thought much about it
15.
by martinvonz 9mo ago
The author of `git history` is a GitLab employee and prolific Git contributor. I think he knows how `git rebase` works.
16.
by martinvonz 10mo ago
> I don't think I would want to rewrite all branches based on rewriting one of the ancestors of those branches. This only makes sense for local branches, and I just never have such a set of branches. Yes, it's only meant for lo
17.
by martinvonz 10mo ago
This seems to be a common misconception, that many jj users don't understand Git. Most jj users I know were pretty good at Git as far as I can tell. Perhaps you'll find this recent video where Scott Chacon talks about Jujutsu inte
18.
by martinvonz 10mo ago
> I don't even want to learn another commit graph model, because git's model is very good. I agree. That's why jj uses practically the same model. That's how Git can quite easily be used as a backend. > I just look
19.
by martinvonz 10mo ago
I can pick only one? Perhaps automatic rebasing then, i.e. that all descendant commits and bookmarks (branches) are automatically updated when you rewrite a commit, e.g. by amending into it.
20.
by martinvonz 10mo ago
> but splitting is harder than selectively adding after blindly merging all changes. Is the scenario that you make many changes in the working copy and then run `git add -p` a few times until you're happy with what's staged and
21.
by martinvonz 11mo ago
Are you saying that that text implies that the you can undo the rebase with a single command or that all the reflogs get updated atomically? Or how is it related to the comment you replied to?
22.
by martinvonz 11mo ago
> Do you want to educate us of the command? Not sure that they had in mind but you can do `jj squash --from <oldest commit with unwanted file>:: --destination 'root()' <path to unwanted file>`. That will take the ch
23.
by martinvonz 11mo ago
> it always seem to amount to that people bother to read the manual and understand the tool AFTER they used a VCS for years. Perhaps, but I don't think that's true for me (or for Steve). I've contributed something like 90
24.
by martinvonz 11mo ago
The difference is that jj doesn't force you to resolve the conflict right away. I agree that you usually want to do that anyway, but it has happened to me many times that some conflict turned out to be more complicated than I had time
25.
by martinvonz 11mo ago
No, it avoids doing that (see the link someone shared above). Git actually also rarely overwrites files. The only case I'm aware of are refs, so I think it could happen that a if you modify a branch on two machines and then sync via Dr
26.
by martinvonz 11mo ago
One little benefit of the op log is that you can use a single `jj undo` to undo all the rebased branches/bookmarks in one go. If you have rebased many branches with `git rebase --update-refs`, you need to reset each of the branches sep
27.
by martinvonz 11mo ago
> I just resolve them? I think I don't understand this question. In order to make changes to commit A when there are conflicting changes in B, I was thinking that you would have to use interactive rebase instead because you can no l
28.
by martinvonz 11mo ago
Ah, I see, so you avoid interactive rebase and instead make all changes in the working copy and use `git commit --fixup` and `git rebase --autosquash` . Makes sense, but doesn't it break down when there are conflicts between the change
29.
by martinvonz 11mo ago
As I understood the scenario: 1. We're rewriting some commits. Let's say a chain of commits A through G. We want to make some change to commits A and D. 2. As we're editing commit D, we realized that we need to make some chan
30.
by martinvonz 11mo ago
Yes, it's certainly possible to do all those things with Git. Compared to jj, it's just much harder to do, easier to mess up, and harder to recover from if you do mess up.

More ›