[HN Gopher] Steve's Jujutsu Tutorial
___________________________________________________________________
Steve's Jujutsu Tutorial
Author : drudru
Score : 97 points
Date : 2024-10-18 16:52 UTC (1 days ago)
(HTM) web link (steveklabnik.github.io)
(TXT) w3m dump (steveklabnik.github.io)
| drudru wrote:
| Steve wrote this in a very approachable style. It is the first
| time I really understood what 'jj' is about. I'm actually kind of
| excited to start using this tool with my git repos.
| steveklabnik wrote:
| 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!
| drudru wrote:
| Thank you Steve! Really enjoying this tutorial. No questions
| so far.
| emmelaich wrote:
| Does "in a minute" mean "not for a long time"? Because that's
| how my kids use that phrase.
|
| English is so great and so confusing!
| stackghost wrote:
| It means both "in a long time" and "in a short time",
| depending on context and intonation.
| steveklabnik wrote:
| Yep, isn't language grand?
| nchmy wrote:
| 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!
| miguelxpn wrote:
| No surprises there. Steve has always been a great writer.
| nixosbestos wrote:
| One of my favorite people talking about my single favorite tool
| of the past 3+ years. Up there with (above, really) zellij and
| helix for changing my daily life.
| emmanueloga_ wrote:
| Helix, the editor? How would you pitch it?
|
| Zellij looks powerful but also a bit too complex, following the
| "kitchen sink" school of design :-). No biggie but its name is
| too close to IntelliJ imho. What kind of workflow do you use
| with it?
|
| I used tmux a bit back in the day, but these days I feel like
| good old tabs and app windows cover my needs. When I want to
| multiplex processes in a single window, I reach for Overmind.
| [1]
|
| --
|
| 1: https://github.com/DarthSim/overmind
| Lyngbakr wrote:
| > Helix, the editor? How would you pitch it?
|
| Not the OP, but Helix is a minimal fuss modal editor with
| sensible defaults. My config is maybe five lines? I say
| "maybe" because I haven't looked at it I first wrote it. And
| I think I'd probably be just fine with no config.
| imjonse wrote:
| Sensible defaults but also out of the box features you only
| get in vim by finding and configuring external plugins
| (fuzzy file picker, LSP integration, multi-cursor editing,
| inline keymapping help).
|
| Cons: no session save, good Helix keybindings not available
| in other tools so confusing to switch between vim/hx mental
| models when in colab/vscode, no AI-assistants since no
| plugin system yet.
| stavros wrote:
| I don't know what you find complex about Zellij, as I haven't
| used it extensively, but the few times I've used it, the UI
| was eminently self-describing, I managed to do everything
| I've needed to do within a minute of first launching it.
|
| Is there more advanced stuff that's more complex that I just
| haven't seen?
| emmanueloga_ wrote:
| > Is there more advanced stuff that's more complex that I
| just haven't seen?
|
| Yes? I mean, it even has a system to install plugins made
| with WASM, from what I saw in the docs. I guess you could
| just use the basics and be okay with it.
|
| For me, after years of tinkering with apps like Vim, Emacs,
| and AwesomeWM [1], I've developed a bit of PTSD over the
| amount of time these kinds of tools can take to configure
| and master [2]. Zellij feels like it belongs in this
| category of tools, and perhaps I'm overreacting or
| flinching. :-)
|
| --
|
| 1: https://awesomewm.org/
|
| 2: I've benefitted a lot from being able to use vim key
| bindings with extensions in apps like VS Code and emacs key
| bindings on _places_ and I 'm somewhat glad I spent the
| time, though.
| stavros wrote:
| Those things are optional, though. You can just use the
| basics and ignore the rest.
| rw_panic0_0 wrote:
| nice to see zellij+helix combo users out there. Helix been my
| fav editor for like a year already, zellij is also a daily
| driver, and now i'm learning jj :P
| nixosbestos wrote:
| Do you use nixos? ;)
| 38 wrote:
| Jujutsu is terrible in my opinion. people hate the index, but I
| think they just dont get it. to me a commit is something that is
| ready to push, and the index is for stuff that is done but not
| ready to push. just because I wrote one line that I am happy
| with, doesn't mean I am ready to commit and push that. I prefer
| to add stuff thats done, then when enough is done I can commit
| and push. if you remove the index it makes it too easy to push
| half done stuff
| steveklabnik wrote:
| I like jj because I like git's index so much. JJ lets me do
| what git's index does, but in a much more powerful way.
|
| What you do is, you treat @ like the index, and you work on @-.
| This is the "squash workflow"
| https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...
| 38 wrote:
| OK but again thats awful, because @ IS A COMMIT, so you are
| only a "git push" away from accidentally pushing arbitrary
| garbage instead of proper changes
| nasso_dev wrote:
| Actually, `jj git push` will only push named branches,
| which are now called "bookmarks".
|
| You simply don't attach a bookmark to @, and `jj git push`
| will NEVER push it (to what branch would it push?)
|
| The branch you're working on is instead on @-. So when you
| squash, it updates the branch.
| abhinavk wrote:
| You need to think commits as of a non-depleting commodity.
| And named-branches (bookmarks) as something that is
| explicitly set to newer commits/changes.
| aseipp wrote:
| You are simply misinformed. `git push` always pushes the
| HEAD by default without question, but jj does not. @ is not
| special in any way, so it does not get special treatment
| from push. It will only push branches you tell it to or
| that have been amended/updated and are not immutable. jj
| also does not update any branch pointers (or "bookmarks" as
| we call them) unless you explicitly ask it to. You have to
| explicitly run `jj branch set ...` and then run `jj git
| push` to get the behavior you are describing, which is much
| more explicit.
| chaostheory wrote:
| 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
| red_admiral wrote:
| Like naming your language after a common two-letter verb. At
| least we can search for 'golang'.
| riwsky wrote:
| If it helps, they actually named it after their desired CLI
| abbreviation:
|
| > The command-line tool is called jj for now because it's easy
| to type and easy to replace (rare in English). The project is
| called "Jujutsu" because it matches "jj".
| gcarvalho wrote:
| And the martial art is jiu-jitsu, not jujutsu. Similar
| sounding but definitely not "named after".
| stavros wrote:
| I guess it's lucky they misspelled it, so there's no conflict.
| martinvonz wrote:
| 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.
| stavros wrote:
| Oh wow, I had no idea, thanks.
| aos wrote:
| I've started to use jj much more often (and actually used this
| tutorial to get me started!). I do wish its interaction with Nix
| flakes is less annoying though, but that's not the fault jj.
| phildenhoff wrote:
| Steve, I see you're in this thread. I was using jj for a while
| before reading your tutorial and yet still found it quite
| insightful and helpful. Thanks for your contribution!
| steveklabnik wrote:
| You're welcome!
| cyanf wrote:
| thank you steve, i've been excited for this!
| steveklabnik wrote:
| You're welcome!
| itohihiyt wrote:
| Came here for a martial arts tutorial, which I thought was a bit
| weird to see front page on HN, and now I see an alternative to
| git.
|
| I don't particularly like git and for personal projects use
| fossil instead.
|
| Without going through the whole tutorial, and doing a lot more
| reading, why should I consider using this over fossil?
| kettleballroll wrote:
| Same. I miss the old times when people tried naming their
| projects sensibly. I mean, we're constantly telling ourselves
| how variable and function names should speak for themselves,
| but then we name our projects using random, completely non-
| descript names. It's a annoying.
| chronial wrote:
| Which old times are you referring to / what are "sensible"
| names?
|
| I thought about it and I don't know what a better name would
| be. Off the top of my Head, I know Perforce, BitWarden,
| Subversion, fossil and git. And then the abbreviations CVS,
| RCS and SVN.
|
| Do any of these qualify as a descriptive name?
| itohihiyt wrote:
| As a British national I like to think git is a very
| descriptive name, because git is a git to use and
| understand.
| batch12 wrote:
| For a US southerner it works too. We can use the tool to
| 'git' our code.
| phrenq wrote:
| At one point in my career, I used Microsoft SourceSafe,
| which is a pretty descriptive name. Seems like the
| exception here, though.
| kettleballroll wrote:
| I don't just mean version control systems, but since you
| mentioned them: CVS (concurrent version system), rcs
| (revision control system) and subversion all seem fairly
| descriptive to me?
| abc123abc123 wrote:
| Interesting. I'm not a professional developer and also love
| fossil for toy/hobby projects. I find it fascinating that this
| well crafted, solid piece of software is so forgotten, and that
| git has just rolled over everything.
| thiht wrote:
| Honestly you could sell me the best alternative to Git that
| exists and I still wouldn't switch, or even try it. I don't
| care enough about my versioning system to use something else
| than what everybody uses. Ubiquity beats convenience.
|
| What I care about is the tooling around it: GitHub and its
| ecosystem mainly. I also want my open source projects to be
| on GitHub specifically, and I don't want to ask contributors
| to use something other than Git.
| steveklabnik wrote:
| Totally respect you wanting to not care about tools, but
| for the latter part, I do agree with you, which is why I
| like jj: it uses a git repo as its backing store, so your
| projects can live on GitHub and all the rest of your
| collaborators can use git. Nobody else needs to know or
| care.
| thiht wrote:
| Wow I've heard about jj multiple times before but didn't
| realize it was compatible with Git. You got me interested
| in just 1 sentence, nicely done!
|
| Well, guess I'm on my way to read the tutorial.
| steveklabnik wrote:
| Glad to hear it! It's a killer feature, for sure.
| otherme123 wrote:
| Same here, the fact that it includes bug tracker, web UI and
| wiki/docs is a huge plus.
| tmtvl wrote:
| Yeah, I was also wondering 'Traditional JJ or BJJ?'
|
| I've never really messed around with VCSes other than git and
| Subversion, there's people who really like Mercurial though, so
| I wonder how jj compares to that.
| ZoomZoomZoom wrote:
| Would be great if it was Pijul that got Steve's attention.
| Sometimes it's all you need to achieve a lot.
| cinntaile wrote:
| No updates since March 2024?
| steveklabnik wrote:
| I'll just be honest with you: Pijul never really caught my
| interest, but I always felt pretty neutral about it until I
| started noticing the project authors acting very snide and
| aggressive on here. That is not something I want to be around
| these days, and so I doubt I'll ever try Pijul.
| ZoomZoomZoom wrote:
| It's a little surprising to hear, from what I've seen here
| there's not much besides the usual whiff of academical
| loftiness, but nothing that I'd qualify as aggression.
|
| What caught my interest:
|
| * Separate operations and data
|
| * Partial repos = no big repo issues, no need for shallow
| clones and such
|
| * Proper and easy merging with no shuffled lines
|
| * Patch-based model is much more intuitive (e.g. rebase and
| merge are the same operation)
|
| * Conflict resolutions are stored and can be reapplied!
| lawn wrote:
| I really like Jujutsu but I went back to Git because there wasn't
| a Neovim plugin with features comparable to Neogit or Fugitive.
|
| I even started writing one but that was a pretty big project and
| I lost the motivation for it.
| steveklabnik wrote:
| I've heard people say similar things about magit. Tooling
| matters a lot, for sure.
| red_admiral wrote:
| I expected actual Jujutsu :)
|
| I recommend looking up Bartitsu (that Conan Doyle spelled
| Baritsu), a short-lived but very interesting martial art.
| klauserc wrote:
| Been using jj at work for months now. In colocated mode,
| JetBrains IDEs even retain some if their VCS integration.
|
| The ability to easily work on top of an octopus merge and then
| push changes "down" into the contributing branches has been a
| live saver when my team had to do a big refactoring in a mono
| repo and split the changes into small PRs for individual teams
| (code owners).
|
| The auto committing behavior is a bit weird at first, but now I
| don't want to go back to git. It feels a bit like the step from
| SVN to git back in the the day. ("this feels weird" -> "how did
| people ever tolerate the old way?")
| conaclos wrote:
| > The auto committing behavior is a bit weird at first
|
| I am a bit skeptical about this, because this requires a jj
| daemon?
| abhinavk wrote:
| No from what I see. It does that whenever you run any jj
| command.
|
| I haven't checked the source.
| sheremetyev wrote:
| by default snapshotting happens on each jj command
|
| additionally you can enable automatic snapshots when files
| in the working copy are updated:
| https://martinvonz.github.io/jj/latest/config/#watchman
| aseipp wrote:
| It's a bit of a magic trick. A "snapshot" is taken any time a
| command is run, and it happens implicitly before any actual
| algorithms or code for a given command is run (massively
| simplifying the internal design), so for all intents and
| purposes it's "automatic" from the user interface e.g. even
| checking repo status or otherwise small operations will cause
| a snapshot.
|
| But you can integrate with
| https://github.com/facebook/watchman/ in order to have a
| truly daemon-ified option where any filesystem write will
| cause a snapshot to be taken.
| steveklabnik wrote:
| Full agreement on both "it feels weird" -> "how do people ever
| tolerate the old way" as well as the auto commit behavior being
| one of those things. In fact I probably over-index on that
| specifically when talking about jj. I thought I'd hate this
| because I love git's index. Turns out that by getting rid of
| the index, jj has a better index than git does, but that sounds
| insane at first!
| videlov wrote:
| Martin (the jj creator) recently gave a talk at the Git Merge
| 2024 conference: https://youtu.be/LV0JzI8IcCY?si=Pun7WJp4ZWvHq-3G
| leighleighleigh wrote:
| It's my first time encountering your writing Steve, loved it!
| Time to give JJ another crack...
| steveklabnik wrote:
| Glad to hear it!
| swiftcoder wrote:
| > 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.
| arccy wrote:
| because it's a name that describes the technical
| implementation, not the end user experience
| swiftcoder wrote:
| Maybe the problem here is that there aren't any open tools
| implementing the user experience, because I'd say it's
| exactly the opposite - that it is implemented using rebase
| under the hood is entirely secondary to the user experience
| of "stacking" changes on top of one another.
| steveklabnik wrote:
| This is a major issue for sure. Like a big enough one that
| if I was still doing major open source work, I'd be working
| on that.
| steveklabnik wrote:
| 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 response to review comments" development
| style is still very rebase centric, but not stacked.
|
| You also have to remember (though there's no reason you should
| know this) that GitHub came out of the community I was heavily
| involved in at the time of its birth. I've been using GitHub
| for longer than most people, and so the PR-style workflow has
| been the air I've breathed for so long, it can be hard to
| understand other things at first. I had used subversion before
| git, but didn't really understand much about it.
|
| Anyway, that's just a roundabout way of saying that I think
| this space is super interesting because these tools are so
| flexible that they can be used in so many different ways, and
| it's easy to assume that "how you use git" is some sort of
| shared experience when that's not really true.
| Kinrany wrote:
| The holy grail of a stacked diff workflow would be making
| multiple Github PRs each made against the previous branch
| instead of trunk, and then updating the branch that's closest
| to trunk and rebasing all of the children PRs without having
| to force push into any of them.
|
| Git and Github do not support this workflow directly, and
| this creates space for all the other tools.
|
| Jujutsu comes close to supporting this workflow directly,
| without having to provide any specialized utilities that
| mention "stacked diffs" at all.
|
| https://github.com/spacedentist/spr (not to be confused with
| ejoffe/spr) is a utility that maps a local change to a remote
| branch, updating the branch (without force pushes) when the
| local change is updated. (Changes work the same as they do in
| JJ, but the implementation is different.) And this works even
| when you have a stack of changes and update one in the middle
| of the stack.
| steveklabnik wrote:
| The https://github.com/sunshowers/spr fork supports jj :)
| swiftcoder wrote:
| Yeah, and I think it's also worth noting that by far the
| largest set of folks advocating for stacked diffs are not
| actually using git.
|
| Meta runs a custom mercurial-compatible monorepo that was
| scaled up to handle thousands of commits per hour, and they
| have a culture of constant codebase-wide refactoring commits
| (i.e. the ongoing live migration of PHP -> Hack) - that rate
| of change causes problems that most GitHub projects have no
| reason to solve.
| jFriedensreich wrote:
| I am torn between sapling and jj. Both make good progress in
| git/github integration which seems to have been the major road
| block in adoption before. One other major roadblock seems to be
| the limits of review tools supporting stacks: github PRs are too
| limited, gerrits ux is horrible, graphite does not work and is
| not open enough, saplings review tool is just a very slow
| performing POC (though with a really good UI concept as starting
| point)
| sheremetyev wrote:
| for me important argument in favour of JJ over Sapling was
| "first-class conflicts" - JJ stores conflicts in the history
| and allows you to resolve them later, while Sapling forces you
| to resolve conflicts at the point when they happen
|
| https://martinvonz.github.io/jj/latest/sapling-comparison/
| steveklabnik wrote:
| I think it's great that there is more than one project in this
| space. Sapling is pretty cool too, though I haven't used it as
| much.
|
| And yeah, the lack of good review tooling is certainly a big
| issue.
| aseipp wrote:
| Gerrit, as I like to say, has a user interface that only a
| mother could love. But ultimately it's a very productive tool,
| so I just got over it. I even wrote some integration between jj
| and gerrit, making submitting stacks very easy and smooth.
|
| IMO, Gerrit is the best currently available option by a large
| margin, notwithstanding its quirks.
| forrestthewoods wrote:
| I'd love a Sapling vs JJ comparison post. I use Sapling at the
| day job and... it's pretty dang good! Although I don't see how
| I'd recommend it outside of Meta.
|
| I swear the modern programmer doesn't realize how extremely bad
| Git is. It does do a lot of things better than SVN. But it's a
| long, long ways from "good" imho.
|
| I blame GitHub. Git didn't win because it's good. Git won because
| GitHub won. If only HgHub had won instead, alas.
|
| My dream VCS system would have a virtual file system, copy-on-
| write storage, and a system wide blob cache. The goal being to
| allow open source repos to commit *ALL* their dependencies, up to
| and including toolchains in many cases.
| aseipp wrote:
| I used Sapling for many months before switching to JJ. In my
| mind -- and I'm insanely biased as I am a JJ developer at this
| point -- they are both leagues ahead of Git, but I think JJ's
| Git interop, conflict handling, and general UX make it much
| more powerful and general than Sapling. Conflict handling alone
| is leagues better. (Martin worked on version control for a long
| time, and JJ is a tool that can only be created by someone with
| deep expertise in the domain, which I think shows itself over
| and over again in its use.)
|
| If you are already using Sapling then at least trying it should
| be fairly easy and familiar. You could also write a JJ backend
| for Mononoke and EdenFS if you wanted and then use it at work
| ;) You wouldn't be the first JJ user from Meta, actually...
|
| We do have plans to explore server-side designs with virtual
| filesystems, chunked storage, etc. There's nothing concrete
| yet.
|
| (Another benefit is that JJ is much easier to write patches and
| contribute to due to being a relatively new, small Rust
| project, whereas Sapling is much more developed but much bigger
| and harder to get into, I think.)
| forrestthewoods wrote:
| JJ's conflict handling seems nice. Can't say that it's a big
| enough problem for me to qualify as a "major feature", but a
| seemingly nice improvement.
|
| I'm not sure how I feel about JJ's "working copy commit". One
| of the great things about Meta VCS is that _all_ commits are
| automatically backed up into the cloud. Which seems
| incompatible with the JJ model? Not sure. I think the D in
| DVCS is *wildly* overrated. 99.999% of projects are defacto
| centralized.
|
| I'm #TeamMonoRepo 100% of the way. My background is gamedev
| and perforce. An industry which still uses Perforce because
| Git is poopy poop poop. The Git integration I want to see is
| the ability to easily sync a monorepo subfolder with an
| external GitHub repo. Syncing commits for internal projects
| that are open sourced requires a big ugly custom set of
| tooling. And I'd kind of like a way to do an "inner fork"
| within a monorepo if that makes sense.
|
| If you're interested here's a pair of blog posts I wrote that
| have at least some of my thoughts on source control.
|
| https://www.forrestthewoods.com/blog/dependencies-belong-
| in-... https://www.forrestthewoods.com/blog/using-zig-to-
| commit-too...
| aseipp wrote:
| Conflict handling is much more useful whenever you actually
| have conflicts arising regularly. :) For working on JJ
| itself, this is super useful because it's still actively
| having tons of code written by 2-3 people, continuously. In
| other words, the velocity for newly written code is still
| very high, internal APIs change breaking PRs, etc. I think
| how often you handle conflicts in a project has a big
| number of factors. But JJ really does make conflict
| handling not 1 but like 3-5 times easier, IMO. So you only
| really need to do it _once_ to be wow-ed, in my opinion.
| (One of my previous coworkers said something like, and I
| quote, "This is fucking awesome.")
|
| JJ has an abstract notion of a working copy and even an
| abstract notion of a backend that stores commits. It is a
| set of Rust crates, and these are interfaces, so you can
| just implement the interfaces with whatever backend you
| want. For example, the working copy can be described in
| terms of the filesystem (POSIX copy/rename/move files
| around) or in terms of a virtual filesystem (RPC to a
| server that tells you to make path x/y/z look like it did
| at version 123.)
|
| You can absolutely have "cloud commits" like
| Mononoke/Sapling does, and that is a central feature
| desired at Google too, where Martin works. Skip to the end
| of this talk from Git Merge 2024 a few weeks ago, and you
| can see Martin talk about their version of `jj` used at
| Google, that interacts with Piper/CitC:
| https://www.youtube.com/watch?v=LV0JzI8IcCY
|
| My understanding is that the design works something like
| this (no promises but we may approximate something like
| this in JJ itself): A central server (Piper) stores all the
| data. A local pair of daemons runs on your machine: a proxy
| daemon that talks with the server on your behalf (is used
| to reduce RPC latency for e.g. commits and writes, and does
| asynchronous upload) and a virtual filesystem daemon
| (CitC). The virtual filesystem daemon manages your working
| copy. It "mounts" the repository at version 123 (the
| "baseline version") onto a filesystem directory, by talking
| to the server. Then it tracks changes to the directory as
| you update files; sort of like OverlayFS does for Docker.
|
| When you make a commit, tell the VFS layer to snapshot the
| changes between your working copy and the baseline,
| uploading them to the server. Then tell the backend that
| you've created version 14 out of those files/blobs. The new
| version 124 is now your new baseline. Rinse and repeat to
| create version 125, 126, etc...
|
| The TL;DR on that is the VFS layer manages the working
| copy. The server/proxy manage interaction with a backend.
|
| OK, monorepo export of subprojects. For the purposes of
| exporting monorepo subfolders, I'm actively exploring and
| thinking about "filtering" tools that can be applied to a
| commit graph to produce a new commit graph. Mononoke at
| Meta can do something like this. Check out this tool Josh
| that does it for native Git repositories: https://josh-
| project.github.io/josh/reference/filters.html
|
| The idea is let's say you have commits A -> B -> C and you
| want to export a repository that only contains a project
| you want to export, located under paths path/to/oss/thing.
| You basically sweep the commit graph and only retain
| commits that touch path/to/oss/thing. If a commit does not
| touch this path, remove it from the graph and "stitch" the
| graph back together. If a commit _does_ touch this path,
| then keep it.
|
| If a commit touches that path _and_ other paths that don 't
| match, then create a new commit that only touches files
| under that path. In other words, you might derive a new
| commit graph A' -> C' where B was thrown away because it
| touched private code, and A' and C' are "filtered" versions
| of the originals that retain a subset of their changes. The
| secret is that this algorithm can be fully deterministic,
| assuming the input commit graph is "immutable" and cannot
| be changed.
|
| This idea actually is kind of like applying a MATERIALIZED
| VIEW to a database. In fact it could actually be a kind of
| continuous materialized view where a new derived graph is
| computed incrementally and automatically. But how do you
| express the filters? The underlying filter is really a way
| of expressing a functional map between graphs. So should
| filters only be bijective? What if they're injective? Etc.
| I haven't fully figured this out.
|
| So anyway, I've never really worked in gamedev or huge
| monorepo orgs before, but these are all problems I've
| acutely felt, and Git never really solved. So, I can say
| that yes, we are at least thinking about these things and
| more.
| forrestthewoods wrote:
| > whenever you actually have conflicts arising regularly.
|
| I mean I work at Meta. We have lots of people working on
| stuff at the same time. :) AraxisMerge auto-merges quite
| nicely. Text conflicts have just never been a meaningful
| issue for me in my 15+ year career.
|
| Now binary conflicts are a source of pain! Unfortunately
| require Perforce style file-locking once you hit a team
| size.
|
| > I've never really worked in gamedev or huge monorepo
| orgs before, but these are all problems I've acutely
| felt, and Git never really solved. So, I can say that
| yes, we are at least thinking about these things and
| more.
|
| Good to hear! Yeah the workflow for subproject syncing
| it's super obvious. It definitely can be done but will
| require a lot of thinking and a few iterations.
| martinvonz wrote:
| > JJ's conflict handling seems nice. Can't say that it's a
| big enough problem for me to qualify as a "major feature",
| but a seemingly nice improvement.
|
| The advantages people first think of when they hear about
| jj's conflict handling are usually that you can collaborate
| on conflicts and that you can leave conflicts for later.
| What's less obvious [1] is that being able to store
| conflicts in commits means that we can always rebase
| descendants, so there are states like what Mercurial (and
| Sapling, I think) call "obsolete" and "orphan". There is
| also no "interrupted rebase" state when you're resolving
| conflicts.
|
| These things simplify for the user. They also simplify a
| lot for developers. An example is how I spent about 2 weeks
| on a `hg amend --into` command for amending the changes in
| the working copy into an ancestor. I then implemented that
| in under an hour in jj. Much of the complexity in hg
| stemmed from dealing with the interrupted states while
| dealing with conflicts. (Other complexity in hg that jj
| doesn't have is dealing with a dirty working copy, dealing
| with concurrent operations, and simply complexity in the
| APIs for creating new commits in memory.)
|
| [1] IIRC, it took me about a year after I added support for
| "first-class conflicts" until I figured out that it meant
| that we should simply always rebase descendants. Jujutsu
| had a orphans and a `jj evolve` command before then.
| thih9 wrote:
| 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, without anyone else you're working with to convert too.
___________________________________________________________________
(page generated 2024-10-19 23:01 UTC)