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

151–160 of 233 posts

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

#151

Post by skissane »

sdesol wrote: post #149
skissane wrote: post #142

Earlier quoted context omitted.

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

I do agree that renaming/moving files isn't great but I guess that is one of the downsides of having a distributed version control system. With Subversion, ClearCase, and others, they were centralized and very much meta-data driven. I'm not quite sure why Linus decided not to make renames/moves/copies explicit/strict and my only guess is it simplified things. Being able to say with 100% certainty all the time that so…

> I do agree that renaming/moving files isn't great but I guess that is one of the downsides of having a distributed version control system. With Subversion, ClearCase, and others, they were centralized and very much meta-data driven.

I don't think it has anything to do with the fact that Git is distributed. It is a question of how rich the repository data model is. The richness of the repository data model is an orthogonal concern from distributed-vs-centralised.

I think Linus just wanted to keep it as simple as possible – but, maybe in some areas he made it too simple. The Subversion developers on the contrary, maybe went too far in the other direction.

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

#152

Post by sdesol »

skissane wrote: post #151
sdesol wrote: post #149

Earlier quoted context omitted.

I do agree that renaming/moving files isn't great but I guess that is one of the downsides of having a distributed version control system. With Subversion, ClearCase, and others, they were centralized and very much meta-data driven. I'm not quite sure why Linus decided not to make renames/moves/copies explicit/strict and my only guess is it simplified things. Being able to say with 100% certainty all the time that so…

> I do agree that renaming/moving files isn't great but I guess that is one of the downsides of having a distributed version control system. With Subversion, ClearCase, and others, they were centralized and very much meta-data driven. I don't think it has anything to do with the fact that Git is distributed. It is a question of how rich the repository data model is. The richness of the repository data model is an ort…

> I don't think it has anything to do with the fact that Git is distributed.

I think it does since meta-data increases merge complexity, which is probably a headache when dealing with a distributed system. With a centralized system, you are basically creating a lock when you do a rename/copy/etc. which doesn't translate well to distributed systems.

With Git as it is currently implemented, you only need to worry about one state which is the tree. With meta-data, the number of states that needs to be tracked can increase significantly.

Having said all of that, I guess it probably wouldn't be too hard to implement a layer on top of Git that ensures every directory has something like a .git.meta file and have hooks that ensures all renames,copies,etc. are recorded in the meta-data file.

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

#154

Post by skissane »

sdesol wrote: post #152
skissane wrote: post #151

Earlier quoted context omitted.

> I do agree that renaming/moving files isn't great but I guess that is one of the downsides of having a distributed version control system. With Subversion, ClearCase, and others, they were centralized and very much meta-data driven. I don't think it has anything to do with the fact that Git is distributed. It is a question of how rich the repository data model is. The richness of the repository data model is an ort…

> I don't think it has anything to do with the fact that Git is distributed. I think it does since meta-data increases merge complexity, which is probably a headache when dealing with a distributed system. With a centralized system, you are basically creating a lock when you do a rename/copy/etc. which doesn't translate well to distributed systems. With Git as it is currently implemented, you only need to worry about…

> I think it does since meta-data increases merge complexity, which is probably a headache when dealing with a distributed system.

I disagree. In Git, merging always happens locally, between two local commits; there is nothing distributed about merging itself.

> With a centralized system, you are basically creating a lock when you do a rename/copy/etc. which doesn't translate well to distributed systems.

I don't think that is really true. If I rename a file in Subversion, that doesn't involve "creating a lock". I rename the file locally (using "svn mv"), Subversion locally remembers I have done it, but doesn't send anything to the server. When I want to commit, it then contacts the server and uploads the commit data, including the rename tracking info. Now, that commit operation takes a write lock on the branch – to prevent any other commit for that branch being processed at the same time – but it is the exact same write lock regardless of whether renames are involved or not. If we take Subversion as an example of a centralised version control system with rename tracking, the rename tracking and the locking are orthogonal. (When I say "locking" here, I mean the internal locks within the Subversion server, not the end-user-visible advisory locks you get with the "svn lock" command–that advisory locking feature is unrelated to the topic of rename tracking.)

