241–250 of 552 posts
Earlier quoted context omitted.
If I had an option, I would still be using something like Subversion or Mercurial. As it is, I go with whatever our clients require of us, and that isn't jj.
You're misunderstanding. You can use it with any git repo without anyone knowing.
Earlier quoted context omitted.
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 exact…
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?
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.
Earlier quoted context omitted.
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…
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 wan…
https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj...
Earlier quoted context omitted.
It’s not just that it’s simpler, it’s that the primitives and interaction model are also strictly more powerful. A ton of extremely useful workflows that are an utter pain in the ass with git are absolutely trivial with jj. One example is a series of dependent PRs. This is excruciating in git if you ever need to make a fix to an earlier PR because you have to manually rebase every subsequent change. It’s trivial in j…
> The subsequent revisions are updated automatically How do you make sure, that a commit isn't changed under you, because someone thought, it would be a good idea to change an earlier revision? I think having immutable commits including all the previous history is a feature, not a bug.
All changes can be modified, but if you try and update a change marked as "immutable", then Jujutsu will error out unless you provide a specific flag. This generally provides a lot of protection against unexpected rebases from other people.
You also have a local immutable history of every update to your copy of the repo. This includes fetches/pulls, so you can easily see and undo those changes if something does go wrong along the way. But if people are deliberately force-pushing to master, you're going to end up in weird states whatever to you use.
Earlier quoted context omitted.
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 exact…
Hmm, never saw it that way. Maybe I just need a different perspective on commits. Thanks for your comment, that was insightful.
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
Earlier quoted context omitted.
Right now I can mess around like I want, because I am in charge what gets tracked, I need to specify it explicitly. This would loose that.
this is not as important as you're used to. I've been there, I've used git since early 2010s and yes autostaging was preposterous at first. in practice, it's barely relevant: the workflow changes from 'I pick what is tracked' to 'I pick what is pushed'.
Earlier quoted context omitted.
I feel like I just outlined a situation where something that's weird in git is completely natural in jj. Maybe I miscommunicated?
I think you communicated well, probably I did not. > suspending the rebase and going to do something else This is what I find to be weird, personally. When doing a rebase, there’s no way I want to do something else in the middle of it, and having a modal state feels totally natural to me. At first approach (I read a (very good) intro[1]; I did not try), it seems there’s a lot of new things to learn (for instance the…
Git worktrees suffice, but they're still heavier weight than `jj new whatever`.
Earlier quoted context omitted.
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?
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 a…
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?
Earlier quoted context omitted.
You're misunderstanding. You can use it with any git repo without anyone knowing.
Usually I am pretty much against snowflake approaches in project delivery, setup should be the same for everyone, as people change roles across projects routinely.
Earlier quoted context omitted.
For me a merge is about grouping commits, when you have just a list of commits, the list can be very long. That's also useful for bisecting, as you can first find the feature that is buggy and then find the commit that introduced it.
The whole point of bisect is to make it quicker to find a point in a potentially long list of commits. Finding the feature first then bisecting within the branch is only going to make it slower, and requires you to manually restart the bisect. I use the commit message to add ticket numbers to things to group commits.
I prefer to have everything in a single source of truth (git), so everything is in commits. Your tickets are my merge commits.