4 ms·

The staging area is a hack in that it is its own unique concept that doesn't work with any of the rest of git's tooling without needing special, inconsistent fl

The staging area is a hack in that it is its own unique concept that doesn't work with any of the rest of git's tooling without needing special, inconsistent flags for commands to target it (git stash, git reset, etc.). I use a staging area with jj! I would surmise most jj users do too. It's just a real, honest-to-god commit in the repo instead of a special snowflake. # do some work … # prepare a new, empty commit if you don't already have one jj new --no-edit --insert-before @ # move changes into it; repeat ad nauseam jj squash --interactive Since it's just a commit, all your tools work with it out of the box. And you don't need to stash changes when you jump around between branches.

weinzierl 1y ago
Thanks for the clear and concise summary. It is helpful for some workflows. For me the staging area being a snowflake is the feature. It is a special temporary singleton commit if you will, but I can rely on its temporary and singleton nature. As that it should have a different interface from regular commits.
nchmy 1y ago
Yeah, I regularly have MANY "staging commits" at the same time in jj, in which I just throw ideas in that I don't want to pollute or yet know how to integrate with the other ideas. I use squash, split, interactive split, rebase etc to move lines and changes around etc... When I eventually figure it all out, I can tidy it all up into completely coherent, discrete, sequential commits that make it look like I knew exactly what I was doing from the start, then push to remote. Conversely git staging around stashing was always an absolute, terrifying mystery to me. I could never remember what was stored where, and would consequently end up losing work, repeating work, and, most of all, just making massive commits that make no sense. I was sold on jj from essentially the moment I found it, but I remain routinely amazed at how much more powerful (yet simple!) it is than I realized.
- weinzierl 1y ago
  Hmm, never saw it that way. Maybe I just need a different perspective on commits. Thanks for your comment, that was insightful.
  - nchmy 1y ago
    Glad to be helpful! In my mind, in some sense, every commit can simultaneously be a stash, staging area, part of a branch and more. Because you can easily create endless branches on top of, beside, before, as merges of, etc.. any commit. And it all automatically rebases, conflicts often auto-resolve (or at least don't block you immediately). I really don't know how to best describe it. But there's a reason that many people are quite literally evangelizing it in every post that comes up - who does this for git, or anything? Just give it a try. And, even better, use it via jjui
- 1718627440 1y ago
  You can use commits instead of the stash the same way in git. Isn't this just a way of using, why do you need jj for that? You now you can give stashs a commit message?
  - nchmy 1y ago
    The commit message is the least useful part of all of this. It is just SO EASY to move, merge, split, rebase, squash etc commits, and even just individual lines and sections from within commits (via split). And it's all even easier via jjui I don't think there's anything any of us can really say to convince those of you who are constitutionally skeptical about it (or even allergic to it) why you should try it... If all of our fawning and evangelizing isn't enough to get you to at least give it a fair shake, then there isn't much else to be said.
    - 1718627440 1y ago
      It's just that I'm fine and also the features seam to amount only to a change in usage not in actual new features. In this case if you want to use commits instead of a stash, then you can do that just fine in git. It's also that I want my commit hashes to be stable (because I cross-reference them) and it sounds like they wouldn't in jj, because it is kind of rebase-y?
      - nchmy 1y ago
        It's the new workflows that it enables via making existing features vastly more accessible (though there are some new features, such as merge conflicts not being a showstopper). The only thing left for me to say to folks like you who think git is just fine (or even great) is that you're in Plato's Cave. https://en.m.wikipedia.org/wiki/Allegory_of_the_cave https://en.m.wikipedia.org/wiki/Allegory_of_the_cave You just don't know what you're missing out on. But if you give it a fair shake, you'll see the light quite quickly. Take care!
      - Filligree 1y ago
        Commits in jj have both a commit has (which is unstable) and a commit id (which is not). Generally you use the id, not the hash. And yes, everything you can do with jj you can also do with git. It’s just that most people don’t, because it’s much harder with git, involves rebases and changing hashes, and so on.
turboponyy 1y ago
Can you edit commits by adding on only parts of your "staging" area? Because that's my workflow. I produce a few focused and semantically coherent commits that I'd like to apply to the codebase, where each keeps the codebase in a working state. I might be working on more than one thing at once, but I know which commit each set of changes should "live in." An append-only log of commits is decidedly not something I want. Is jj amenable to this?
- nchmy 1y ago
  It's not quite clear to me what you're talking about, but I think the Megamerge workflow might be something you'd be interested in. https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/ https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj... https://ofcr.se/jujutsu-merge-workflow https://ofcr.se/jujutsu-merge-workflow
- riwsky 1y ago
  Extremely amenable—my workflow shifted to match your description after I started using jj, because it makes that easier. Conceptually, it’s not “edit commits by adding on only parts of your staging area”, but “edit commits by only moving or splitting parts from another commit”, and since the working copy is a commit, it is handled by that general case instead of being it’s own thing.
- joshka 1y ago
  jj squash allows you to move changes from a revision to another. Default is your working copy, but there's nothing preventing you from working on several semantic commits and moving changes from your working copy to those commits as you want. jj squash --into -r <revset> Where <revset> is @-, a change id, or perhaps a bookmark name if you want to give a semantic name to your changes.
- paradox460 1y ago
  Yes. You can use jj split to cleave changes out into their own commit, and JJ squash to move changes into another commit

weinzierl 1y ago

Thanks for the clear and concise summary. It is helpful for some workflows. For me the staging area being a snowflake is the feature. It is a special temporary singleton commit if you will, but I can rely on its temporary and singleton nature. As that it should have a different interface from regular commits.

nchmy 1y ago

Yeah, I regularly have MANY "staging commits" at the same time in jj, in which I just throw ideas in that I don't want to pollute or yet know how to integrate with the other ideas. I use squash, split, interactive split, rebase etc to move lines and changes around etc... When I eventually figure it all out, I can tidy it all up into completely coherent, discrete, sequential commits that make it look like I knew exactly what I was doing from the start, then push to remote. Conversely git staging around stashing was always an absolute, terrifying mystery to me. I could never remember what was stored where, and would consequently end up losing work, repeating work, and, most of all, just making massive commits that make no sense. I was sold on jj from essentially the moment I found it, but I remain routinely amazed at how much more powerful (yet simple!) it is than I realized.

weinzierl 1y ago
Hmm, never saw it that way. Maybe I just need a different perspective on commits. Thanks for your comment, that was insightful.
- nchmy 1y ago
  Glad to be helpful! In my mind, in some sense, every commit can simultaneously be a stash, staging area, part of a branch and more. Because you can easily create endless branches on top of, beside, before, as merges of, etc.. any commit. And it all automatically rebases, conflicts often auto-resolve (or at least don't block you immediately). I really don't know how to best describe it. But there's a reason that many people are quite literally evangelizing it in every post that comes up - who does this for git, or anything? Just give it a try. And, even better, use it via jjui
1718627440 1y ago
You can use commits instead of the stash the same way in git. Isn't this just a way of using, why do you need jj for that? You now you can give stashs a commit message?
- nchmy 1y ago
  The commit message is the least useful part of all of this. It is just SO EASY to move, merge, split, rebase, squash etc commits, and even just individual lines and sections from within commits (via split). And it's all even easier via jjui I don't think there's anything any of us can really say to convince those of you who are constitutionally skeptical about it (or even allergic to it) why you should try it... If all of our fawning and evangelizing isn't enough to get you to at least give it a fair shake, then there isn't much else to be said.
  - 1718627440 1y ago
    It's just that I'm fine and also the features seam to amount only to a change in usage not in actual new features. In this case if you want to use commits instead of a stash, then you can do that just fine in git. It's also that I want my commit hashes to be stable (because I cross-reference them) and it sounds like they wouldn't in jj, because it is kind of rebase-y?
    - nchmy 1y ago
      It's the new workflows that it enables via making existing features vastly more accessible (though there are some new features, such as merge conflicts not being a showstopper). The only thing left for me to say to folks like you who think git is just fine (or even great) is that you're in Plato's Cave. https://en.m.wikipedia.org/wiki/Allegory_of_the_cave https://en.m.wikipedia.org/wiki/Allegory_of_the_cave You just don't know what you're missing out on. But if you give it a fair shake, you'll see the light quite quickly. Take care!
    - Filligree 1y ago
      Commits in jj have both a commit has (which is unstable) and a commit id (which is not). Generally you use the id, not the hash. And yes, everything you can do with jj you can also do with git. It’s just that most people don’t, because it’s much harder with git, involves rebases and changing hashes, and so on.

turboponyy 1y ago

Can you edit commits by adding on only parts of your "staging" area? Because that's my workflow. I produce a few focused and semantically coherent commits that I'd like to apply to the codebase, where each keeps the codebase in a working state. I might be working on more than one thing at once, but I know which commit each set of changes should "live in." An append-only log of commits is decidedly not something I want. Is jj amenable to this?

nchmy 1y ago
It's not quite clear to me what you're talking about, but I think the Megamerge workflow might be something you'd be interested in. https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/ https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj... https://ofcr.se/jujutsu-merge-workflow https://ofcr.se/jujutsu-merge-workflow
riwsky 1y ago
Extremely amenable—my workflow shifted to match your description after I started using jj, because it makes that easier. Conceptually, it’s not “edit commits by adding on only parts of your staging area”, but “edit commits by only moving or splitting parts from another commit”, and since the working copy is a commit, it is handled by that general case instead of being it’s own thing.
joshka 1y ago
jj squash allows you to move changes from a revision to another. Default is your working copy, but there's nothing preventing you from working on several semantic commits and moving changes from your working copy to those commits as you want. jj squash --into -r <revset> Where <revset> is @-, a change id, or perhaps a bookmark name if you want to give a semantic name to your changes.
paradox460 1y ago
Yes. You can use jj split to cleave changes out into their own commit, and JJ squash to move changes into another commit