martinvonz · HackerTrans

martinvonz

no profile record

Submissions

Design of a lock-free DVCS (rsync-/Dropbox-/NFS-safe)

github.com

1 pointsby martinvonzقبل 5 سنوات0 comments

Show HN: The Best of Git, Mercurial, and Pijul in One VCS?

github.com

2 pointsby martinvonzقبل 5 سنوات4 comments

comments

قبل 4 أشهرdiscuss

I agree, but that doesn't seem relevant. I did not say the jj automatically resolves conflicts.

قبل 4 أشهرdiscuss

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 resolve each conflict and then `git rebase --continue`.

However, the conflict algebra does remove many common uses of rerere. See https://github.com/jj-vcs/jj/issues/175#issuecomment-1079831... for a longer discussion.

قبل 7 أشهرdiscuss

> 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 move the index back one step, so the index is empty (relative to HEAD) and the working copy has the combination of changes that were in the previous HEAD commit and the working copy (relative to the previous HEAD). I think that's more like squashing than splitting because we have fewer "things" after: we have one commit fewer (the previous HEAD commit may of course still be reachable from another branch, in which case we still have the same number of "things" afterwards). It's similar with `--soft` and `--hard`, except that the old changes end up in a different "thing".

At a less technical level, the point of splitting a commit is to end up with some of the changes from one commit in a new commit and the rest of the changes in another commit. That's what meant when I said "`git reset` by itself doesn't split a commit", because you need to do something like this:

  git reset HEAD^
  git add -p
  git commit -C HEAD@{1}

> Ok, but then what was your point?

Just that additional steps are needed.

For example, if you wanted to split the HEAD commit but you had already started working on a new commit so have some changes in the working copy, then you might instead have to do something like this:

  git commit -m tmp
  git rebase -i HEAD^^ # Use the "edit" action for the first commit
  git add -p
  git commit -m first
  git rebase --continue
  git reset HEAD^

The other case I mentioned was if you want to split a commit on another branch. Then you have to insert some additional commands in that sequence. As I said, I know how to do this with Git. I just find it easier to do with jj, where it's `jj split -r xyz` to split commit xyz, whether it's the current working copy, an ancestor commit, or on an unrelated branch.

(Take my Git commands with a grain of salt because I haven't used Git in 10 years.)

قبل 7 أشهرdiscuss

Those were rhetorical questions. I know how to use Git. Sorry that I was unclear.

قبل 7 أشهرdiscuss

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 other changes in the working copy first? Or if you want to split a commit that's not at HEAD?

قبل 7 أشهرdiscuss

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.

قبل 7 أشهرdiscuss

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.

قبل 8 أشهرdiscuss

Maybe you know this already but it's `jj squash --into @----` whether there are conflicts or not.

قبل 8 أشهرdiscuss

> 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. I haven't heard from anyone who used jj for a few months and knew it well and then switched to Git.

قبل 8 أشهرdiscuss

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 about the formatting here. I guess you'll have to copy & paste it to read it)

What I'm saying is that if I want to fix something in D, I do `jj new D` to create a new commit on top of D. Then I make the fix, run tests, etc., and then I run `jj squash` to amend the changes into D. The descendant commits (E through J) then get automatically rebased and the feature bookmarks/branches get updated.

I didn't follow what you about it other changes needed for updating the ancestor. Can you explain in the context of this example?

قبل 8 أشهرdiscuss

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 hard to update many refs at once with Git in the first place (there's `git rebase --update-refs` but not much else?), so undoing multiple ref-updates is not as relevant there.

قبل 8 أشهرdiscuss

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 but it feels like it could be done in a backwards-compatible way. It sounds like a ton of work, though, especially if it's going to be a transition from having the current ref storage be the source of truth to making the operation log the source of truth.

قبل 8 أشهرdiscuss

The author of `git history` is a GitLab employee and prolific Git contributor. I think he knows how `git rebase` works.

قبل 8 أشهرdiscuss

> 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 local branches. When I used Git, I had a script for rebasing dependent branches. I remember that a coworker had written a similar script.

I think jj is generally more useful for people like me who often have lots of independent and dependent work in progress. If you mostly just have a one review at a time, there's much less benefit. Perhaps I would say that `jj undo` might be the most useful feature for users with simpler development (yes, I know about the reflog, but see the video I linked to in the other message).

قبل 8 أشهرdiscuss

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 interesting: https://www.youtube.com/watch?v=PsiXflgIC8Q. Scott is a GitHub cofounder, author of Pro Git, and now runs GitButler.

> I don't think making another tool entirely is the right solution.

I considered making the changes to Git but the changes I wanted to make would make the UX so different that it would basically mean introducing a whole parallel command set to Git. I figured it would take ages to get Git to that state, if I could sell the ideas to the Git community at all. By the way, the video above talks about an proposed `git history` series of commands inspired by Jujutsu (also see https://lore.kernel.org/git/20250819-b4-pks-history-builtin-...).

قبل 8 أشهرdiscuss

> 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 looked at its FAQ, and saw a bunch of nonsensical new terms as well.

Like what? Perhaps we can improve it.

قبل 8 أشهرdiscuss

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.

قبل 8 أشهرdiscuss

> 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 then you `git commit`? With jj, you would run `jj split` instead of the first `git add -p` and then `jj squash -i` instead of the subsequent ones. There's no need to do anything instead of `git commit`, assuming you gave the first commit a good description when you ran `jj split`. This scenario seems similarly complex with Git and jj. Did you have a different scenario in mind or do you disagree that the complexity is similar between the tools in this scenario? Maybe I'm missing some part of it, like unstaging some of the changes?

قبل 9 أشهرdiscuss

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?

قبل 9 أشهرdiscuss

> 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 changes to the unwanted file from all those commits and move them into a new commit based on the root commit (the root commit is virtual commit that's the ancestor of every other commit).