Jujutsu – A Git-compatible DVCS that is both simple and powerful

Post by mastazi » Sun, Feb 20, 2022, 1:33 AM UTC

geofft wrote: post #126

kazinator wrote: post #111

Earlier quoted context omitted.

When you cherry-pick a commit from another branch, it's not doing anything like a read-tree to make your current work look like that commit's snapshot state. It's doing something like three-way merge between that commit, your baseline and a common ancestor (I'm guessing: the same one that would be identified by git merge-base .) That's why cherry-pick identifies conflicts. A cherry-pick deos not just do a diff with i…

It's doing something weirder than that, but "it applies a diff between a specified commit and its parent on top of your current work" is more accurate/intuitive than "it does a three-way merge with a common ancestor". No common ancestor is involved. The first hint that it's doing something interesting is that the implementation of cherry-pick is in revert.c, because it's implemented as a variant of revert: https://gi…

Post by jefftk » Sun, Feb 20, 2022, 1:55 AM UTC

stouset wrote: post #110

pjc50 wrote: post #102

Earlier quoted context omitted.

> just commit everything in their working directory But that's what they've tested. I've had far more problems in the other direction, where the commit doesn't contain the complete set of things that it's supposed to but because all the tooling - every single IDE and compiler - is looking at the working directory not the index, I've missed something. The index is definitely confusing for new users and users of other…

Like I said, I’m not sold on git’s specific implementation. But breaking things into smaller, focused commits is—in my experience—a hallmark of good development practice. There should absolutely be better tooling around it, so that these piecemeal commits can be tested in isolation from one another. That’s a far better approach than just throwing up our hands and committing everything in the working tree, even if hal…

Post by Aeolun » Sun, Feb 20, 2022, 2:09 AM UTC

martinvonz wrote: post #136

Aeolun wrote: post #131

Earlier quoted context omitted.

> git clients won't know what to do with the conflicted files This seems kind of similar to pushing git files with conflicts with the git client? Maybe the Jujutsu formatting is slightly different, but the concept is the same.

These are representations of conflicts that are stored as special files, they are not regular files with conflict markers in. If you look at the commit with regular `git`, you're going to see a weird file with some JSON in it.

Post by alwillis » Sun, Feb 20, 2022, 2:57 AM UTC

throw0101a wrote: post #22

cryptonector wrote: post #5

> It combines features from Git (data model, speed), Mercurial (anonymous branching, simple CLI free from "the index", revsets, powerful history-rewriting), and Pijul/Darcs (first-class conflicts), with features not found in either of them (working-copy-as-a-commit, undo functionality, automatic rebase, safe replication via rsync, Dropbox, or distributed file system). You lost me at "free from the index". The index i…

> You lost me at "free from the index". The index is one of the most important parts of Git that makes my life easier. Opinionated DVCS UIs make my life harder -- all of them. Mercurial has an 'index' / staging area, but not exposed by default. You can access it with some extra CLI options, but there is an optional idea that may be 'better' and worth looking into: > If you need the index, you can gain its behavior (w…

Post by sdesol » Sun, Feb 20, 2022, 3:07 AM UTC

skissane wrote: post #142

freedomben wrote: post #13

Earlier quoted context omitted.

I remember that well too (along with Rational Clearcase), and you may totally be right, but git does feel different because it works so well with all sorts of projects, big and small. There were always operations that required hacks. With git that doesn't feel the case to me,perhaps with one exception (but I don't think this is git's fault as much as it's mine for not knowing git well enough to use the tools it provi…

> There were always operations that required hacks. With git that doesn't feel the case to me,perhaps with one exception I think the way Git handles renames is ugly – it doesn't actually record them, it just tries to guess when they occur based on file contents (inevitably imperfect). I think Subversion handled this better. The problem is that a Git tree object only contains file name, file mode, and blob/subtree has…