Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

111–120 of 233 posts

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

#111

Post by kazinator »

mastazi wrote: post #109
kazinator wrote: post #97

In git you can reorder any sequence of commits without any conflicts. Howwever, there is no nice "porcelain" for it. The basis for it is the read-tree command. In git, every commit is a snapshot and not a delta. (Repeat that three times.) Any arbitrary snapshots of files can be arranged into a git history. They don't even have to be related. We could take a tarball of GCC, and make that the first commit. Then a tarba…

> In git, every commit is a snapshot and not a delta. I know this, but also I cannot reconcile this whit what happens when you cherry-pick a commit from another branch. I'm confused because cherry-pick really seems to be taking out the delta not the snapshot. I'm thinking that cherry-pick takes that commit and makes a diff with its parent and then that's what you get when you call it. Is it how it works behind the sc…

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 its parent 0 and then patch it onto your work. In many cases, that wouldn't work because that's not a three-way-merge, but a two-way merge, which has disadvantages.

However: there may be situations when the commits are so distant, it might make sense just to turn that one into a patch and work the patch onto your baseline. Even if that needs manual work, it can be simpler. You will only get conflicts (patch hunk rejects in that case) that are relevant to that change. I've had lots of experience working with patch stacks (both before and after Quilt was introduced to make that a bit easier) so I'm comfortable migrating patches from one code base to another without a three-way-diff process within version control.

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

#112

Post by Hendrikto »

stouset wrote: post #95
skrebbel wrote: post #27

Wow, this scratches a lot of my itches about Git. I teach a Git course at my alma mater, and the things that confuses people the most (the index, how to undo mistakes etc etc) all seem addressed head-on. At first glance, this seems substantially easier to teach than Git. The Git compat seems like a great idea for this to really take off. My team is totally PR based though so if/when doing (Git compatible) feature bra…

While I agree that git could use a rethink from a user tooling perspective, I really appreciate the existence of the index. I’m not tied necessarily to this specific implementation of it, but having a staging area where chunks are added piecemeal is an enormous benefit. I honestly wish git forced `-p` for operations that support it. I’ve worked on too many teams where people would just commit everything in their work…

> I’ve worked on too many teams where people would just commit everything in their working directory, and it would inevitably make reviewing their PRs a nightmare.

And they always claim to review and clean their commits before pushing, or at least before merging, but never do.

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

#113

Post by throw0101a »

pjc50 wrote: post #102
stouset wrote: post #95

Earlier quoted context omitted.

While I agree that git could use a rethink from a user tooling perspective, I really appreciate the existence of the index. I’m not tied necessarily to this specific implementation of it, but having a staging area where chunks are added piecemeal is an enormous benefit. I honestly wish git forced `-p` for operations that support it. I’ve worked on too many teams where people would just commit everything in their work…

> 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…

> It would be quite fun if we could have hierarchical commits, so I could add bits to a commit without having to squash/amend. Then you'd see the top-level work item as a "commit" and the individual changes as "subcommits".

Would something like Mercurial's queues be something what you're looking for?

* https://stevelosh.com/blog/2010/08/a-git-users-guide-to-merc...

See especially "…with Two (or More) Patches" onwards.

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

#114

Post by CGamesPlay »

Interesting ideas! I especially like the automatic rebasing and associated ideas.

It's a bit strange to see "jj st" will automatically add all files to the "working copy" commit. This means that when I initially create my project, run "npm install" to install 500 MB of dependencies, and then run "jj st" to figure out what to include in my first commit, the command is going to copy all of that into a commit object for no reason. I don't think I like that behavior, to be honest. Is this a requirement of any of the other unique features? Could this be turned off, or modified to be an explicit operation?

[append]

To be clear, the fact that it's `jj st` is actually a big part of the problem for me: this is the command I use to figure out what to put into my `.gitignore` in the first place! I don't think that any of the "read-only" commands should be making these kind of changes.

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

#115

Post by giovannibonetti »

> 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".

Yeah, it's just a coincidence that the world Jujutsu means magic in japanese (呪術)

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

#116

Post by andrewshadura »

cryptonector wrote: post #81
throw0101a wrote: post #22

Earlier quoted context omitted.

> 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…

I find Mercurial very difficult to use. I find Git much easier.

It's just because you've been using Git for too long. Mercurial is much easier to use if you're not exposed to Git.

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

#117

Post by andrewshadura »

bonzini wrote: post #11
yjftsjthsd-h wrote: post #7

Earlier quoted context omitted.

If you can rewrite the history that actually got committed, do you really need a temporary pre-commit staging area?

The index is mostly useful to me to split a commit in multiple ones. You do that with a sequence of "git add -p" and "git commit" commands. I am interested in how to do this with jj, because otherwise it looks like a very interesting tool.

Try git-crecord.

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

#118

Post by mastazi »

kazinator wrote: post #111
mastazi wrote: post #109

Earlier quoted context omitted.

> In git, every commit is a snapshot and not a delta. I know this, but also I cannot reconcile this whit what happens when you cherry-pick a commit from another branch. I'm confused because cherry-pick really seems to be taking out the delta not the snapshot. I'm thinking that cherry-pick takes that commit and makes a diff with its parent and then that's what you get when you call it. Is it how it works behind the sc…

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…

Yes, I agree about distant commits and turning it into a patch.

Thank you for explaining the three-way merge between baseline, commit and common ancestor, makes sense.

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

#120

Post by feanaro »

pjc50 wrote: post #102
stouset wrote: post #95

Earlier quoted context omitted.

While I agree that git could use a rethink from a user tooling perspective, I really appreciate the existence of the index. I’m not tied necessarily to this specific implementation of it, but having a staging area where chunks are added piecemeal is an enormous benefit. I honestly wish git forced `-p` for operations that support it. I’ve worked on too many teams where people would just commit everything in their work…

> 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…

> But that's what they've tested.

https://pre-commit.com/ helps with that.

> It would be quite fun if we could have hierarchical commits, so I could add bits to a commit without having to squash/amend.

Yes! I've been saying this for years.

Branch merge commits are already this, kind of. However their UI sucks and there's an idea gap which prevents them from being fully understood as such "supercommits" composed of subcommits.

For one, the user should be forced to give meaningful, high level commit messages for merge commits and the tooling should fold commits made on a merge branch into the merge commit by default (effectively linearizing the merged history).

Post reply on HN