91–100 of 120 posts
I get that naming is one of the hardest problems in computer science, but naming software after a martial art is just lazy and will lead to problems with things like searches
I guess it's lucky they misspelled it, so there's no conflict.
Earlier quoted context omitted.
I guess it's lucky they misspelled it, so there's no conflict.
I would have spelled it "jiu-jitsu" if I had not looked up the spelling first and found that Wikipedia decided to spell it "jujutsu" ( https://en.wikipedia.org/wiki/Jujutsu ). Maybe I trusted Wikipedia too much; I have never practiced jujutsu/jiu-jitsu myself.
Can someone sometimes use jj and sometimes use git in the same repo?
From a tiny bit of previous jj experience, my mental model is "a commit is the snapshot, and a change is what happened between snapshots", but that might be wrong. It would be great if this could be clarified a bit more in the tutorial.
This was informative, thanks Steve! The only problem I had was that the difference between changes and commits wasn't clarified enough in the beginning, and I got lost trying to distinguish between the two. I'm on chapter 4 and I'm still not sure what a change is and what a commit is. From a tiny bit of previous jj experience, my mental model is "a commit is the snapshot, and a change is what happened between snapsho…
Your mental model sounds decent. I think there’s a few ways to describe things. I like to think of changes as a stable ID for something I want to accomplish, and a commit as the intermediate steps that make up a change. You can kind of think of a change as a branch… but I think that’s stretching it.
Love it, read a couple of chapters already and planning to finish the rest. As a person completely new to jj and someone who also enjoys git CLI, this is an intuitive, very useful and enjoyable read. I’m especially interested after learning about the git compatible backend: > There's one other reason you should be interested in giving jj a try: it has a git compatible backend, and so you can use jj on your own, witho…
Earlier quoted context omitted.
Thanks so much! Just want to point out that this hasn’t been updated in a minute, and in particular, you’ll get some messages about branches being bookmarks now: https://github.com/steveklabnik/jujutsu-tutorial/pull/34 I have started on a second iteration of the tutorial in private, and am gonna see if I can get it in shape this weekend. Happy to answer questions about jj!
I've been meaning to figure out JJ for a few months now. Part of why I havent was that your tutorial is a bit out of date. I can't wait for a revamp!
This was informative, thanks Steve! The only problem I had was that the difference between changes and commits wasn't clarified enough in the beginning, and I got lost trying to distinguish between the two. I'm on chapter 4 and I'm still not sure what a change is and what a commit is. From a tiny bit of previous jj experience, my mental model is "a commit is the snapshot, and a change is what happened between snapsho…
Thanks for the feedback! I think these terms are used a bit loosely, even though I try to be precise about it. Your mental model sounds decent. I think there’s a few ways to describe things. I like to think of changes as a stable ID for something I want to accomplish, and a commit as the intermediate steps that make up a change. You can kind of think of a change as a branch… but I think that’s stretching it.
Clarifying early on what exactly a change ID is, when it changes, and what the relationship between changes and commits is would really help, I think.
> I also heard friends rave about "stacked diffs" but struggled to understand what exactly was going on there. Nothing I read or conversations I had have clicked. I wonder what it is about descriptions of stacked diffs that doesn't land - it's literally just a rebase-centric workflow instead of the merge-centric workflow popularised by GitHub et al.
For me, my git brain is very low level. And none of them ever explains what actually happens under the hood, or how that was different than branching… With some respect, I think “rebase centric workflow” doesn’t really cover it: I use rebasing heavily with GitHub. A “trunk based development where all branches are rebased before merge so there’s never merge commits, please add to commits and rebase the branches in res…
refactor/a # should be merged as independent PR
feature/a-b # depends on a; should be merged independently, after
fix/c # independent
How else than "stacked diffs" would you submit all of this for review concurrently while still working on all of them? It sounds like a new word for what we were always expected to do? What's an alternative which doesn't rely on compromising merge-strategy?
At this point I'm suspecting "stacked diffs" is just a crotch for people still barely coping with DVCS but I could be missing something.