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

131–140 of 269 posts

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

#131

Post by Double_a_92 »

calvinmorrison wrote: post #124
9dev wrote: post #120

I haven't really used git on the command line for years now, except for some special cases. In my daily usage, I rely on the built-in IDE integration (IntelliJ, FWIW), and I don't understand why anyone would put up with doing it manually. I can do partial commits by selecting individual lines right in my editor. I can view all branches, merge them, cherry-pick from them, commit stuff or amend it, pull updates, edit t…

Because I have two types of people who understand git on my team. People who use the CLI and people who don't understand git and just start clicking buttons

You forgot the people that only know: git commit -a -m "foobar" and think that's better than using a GUI to easily make clean commits.

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

#132

Post by calvinmorrison »

Double_a_92 wrote: post #131
calvinmorrison wrote: post #124

Earlier quoted context omitted.

Because I have two types of people who understand git on my team. People who use the CLI and people who don't understand git and just start clicking buttons

You forgot the people that only know: git commit -a -m "foobar" and think that's better than using a GUI to easily make clean commits.

If I could enforce one thing, it would be to REQUIRE partial commits for everything from an UI. I can't tell you the amount of commits I have seen that need to be cleaned up from spare debugging statements to vendor files to things that need to be added into the git ignore.

The other thing would be to make sure people understand what things like 'squash' and 'rebase' to and how they effect the tree.

Also to explain if you have multiple features, please don't work on it all on the same branch unless you have too. (This is a internal workflow, not really related to git but how we handle merges)...

Yeah, a UI could be just fine for an experienced git user. In my experience though, experienced git users don't use it though, so it's a moot point.

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

#133

Post by 9dev »

BaseballPhysics wrote: post #125
9dev wrote: post #120

I haven't really used git on the command line for years now, except for some special cases. In my daily usage, I rely on the built-in IDE integration (IntelliJ, FWIW), and I don't understand why anyone would put up with doing it manually. I can do partial commits by selecting individual lines right in my editor. I can view all branches, merge them, cherry-pick from them, commit stuff or amend it, pull updates, edit t…

Because I have always and will always prefer to interact with my VCS on the command-line. The skillset is portable across environments (I can remote into a box and look at a repo as easily as I can interact with one locally), across editors (I don't have to learn and re-learn how each editor interacts with the VCS), and I can use all my familiar tools to work with it. As for those workflow examples, I can just as eas…

It's not that it's hard to believe, I've seen enough discussion on this very topic to know many people (at least on HN) seem to prefer the CLI for VCS interaction.

I'm merely wondering why people seem to prefer a lower-level, separate tool to a higher-level, integrated one. To me it seems similar to writing your Makefile by hand vs. using automake.

The same as you, I don't want to dismiss anyone's tooling. Just curious :-)

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

#135

Post by dicytea »

nordsieck wrote: post #71
apeescape wrote: post #34

Earlier quoted context omitted.

Did you know that the English way to pronounce "jujutsu" isn't how the Japanese pronounce it? The Japanese way to pronounce it could actually be a lot easier for many non-English speakers (I'd anyway argue it's a common enough word that people are familiar enough with it to pronounce it in a way that's comfortable to them).

> Did you know that the English way to pronounce "jujutsu" isn't how the Japanese pronounce it? Really? The wiki audio sample[1] seems fairly close to how people in the US pronounce the word, just with a more emphasized first syllable. --- 1. https://upload.wikimedia.org/wikipedia/commons/f/f1/Ja-Jujut...

That's funny, I thought the name means 呪術, but the person in that audio clip is (probably) pronouncing 柔術. I prefer my interpretation though (git with magic).

Ambiguous romanization is weird, I wish romanization rules would just follow IME rules (except in the case of consecutive n's, that'd look weird).

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

#136

Post by _huayra_ »

calvinmorrison wrote: post #124
9dev wrote: post #120

I haven't really used git on the command line for years now, except for some special cases. In my daily usage, I rely on the built-in IDE integration (IntelliJ, FWIW), and I don't understand why anyone would put up with doing it manually. I can do partial commits by selecting individual lines right in my editor. I can view all branches, merge them, cherry-pick from them, commit stuff or amend it, pull updates, edit t…

