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

91–100 of 269 posts

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

#91

Post by rslabbert »

ephaeton wrote: post #52

my initial reaction, half OT: Ooof, random "ASCII" (actually: Unicode) art & dev-chosen colors, my bane of the "modern" CLI applications. That drawing you like? Doesn't work for me, give me the raw output please. Those colors you love? Aside of red-green weakness being the most dominant factor, what you're really doing is trying to set things apart, connotating color with semantics as well. It's nice this works fine…

All the colours can be adjusted or turned off entirely in the config. [1] A number of different graph styles are supported [2], and failing that, you can completely customise the output template [3]

$XDG_CONFIG_HOME/jj/config.toml is supported, that's where I keep mine.

The working copy is updated whenever you run jj by default, but watchman is also supported (recently added). [4]

In my experience, the command to fix the stale workspaces only needs to be run in exceptional cases where a bug got triggered and a command failed to complete or if you're doing manual poking around.

It's a mindset shift, but it's well worth it in my opinion.

[1] https://github.com/martinvonz/jj/blob/main/docs/config.md#ui... [2] https://github.com/martinvonz/jj/blob/main/docs/config.md#gr... [3] https://github.com/martinvonz/jj/blob/main/docs/templates.md [4] https://github.com/martinvonz/jj/blob/main/docs/config.md#fi...

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

#92

Post by tom-dixon »

Certhas wrote: post #32
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…

I don't see how these things are an issue in jjs design, nor do I see how staging some files is easier than splitting a commit after the fact... Check out the documentation, many of the cases you are concerned about are explicitly mentioned: https://github.com/martinvonz/jj/blob/main/docs/git-comparis...

Constantly having to split after the auto-commits feels like I have to keep fighting this automated commit system. It's a bit like the autosave feature of text editors, which some people find useful, but I never felt like it's needed.

A big downside I can see is that sensitive information might end up in the repo forever because I forgot to revert the auto commit.

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

#93

Post by rslabbert »

e12e wrote: post #41

Looks interesting. Unfortunately doesn't support signing commits - apparently it's possible via "jj export" and using classical git: https://github.com/martinvonz/jj/issues/58#issuecomment-1247...

The plan for how the add signed commits is there, and the work isn't that hard (especially as gitoxide continues to add functionality), it just has to be pushed over the line and I've been a bit slack on getting that going.

There's definitely nothing foundational blocking it though and it will happen one day if you'd like to give it a go in the meantime.

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

#94

Post by OJFord »

I'm semi-sold on the idea of everything always being a commit, and lighter weight editing of those commits & structure, it sounds good. Except:

1. Not until I run some jj command? It's kind of begging for a 'jjd' isn't it? Or if you use an IDE you'd want/need it to be not just saving but doing some kind of 'jj nop'.

2. I haven't looked more into it than the readme, but that at least doesn't discuss (and I think it's important) withholding commits from the remote(s)? If everything's always(ish) committed, I've lost some control of untracked files or unstaged or locally stashed changes that I now need at the point of pushing; to mark those commits 'private' or something. I assume it does exist, and I'll look for it when I make time to play with it, but I find it slightly concerning (for how good it will be, or how important it's considered to be) that it's not more prominently discussed.

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

#95

Post by avgcorrection »

hosh wrote: post #21
dagurp wrote: post #11

Earlier quoted context omitted.

It's a horrible name to pronounce for many non-English speakers.

Ironic because it’s a Japanese name, not English. According to the readme, “jj” was chosen because it was easy to type, and a name was found to fit that.

[flagged]

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

#96

Post by [deleted] »

zelphirkalt wrote: post #5

I would say "What a weird name for a VCS. Whether that will work ...", but then I have to remind myself of the dictionary meaning of "git". So who knows. Maybe we will be adopting all kinds of martial arts terminology. For example: "I use Karate to manage my code. I divide everything using chops. When a kata is done, ..."

[deleted]

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

#97

Post by Certhas »

KolmogorovComp wrote: post #38
Certhas wrote: post #31

Earlier quoted context omitted.

Isn't the idea that you continue editing the working copy commit until you actually commit it? Also from the documentation: https://github.com/martinvonz/jj/blob/main/docs/git-comparis... "As a Git power-user, you may think that you need the power of the index to commit only part of the working copy. However, Jujutsu provides commands for more directly achieving most use cases you're used to using Git's index for. Fo…

Sometimes you have changes that are permanent to your repo (ie local workflow), that you always want to keep locally, but never push to the remote. In git you would always leave the changes unstage, does that mean with jj you would always have to remove them before pushing? I haven’t found an answer on the linked page. Side note: I really wish git had a way to mark commit has ‘no-push’ so they never leave your local…

So in your workflow you never "git commit -a"? So you have to always manually mark what you stage. Which is probably more work than always manually removing the changes you don't want to commit.

The ability to rewrite older commits easily in jj also looks like it would help with this usecase if you get it wrong once.

Concretely I think you would do is: Instead of staging part of your changes and then committing as in git, you would call jj split and split the commit into the part you want to keep local and the part you want to push. This way the local changes always stay in your working copy commit.

Even better, just commit the local changes once when you start. Work locally and before you push you call jj diffedit on your initial commit of the local changes and remove them. Now all the work you did since then will be automatically rebased on the edited initial commit and you can now push up. Instead of excluding your local edits every single time you just have to do it once before pushing.

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

#100

Post by ChadNauseam »

josephg wrote: post #84

> If an operation results in conflicts, information about those conflicts will be recorded in the commit(s). The operation will succeed. You can then resolve the conflicts later. I’m really glad people are trying this out. I’ve spent the last decade or so playing with collaborative editing algorithms. Ideally I’d like tools like git to eventually be replaced by CRDT based approaches. CRDTs would let us use the same t…

You should check out Pijul, as it essentially implements everything you mentioned here. Pijul works on patches which are CRDTs, it makes conflicts a first-class concept, etc.
Post reply on HN