Like Git, merging is essentially a local process in Subversion – the client constructs a merge commit, and then sends the completed merge commit to the server. The actual merge, meaning construction of the merge commit contents, always happens on the client side, at least as far as the core Subversion protocol is concerned.

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

#156

Post by shp0ngle »

uses wrote: post #121

Maybe I'm too brainwashed by git, but it seems to me one of its benefits is the way the index works. You're encouraged to be fairly explicit about what you're adding to a commit, which encourages making a nice version history. Why would I want everything I do to automatically be added to a commit by default? Doesn't this encourage me to either put all kinds of unintended, not-ready crap in my commits, or constantly m…

Exactly. Reading the docs makes me feel something is a bit “wrong”.

But I felt like this before when I switched from subversion to git (“why would I download all history, always???”) so, who knows.

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

#157

Post by buck4roo »

alwillis wrote: post #39
martinvonz wrote: post #12

Earlier quoted context omitted.

> You lost me at "free from the index". If you click the link that text points you to (i.e. https://github.com/martinvonz/jj/blob/main/docs/git-comparis... ), there's an explanation there for how to achieve the same workflows. I get that it's different , but I don't think it's worse. I consider myself a (former) git power user (I think I have ~90 patches in Git itself) and I've never missed the index since I switched…

Something that’s backend compatible with Git but uses some of Mercurial’s sensibilities? Sign me up!

https://hg-git.github.io/

Happy user for at least 6 years.

The sanity of Mercurial's UX cannot be overstated.

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

#158

Post by martinvonz »

gmfawcett wrote: post #90
jjthrowaway wrote: post #57

It would be nice if this were in nixpkgs, it's a pain to manage all the different language environments and it would save me from trying to get it to compile. Right now error[E0554]: `#![feature]` may not be used on the stable release channel --> lib/src/lib.rs:15:12 | 15 | #![feature(assert_matches)] |

If you get it working, please share a flake. :)

I filed https://github.com/martinvonz/jj/issues/61 about having Nix packages. I should learn about Nix packaging some day, but I'd appreciate any help I can get.

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

#159

Post by martinvonz »

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…

Yep. Same thing in Jujutsu (the recursive merge is at https://github.com/martinvonz/jj/blob/a6ef792ba66b5b19e75282...). Probably the biggest difference compared Git there is that it'll still work even if there are conflicts.

FYI, this is also how `jj undo` works, except that it's a three-way merge at the repo level (https://github.com/martinvonz/jj/blob/d9b364442e2246a734d600...). So that applies changes to branches, checkouts (think: git HEAD), and sets of anonymous heads. This is how you can undo an operation even if it wasn't the most recent one (just like you can `git revert` a commit that wasn't the most recent one).

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

#160

Post by tragictrash »

hinkley wrote: post #94
swagonomixxx wrote: post #6

> A Git-compatible DVCS that is both simple and powerful We all know the dig here - Git is not simple. Like many tools, Git has evolved significantly over the years. Git today was not like Git 10 years ago. Also, like many replacements to existing tools and software, they always start out simple and beautiful. Then they grow in complexity to serve the domain. The reason Git is complicated - not "simple" - is mostly b…

I am by all accounts the SME on git at my company. I often am the VCS expert at my company. I don't like using tools I don't understand, and my brain is pretty good at handling problems that look like graph theory. After using git for 6 years git still terrifies me. After 9 months of svn I performed open heart surgery to remove a 1GB zip file that some dummy merged before anyone thought to stop him. It was at least 1…

It's not that hard man. Really isn't. Your anecdote sounds like someone who thinks they're awesome at git setting a noob up for failure and then mansplaining when they fuck up.

It's not hard to be better at git than 85% of people, most devs I've met don't understand the basics beyond pull commit push.

Post reply on HN