Because I have two types of people who understand git on my team. People who use the CLI and people who don't understand git and just start clicking buttons

I was annoyed by a lack of support for git worktrees in my current employer's dependency system (think virtualenv from python, but for everything). I fixed some scripts to be worktree dependent and tested it out thoroughly on the CLI, but as soon as I got the PR through with the change, I got a bazillion messages on Teams from people yelling at me that I broke their workflow.

Their workflow was basically "blindly point and click in Visual Studio because I don't understand even the basics of git. I miss the old custom in-house VCS and am very grumpy".

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

#137

Post by codexb »

9dev wrote: post #120

I haven't really used git on the command line for years now, except for some special cases. In my daily usage, I rely on the built-in IDE integration (IntelliJ, FWIW), and I don't understand why anyone would put up with doing it manually. I can do partial commits by selecting individual lines right in my editor. I can view all branches, merge them, cherry-pick from them, commit stuff or amend it, pull updates, edit t…

My experience with IDE integration is that it never implements the full feature set of the git CLI. It's probably improved, but I've generally found that anything besides basic clone/branch/commit/merge with very few developers and branches eventually leads to having to resort to the git CLI to resolve issues.

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

#138

Post by systems »

OJFord wrote: post #86
k__ wrote: post #42

Do I understand this correctly? This is some kind of background process that automatically commits any changes you make. You can use the CLI to check what it did and if you want to modify the auto commits.

No daemon, it happens 'whenever you run a command'. > Commands snapshot the working copy before they start, then the update the repo, and then the working copy is updated (if the working-copy commit was modified). Almost all commands (even checkout!) operate on the commits in the repo, leaving the common functionality of snapshotting and updating of the working copy to centralized code.

so commit is a side effect, not an explicit action

weird choice, isnt explicit always better than implicit

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

#139

Post by pbronez »

chaxor wrote: post #129
ocharles wrote: post #22

Nice to see this posted here. I switched over to it about 2-3 weeks ago, and I haven't looked back. It took a lot of mental rewiring, but I really enjoy the workflow `jj` provides. There's no longer a time to think about what's being committed, because all file changes automatically amend the working copy commit. Of course, sometimes you don't want this, so you have things like the ability to split a commit into two,…

Are you simply using it with GitHub repos? It mentions that it can be used with backends like Dropbox, but it would be wonderful if we finally had a system that could easily be used with IPFS. This is especially important for large data, since you can't store 1TB on github (and no, I don't count lfs, since you have to pay for it). IPFS is the natural solution here, since everyone that wants to use the dataset has it…

In the author’s presentation [0], the Google roadmap includes “custom working copy implementation for our internal distributed VFS”. The related graphic shows a “working copy” block connected to a “distributed file system block”.

This work might be extensible to include IPFS and other distributed virtual file systems.

[0] https://docs.google.com/presentation/d/1F8j9_UOOSGUN9MvHxPZX...

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

#140

Post by ranting-moth »

sanderjd wrote: post #101
awestroke wrote: post #28

"working copy is automatically committed" seems like a good idea at first glance, but there are many situations where this is not a good idea: - when new artefact files are added and you have not yet added them to .gitignore, they'll be automatically committed - when you have added ignored files in one branch and switch to another branch, the files will still be in your working copy but not listed in your .gitignore…

> - staging only some files and comitting is much easier than splitting a commit after the fact I see this project as a challenge to that conventional wisdom. This view is certainly the one I have embedded in my mind. But is it right? I end up fixing up the index and amending commits post facto quite often. I can also do it pre facto. But in a world where you can't fully avoid editing after the fact, mightn't it be b…

I agree. We've gotten used to pick what should go into the commit after we've done the work.

There's a very serious and glaring error in doing that if you don't commit everything. When someone checks out your commit in a clean repo, his codebase is in a state that has never existed before, not even on your computer.

Some people (I think we've all done it at least once) split their work into multiple commits after a few days of hacking. Like "Adding data services for X", "UI features for X". This is a bad example, but you get the point.

Normally this doesn't cause a problem since all commits get pushed at the same time. But it can easily break things like git-bisect (which is just an amazing tool for finding astonishing bugs).

Post reply on HN