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

101–110 of 269 posts

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

#101

Post by sanderjd »

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 better to have a single workflow for this kind of editing? That is, if you can't totally get rid of post facto commit editing (which I think is reality), can you actually get rid of pre facto editing, and be left with just one editing workflow? If so, maybe that's good!

I haven't used this yet, but this strikes me as a very plausible attack on a conventional wisdom that we take for granted but may not actually be doing us any favors.

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

#102

Post by conaclos »

ChadNauseam wrote: post #100
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.

I wonder: Is there a git backend for Pijul?

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

#103

Post by sanderjd »

tom-dixon wrote: post #92
Certhas wrote: post #32

Earlier quoted context omitted.

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.

I always end up reading through my commit diffs while committing and then maybe like a third of the time I edit something about them. So for me this seems like it could be a natural acknowledgement of that; just make that editing after the fact be the primary / only workflow.

Haven't used this yet so no idea if it's actually great or terrible, but I like to see ingrained conventional wisdom challenged like this. We're always in some local maximum, so I think it's often interesting to be pushed in some new direction on the gradient.

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

#105

Post by nickspain »

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…

These might be the clunky way your talking about but you can have “private” git ignored either in ‘.git/info/exclude’ in the repo or in the ‘core.excludesfile’ set in your git config. The later is quite nice because you could actually version control that elsewhere if you version control your system config.

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

#106

Post by Certhas »

tom-dixon wrote: post #92
Certhas wrote: post #32

Earlier quoted context omitted.

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.

I think you are misunderstanding the autocommit, but maybe I am.

I think you don't need to do this after every autocommit but only before the manual ones? Isn't that how amending commits in git works? The unamended commit is no longer around, right?

Also it seems to me that you can rewrite old commits in jj to get rid of accidentally committed information a lot more easily than you can remove it from when you accidentally commit it to git...

Meta comment: Bit frustrating to see so many downvotes in these threads when people are just trying to grok what the jj model means concretely for important workflows.

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

#107

Post by pjc50 »

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…

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

I appreciate that there are times when this has to be in the middle of an otherwise committed file, but it's worth avoiding that if at all possible and putting the locally-changed bit in a different file because, as others have pointed out, this is error prone. It feels like the equivalent of keeping your important files in the recycle bin because it's easily accessible.

For 90% of git users 90% of the time, the staging area is an inconvenience that adds an extra step.

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

#108

Post by Manjuuu »

I've just started looking into this, and since this seems to be doing a few automatic rebases under the hood, I wonder how this behave if commits get randomly pushed to origin. For git is always obvious when you are about to amend/overwrite a pushed HEAD and you can push forcefully only explicitly.

Edit: anonymous branches are destined to be pushed remotely (to be reviewed and merged) and there is no local merge as far as I can tell, you can name these branches but no "merge back to development branch once done". Completely different workflow, having the ability to merge or "collapse" the anonymous branch to its parent would be nice, when you don't really need to push your feature branches anywhere.

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

#109

Post by freeopinion »

OJFord wrote: post #82
scq wrote: post #73

Earlier quoted context omitted.

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…

So is it pronounced like it looks here? I've never seen this spelling before, and IME (and I assume GP's) everyone says 'jew-jit-sue'. But it's more like 'jew-jut-sue' (as in to jut out)?

To use your phonetic spelling juujutsu would be more like jew-jew-tsue, with the first jew being stretched out a little. That is, both ju syllables would be pronounced the same way. The tsu on the end is its own syllable.

Unless we're talking about the English word, which I'm not sure how to pronounce. If we're talking about the American word then it's really just like a lot of other murkin words: butcher it any way you like.

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

#110

Post by systems »

ctafur wrote: post #98

I just find another alternative to Git called Grace. It's made by a Microsoft employee with F#.

I saw the presentation, its about having cloud ready or cloud native scm, i dont think this is a great idea

git is about working locally github (or similar solutions) is the cloud part

cloud native scm sound like a bad idea

Post reply on HN