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

161–170 of 269 posts

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

#161

Post by postmodest »

jayd16 wrote: post #156
KolmogorovComp wrote: post #38

Earlier quoted context omitted.

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…

Git should really steal the only thing I like about perforce, many uncommited change lists. It should be an easy workflow change to add 'named stages' along side the default stage. That way you can just leave changes in a different stage, tracked but uncommitted.

Is that different to git stash?

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

#162

Post by pulse7 »

bastardoperator wrote: post #147
chaxor wrote: post #129

Earlier quoted context omitted.

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…

If you're storing 1TB of binary files in git, you're just doing it wrong anyways. You have a bunch of other tools and capabilities for doing this in a way that doesn't make your repository nightmarishly stupid to deal with because of its size.

One can still use Subversion to store binary files in VCS...

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

#163

Post by josephg »

dogleash wrote: post #111
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…

> Ideally I’d like tools like git to eventually be replaced by CRDT based approaches. CRDTs would let us use the same tools to do pair programming. CRDTs also handle complex merges better (no self-conflicts like you can get with git). And they’re generally a more powerful model. I'd be interested to see how this plays out in practice. It seems to be in conflict with the idea that scm history is a meaningful deliverab…

I’ve thought a lot about that. Personally, I think it’s silly that people try to use git’s history for two different purposes:

1. An audit log of what actually happened, and when

2. A curated story of features added and changed

I don’t think git can be both of those things at the same time already. And we see this tension play out when people argue about squishing commits and rebasing before merging.

Personally I think both pieces of information have value. And they should be managed separately - as different features. Eg Git could (and perhaps should) have a second semantic layer which marks a set of commits (atomic history of changes) as semantically associated with a particular feature or issue. This is how I imagine a crdt based scm working: the history of all changes is stored immutably, and synchronised. And change sets can be grouped and marked as “this set of changes is associated with feature XXX”, to make it easier to understand the intent behind code, and roll back specific change sets.

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

#164

Post by josephg »

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.

Pijul is interesting, but my understanding is that it still operates on lines, and does diffs when you push the commit button. And that makes it not work well for real-time collaborative editing. Ideally I’d like a tool that can span both the real-time collaborative editing and offline collaboration use cases. But it’s a very interesting tool, and I’d like to have another read through the docs at some point. I remember being very impressed with it when I took a look a few years ago.

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

#165

Post by aseipp »

proto_lambda wrote: post #50

This looks really cool, I'll try it out on some of my repos to get a feel for it. Too bad support/discussion happens entirely on Discord.

Realistically, Jujutsu is a pretty new project and there are many features to add and lots and lots of code that needs to be written. There is a lot of talking that needs to happen, in other words. So, most of the developers and committers actively hang out and discuss things in Discord, yes, because it's convenient, and fast, and allows all the interested parties to be alerted. I say this as someone who started hacking/working on Jujutsu recently; having Discord has been nice for such a new project.

The reality is that the project is in a part of its life where active discussion and feedback with the userbase is pretty valuable. So, you just go where the users are, and Discord is a big place for that.

GitHub Issues and GitHub Discussions are also actively used by a lot of people, and you can just post things there. Every major committer watches those venues as well, AFAIK, I know my notifications are set up for it.

Over time, assuming things are wildly successful, you'd probably have a lot of different venues to discuss things. I would view Discord mostly in the context of a new project that wants feedback, in that regard.

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

#166

Post by ocharles »

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…

Yea, just GitHub repos. In fact just a single repo (work's mono repo) for now, but that's where I spend the majority of my day.

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

#167

Post by Manjuuu »

arxanas wrote: post #150
Manjuuu wrote: post #146

Earlier quoted context omitted.

> You would expect the push to fail in the normal way, as if you had manually done the rebase, because your commit history may have diverged. That being said, I don't think this happens much in practice: the automatic rebases are typically for explicit history-rewriting operations that users tend to only do on their local work. If a user prefers to use a "no-rewriting" workflow, then they can certainly do so by simpl…

> jj merge exists but it's not obvious which revisions you are supposed to pass to it I don't think I understand your confusion. `jj merge` is essentially like Git merge, except that you also normally pass the current commit as one of the revisions. For example, you could write `jj merge @ main` to make a merge commit with the working copy[1] and the `main` branch. Feel free to open a GitHub discussion or drop by the…

Thanks for the detailed answer.

> For example, you could write `jj merge @ main` to make a merge commit with the working copy[1] and the `main` branch.

Since it's my first time seeing this, the syntax is a bit confusing, the man says "Unlike most other VCSs, `jj merge` does not implicitly include the working copy revision's parent as one of the parents of the merge; you need to explicitly list all revisions that should become parents of the merge.", it's not clear to me if the order matters and how many can be listed (and why for more than 2). What I wanted to replicate was just doing a "git co main; git merge feature-branch", thanks for the explanation.

> git log`/`jj log` are non-mutating operations, so why would you expect that they can update `HEAD`/branches?

What I meant was that with git status/log the differences between your local clone and the remote are clearly shown, you know if they are misaligned and see the last commit for each branch without using additional commands, jj log/st provide way less info. I see where "main" is in jj log but have no idea if that label will update after a push or a fetch of the remote. Just a bit confusing for newcomers, I have to play with it.

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

#168

Post by ocharles »

rkangel wrote: post #155
Certhas wrote: post #97

Earlier quoted context omitted.

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…

I almost always do "git add -p", "git commit". "add -p" is great for showing you all the chunks of code you've written one-by-one and then you do "y" or "n" for whether you're adding them. Doing it like this means that you are reviewing what you've changed as a final check that you haven't left a debug line in, or forgotten part of what you meant to do. It's also a natural way of splitting up what you've done into tw…

The analogous command here is `jj split -i`, which interactively splits the current commit (which is your working copy).

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

#170

Post by theLiminator »

motoboi wrote: post #160
chaxor wrote: post #129

Earlier quoted context omitted.

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…

Why do you want such big files in a git repo?

How about why not? The only reason it's not done is because git doesn't support it.
Post reply on HN