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

71–80 of 269 posts

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

#71

Post by nordsieck »

apeescape wrote: post #34
dagurp wrote: post #11

Earlier quoted context omitted.

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

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

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

#72

Post by masukomi »

RHSeeger wrote: post #66
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'm of the same opinion as you, here. I generally have 10+ "extra" files in my project directory (output files, notes, one-off scripts for certain things, etc). When I add files to a commit, I do it by filename, never "everything that's new/changed". I don't have a use case for "everything I've created/changed goes into the commit, always". > switch to another branch, the files will still be in your working copy but…

i always have a large pile of temp files and such that should never be committed but it's never been a problem because i never use `git add .` i use `git add -u` which is "only add things that are already being tracked"

there's a newer flag for the same thing but my brain is hardcoded to the old "-u" option from "back in the day". It feels like a "simple, out of the box way to do it" to me.

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

#73

Post by scq »

psd1 wrote: post #48

The tool looks great; I have a hurdle to overcome with the name. I'm long accustomed to spelling it, in English, as Jujitsu. I've also seen Jiu-jitsu. "jutsu" is much less common, IME. Is there such thing as canonical Romanisation of Nipponese? I can deal with a project being "wrong" better than not knowing which of us is wrong.

There are multiple romanisation systems for Japanese, but the most common one is Hepburn. In Japan, Kunrei-shiki is sometimes used (especially by the government), which is designed with Japanese speakers in mind (vs Hepburn which was designed with English speakers in mind).

It's jujutsu in both, but there are varying ways of representing the long vowel on the first "u" -- either omitting it (jujutsu), using a macron or circumflex (jūjutsu), or repeating the vowel (juujutsu).

Ju-jitsu and jiu-jitsu are not correct in any romanisation system that I know of, I'm not really sure how they came about. Probably historical accident.

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

#74

Post by mattmanser »

masukomi wrote: post #69
jstanley wrote: post #40

Earlier quoted context omitted.

> In git you would always leave the changes unstaged I do this too, but I quite frequently forget that I've done it and "git commit -am" and end up pushing my private changes anyway.

tell git to treat it as if it's unchanged i have these 2 aliases assume = update-index --skip-worktree unassume = update-index --no-skip-worktree "assume" as in "assume it's unchanged / not wanted" which lets me say "git assume path/to/file" and then "unassume" it when/if i want to commit it.

Someone else's warning to not do this:

https://news.ycombinator.com/item?id=36954723

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

#75

Post by vdfs »

RHSeeger wrote: post #66
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'm of the same opinion as you, here. I generally have 10+ "extra" files in my project directory (output files, notes, one-off scripts for certain things, etc). When I add files to a commit, I do it by filename, never "everything that's new/changed". I don't have a use case for "everything I've created/changed goes into the commit, always". > switch to another branch, the files will still be in your working copy but…

There actually a local .gitignore, it's called or located at .git/info/exclude

You can even ignoring changes in files that are already tracked with `git update-index --assume-unchanged `

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

#76

Post by ephaeton »

cannam wrote: post #64
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…

> It's nice this works fine on your white-on-black terminal I was curious about this as well, as I found the images in the README a bit hard to read. In fact the program itself seems to use quite sensible colours in my white-background terminal, and it also respects the NO_COLOR environment variable.

I often use 5%-black-on-90%-white (and vice versa) and various colored setups that bear semantics to me (like work context, for example, authenticated user, preferred REPL, ...) and as soon as you leave a monochrome world, those colors tend to break down completely.

But, TIL about NO_COLOR!

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

#77

Post by vdfs »

masukomi wrote: post #72
RHSeeger wrote: post #66

Earlier quoted context omitted.

I'm of the same opinion as you, here. I generally have 10+ "extra" files in my project directory (output files, notes, one-off scripts for certain things, etc). When I add files to a commit, I do it by filename, never "everything that's new/changed". I don't have a use case for "everything I've created/changed goes into the commit, always". > switch to another branch, the files will still be in your working copy but…

i always have a large pile of temp files and such that should never be committed but it's never been a problem because i never use `git add .` i use `git add -u` which is "only add things that are already being tracked" there's a newer flag for the same thing but my brain is hardcoded to the old "-u" option from "back in the day". It feels like a "simple, out of the box way to do it" to me.

Add those files to `.git/info/exclude` and they won't show up in `git status`

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

#78

Post by arp242 »

RHSeeger wrote: post #66
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'm of the same opinion as you, here. I generally have 10+ "extra" files in my project directory (output files, notes, one-off scripts for certain things, etc). When I add files to a commit, I do it by filename, never "everything that's new/changed". I don't have a use case for "everything I've created/changed goes into the commit, always". > switch to another branch, the files will still be in your working copy but…

> There should be a .local.gitignore to somesuch

I think .git/info/exclude is what you're looking for? (and also the global ~/.config/git/ignore)

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

#79

Post by josephg »

masukomi wrote: post #72
RHSeeger wrote: post #66

Earlier quoted context omitted.

I'm of the same opinion as you, here. I generally have 10+ "extra" files in my project directory (output files, notes, one-off scripts for certain things, etc). When I add files to a commit, I do it by filename, never "everything that's new/changed". I don't have a use case for "everything I've created/changed goes into the commit, always". > switch to another branch, the files will still be in your working copy but…

i always have a large pile of temp files and such that should never be committed but it's never been a problem because i never use `git add .` i use `git add -u` which is "only add things that are already being tracked" there's a newer flag for the same thing but my brain is hardcoded to the old "-u" option from "back in the day". It feels like a "simple, out of the box way to do it" to me.

I do the same, but in all the mess that git status outputs, I occasionally forget to git add some required source code - which leaves entire chains of commits in my repository in a broken, impossible to compile or run state. Worse, I don’t notice until I try to run the code on another computer - and find I’m missing data.

Having a “local gitignore” makes a lot more sense. I’d like to be more explicit about which local files should be ignored.

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

#80

Post by sanderjd »

Groxx wrote: post #60
bmacho wrote: post #57

Earlier quoted context omitted.

Why wouldn't it work? You gitignore that file, and your modification is ignored, even if it is committed? Or will git delete that file from everyone?

gitignores are usually committed (they're treated like a normal file), so yes, in this context that would delete it from everyone. There's .git/info/exclude, but that has some kinda large surprises if it excludes a tracked file and I don't recommend anyone use it unless they know what to look for and can always remember what they've excluded.

I have a $HOME/.gitignore that I use for this. (You can configure git to use that globally.) It's not a panacea, and I think other commenters are right that you should instead endeavor to organize things so that the project's own gitignore results in a sane workflow. But I think having permanently unstaged changes is worse.
Post reply on HN