6 ms·

Along with the appropriate git stash and git stash pops or git commit -anm wip and git reset HEAD^ so long as you’re not using your staging area for anything, y

Along with the appropriate git stash and git stash pops or git commit -anm wip and git reset HEAD^ so long as you’re not using your staging area for anything, yeah. But if the cherry pick doesn’t cleanly apply at the current HEAD, then you have to remember to either do the git rebase -i first and pause at the appropriate place to cherry pick it if that works (I think it should? though I also recall rebase only letting you pause before a commit so you lose your commit message, but that’s probably a me problem) or else maybe detach your head and start doing surgery because otherwise you’ll be resolving conflicts in two different directions as you cherry pick and then rebase, and at that point I’m usually going back to git reflog to try to find the last point where history made sense. Or I guess you could just remember that you can introduce arbitrary existing commit refs into an interactive rebase like 1718627440 did. But I said I didn’t want to think about this anymore.

1718627440 14d ago
> Along with the appropriate git stash and git stash pops If you don't want to do that, you can tell git to do it automatically too? I actually thought I would like that, so I used it for a week. I did not like it at all. > But if the cherry pick doesn’t cleanly apply at the current HEAD If the diff you want to commit isn't applicable to the tree you want to apply it to, it's not going to work, no matter the VCS you use. > then you have to remember to either do the git rebase -i first and pause at the appropriate place to cherry pick You say that like these would be separate operations, but for me these are very much not, I guess like the fact that you need to supply both '-r oldercommit' and '--before @-' are for you. I think this is the point where I actually don't understand your view. Like, we both need to supply two parameters, we need to because this is the operation we want to do. You write two parameters free form, I write one free and select the other from a list. There is a difference, I actually think selecting from a list can be more convenient in some cases, less in others. But I don't get why you write like it would be crazy work. > though I also recall rebase only letting you pause before a commit so you lose your commit message, but that’s probably a me problem It does only let you handle full commits, if that's what you mean, if you want to split a commit you need to provide information how. But that it doesn't sound like you mean that. > so you lose your commit message You can apply commit metadata independently of the tree you want to commit, so that definitely occurs never. > maybe detach your head I bet you don't have issues with detaching the head in JJ, so why do you in Git, it's just a normal state. > start doing surgery because otherwise you’ll be resolving conflicts in two different directions as you cherry pick and then rebase Yes, but that is not because you use Git, but because you wrote the change against some other commit first, which you don't do in your JJ example. You could do that in Git as well and then you only have one set of merges to resolve. > I’m usually going back to git reflog to try to find the last point where history made sense Which is git rebase --abort or git reset @{1}. The latter is always the same, this is as silly as saying I can't remember whether it's jj undo or jj revert. > But I said I didn’t want to think about this anymore. Yet you do in JJ.
- 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 Git and jj well. But that's just my impression; I may of course be wrong.
- dullcrisp 14d ago
  > I did not like it at all. Because it left you fewer opportunities to experience the ecstasy of typing git commands into a terminal? Or because it didn't work so well?
  - 1718627440 14d ago
    Because it interferes with my workflow. If there are non-committed changes when I want to do something else, they do represent actions I want to do. I don't just have random uncommitted changes there. Setting --autosquash as default results in my finding out I forgot something later. I believe this to be the same with the index, that is praised as unnecessary and "overcomed" in JJ.
    - steveklabnik 13d ago
      I love the index, and often have "uncommitted" stuff lying around. jj makes doing this easier because you represent the index as an unnamed commit, and everything just works, as opposed to needing to manage the index vs committed changes with separate tools.
      - 1718627440 13d ago
        The absence of "needing to manage the index" is what breaks my workflow.
        steveklabnik 13d ago
        What I mean is, you manage the index with the same commands that you manage commits with. The emphasis is on "with separate tools" not "manage the index". I am super curious as to what you mean specifically, but I also know that getting into details can be annoying, so if you have some specifics I'd love to hear more about them. I loved git's index so this isn't coming from a place of "the index sucks and you shouldn't care about it" it's "I think jj executes the index better than git does actually". But also if you don't, that's fine by me too, if you like a tool you should continue to use it. (I never set autosquash either)

1718627440 14d ago

> Along with the appropriate git stash and git stash pops If you don't want to do that, you can tell git to do it automatically too? I actually thought I would like that, so I used it for a week. I did not like it at all. > But if the cherry pick doesn’t cleanly apply at the current HEAD If the diff you want to commit isn't applicable to the tree you want to apply it to, it's not going to work, no matter the VCS you use. > then you have to remember to either do the git rebase -i first and pause at the appropriate place to cherry pick You say that like these would be separate operations, but for me these are very much not, I guess like the fact that you need to supply both '-r oldercommit' and '--before @-' are for you. I think this is the point where I actually don't understand your view. Like, we both need to supply two parameters, we need to because this is the operation we want to do. You write two parameters free form, I write one free and select the other from a list. There is a difference, I actually think selecting from a list can be more convenient in some cases, less in others. But I don't get why you write like it would be crazy work. > though I also recall rebase only letting you pause before a commit so you lose your commit message, but that’s probably a me problem It does only let you handle full commits, if that's what you mean, if you want to split a commit you need to provide information how. But that it doesn't sound like you mean that. > so you lose your commit message You can apply commit metadata independently of the tree you want to commit, so that definitely occurs never. > maybe detach your head I bet you don't have issues with detaching the head in JJ, so why do you in Git, it's just a normal state. > start doing surgery because otherwise you’ll be resolving conflicts in two different directions as you cherry pick and then rebase Yes, but that is not because you use Git, but because you wrote the change against some other commit first, which you don't do in your JJ example. You could do that in Git as well and then you only have one set of merges to resolve. > I’m usually going back to git reflog to try to find the last point where history made sense Which is git rebase --abort or git reset @{1}. The latter is always the same, this is as silly as saying I can't remember whether it's jj undo or jj revert. > But I said I didn’t want to think about this anymore. Yet you do in JJ.

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 Git and jj well. But that's just my impression; I may of course be wrong.
dullcrisp 14d ago
> I did not like it at all. Because it left you fewer opportunities to experience the ecstasy of typing git commands into a terminal? Or because it didn't work so well?
- 1718627440 14d ago
  Because it interferes with my workflow. If there are non-committed changes when I want to do something else, they do represent actions I want to do. I don't just have random uncommitted changes there. Setting --autosquash as default results in my finding out I forgot something later. I believe this to be the same with the index, that is praised as unnecessary and "overcomed" in JJ.
  - steveklabnik 13d ago
    I love the index, and often have "uncommitted" stuff lying around. jj makes doing this easier because you represent the index as an unnamed commit, and everything just works, as opposed to needing to manage the index vs committed changes with separate tools.
    - 1718627440 13d ago
      The absence of "needing to manage the index" is what breaks my workflow.
      - steveklabnik 13d ago
        What I mean is, you manage the index with the same commands that you manage commits with. The emphasis is on "with separate tools" not "manage the index". I am super curious as to what you mean specifically, but I also know that getting into details can be annoying, so if you have some specifics I'd love to hear more about them. I loved git's index so this isn't coming from a place of "the index sucks and you shouldn't care about it" it's "I think jj executes the index better than git does actually". But also if you don't, that's fine by me too, if you like a tool you should continue to use it. (I never set autosquash either)