Live data from Hacker News

Viewing profile — martinvonz

martinvonz

HN member
Joined
Mon, Nov 15, 2021, 11:13 PM UTC
HN karma
314
Public activity
139 items

About martinvonz

My name is Martin von Zweigbergk. I work on source control at Google. github.com/martinvonz

Recent public activity

  1. comment
    Comment #47703665

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

  2. comment
    Comment #47699377

    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 i…

  3. comment
    Comment #46269072

    > 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 ba…

  4. comment
    Comment #46267822

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

  5. comment
    Comment #46267482

    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 mess…

  6. comment
    Comment #46265304

    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 m…

  7. comment
    Comment #46264391

    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. comment
    Comment #46184420

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

  9. comment
    Comment #46184250

    > 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 enthu…

  10. comment
    Comment #46175139

    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.…

  11. comment
    Comment #46174690

    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 we…

  12. comment
    Comment #46174636

    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…

  13. comment
    Comment #46173709

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

  14. comment
    Comment #46171390

    > 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…

  15. comment
    Comment #46171368

    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…

  16. comment
    Comment #46171163

    > 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 b…

  17. comment
    Comment #46170885

    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 amendin…

  18. comment
    Comment #45935100

    > 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 …

  19. comment
    Comment #45807828

    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…

  20. comment
    Comment #45806072

    > Do you want to educate us of the command? Not sure that they had in mind but you can do `jj squash --from :: --destination 'root()' `. That will take the changes to the unwanted …

  21. comment
    Comment #45777283

    > 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 S…

  22. comment
    Comment #45776830

    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 conf…

  23. comment
    Comment #45776723

    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 y…

  24. comment
    Comment #45776661

    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 --u…

  25. comment
    Comment #45776614

    > 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…