Viewing profile — martinvonz
martinvonz
HN member- Joined
- Mon, Nov 15, 2021, 11:13 PM UTC
- HN karma
- 314
- Public activity
- 139 items
- HN profile
- View on Hacker News ↗
About martinvonz
Recent public activity
-
comment
Comment #47703665
I agree, but that doesn't seem relevant. I did not say the jj automatically resolves conflicts.
-
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…
-
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…
-
comment
Comment #46267822
Those were rhetorical questions. I know how to use Git. Sorry that I was unclear.
-
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…
-
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…
-
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.
-
comment
Comment #46184420
Maybe you know this already but it's `jj squash --into @----` whether there are conflicts or not.
-
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…
-
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.…
-
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…
-
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…
-
comment
Comment #46173709
The author of `git history` is a GitLab employee and prolific Git contributor. I think he knows how `git rebase` works.
-
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…
-
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…
-
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…
-
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…
-
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 …
-
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…
-
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 …
-
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…
-
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…
-
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…
-
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…
-
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…