Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jujutsu at Google [video]

youtube.com

Post reply on HN
Print view View original

181–190 of 212 posts

Re: Jujutsu at Google [video]

#181

Post by 1718627440 »

steveklabnik wrote: post #176
1718627440 wrote: post #167

Earlier quoted context omitted.

Create a bare repo on the USB stick(/dropbox/Google Drive/random folder) and just push to the USB stick.

Historically speaking, this does not change things, at least for Dropbox/Google Drive. Stack Overflow is tons of posts like this: https://stackoverflow.com/questions/2199637/is-it-possible-t... That said, I haven't tried this lately, maybe it's gotten more robust over time. But historically, even a bare repo on something like Dropbox has issues.

Sure, but this seams to be more of an issue with Dropbox, not with Git, when I run a database on Dropbox, the same problems occur. I wouldn't trust these to even preserve file attributes correctly, so I would put things into a tarball, before uploading (optionally also encrypting).

Re: Jujutsu at Google [video]

#182

Post by steveklabnik »

1718627440 wrote: post #179
steveklabnik wrote: post #175

Earlier quoted context omitted.

> The thing to keep in mind is that Git doesn't version the file system, it versions the index. Yes. I think that this difference is what introduces a lot of friction, both in the model, and how people use it. The divergence between the files that exist on disk inside your working copy and what's actually tracked means lots of opportunities for friction that go away once you decide that it should. That doesn't mean t…

> So, one big example is detatched HEADs: any changes you make to those, which still are contents of the repository, are not tracked in the reflog. $ git checkout HEAD $ git commit --allow-empty -m "_" $ git checkout master $ git reflog a91 (HEAD -> master, origin/master, origin/HEAD) HEAD@{0}: checkout: moving from b94 to master b94 HEAD@{1}: commit: _ 28d (origin/feature, feature) HEAD@{2}: checkout: moving from fe…

Oh yeah I forgot HEAD Is a ref, whoops. Duh! (My git is getting rusty at this point...)

jj still ends up keeping information in here that the reflog doesnt, but you're right that these aren't the strongest points.

Re: Jujutsu at Google [video]

#183

Post by steveklabnik »

1718627440 wrote: post #181
steveklabnik wrote: post #176

Earlier quoted context omitted.

Historically speaking, this does not change things, at least for Dropbox/Google Drive. Stack Overflow is tons of posts like this: https://stackoverflow.com/questions/2199637/is-it-possible-t... That said, I haven't tried this lately, maybe it's gotten more robust over time. But historically, even a bare repo on something like Dropbox has issues.

Sure, but this seams to be more of an issue with Dropbox, not with Git, when I run a database on Dropbox, the same problems occur. I wouldn't trust these to even preserve file attributes correctly, so I would put things into a tarball, before uploading (optionally also encrypting).

Sure, you could view it as Drobox's problem, but the core of it is that git relies on things that Dropbox doesn't support, while jj does not. And so it's usable more safely in more contexts.

I fully agree that this is a niche use-case.

Re: Jujutsu at Google [video]

#184

Post by 1718627440 »

martinvonz wrote: post #180
1718627440 wrote: post #178

Earlier quoted context omitted.

1. Edit changes, run `git commit --fixup=A`. 2. Edit changes for D. Also edit changes for B. Interactively `git add` changes for B. `git commit --fixup=B`. 3. Finish changes for D, then call git commit --fixup=D Before push I run `git rebase --autosquash`, optionally `git rebase --exec='make check'` to rerun all the tests on the changed commits. Where is that "much harder"?

Ah, I see, so you avoid interactive rebase and instead make all changes in the working copy and use `git commit --fixup` and `git rebase --autosquash` . Makes sense, but doesn't it break down when there are conflicts between the changes you're making in the working copy and the target commit? How do you adjust the steps if there were conflicts between the changes we wanted to make to A and the changes already present…

> Ah, I see, so you avoid interactive rebase and instead make all changes in the working copy and use `git commit --fixup` and `git rebase -i .

I wouldn't say I avoid this, I also run `git rebase -i` several times per day, and I also often use `git commit --fixup` during a rebase.

> Makes sense, but doesn't it break down when there are conflicts between the changes you're making in the working copy and the target commit?

Yes, but wouldn't this be the same in JJ, when you do your changes on top of A, and later squash them into D? If you don't want to have the changes, you can also checkout D and do the changes there. Then you have two options:

- `git commit --fixup`, later do `git rebase`

- `git commit --amend`, and `git rebase --onto`

Most times I do the thing described earlier and just solve the conflicts, because that's just a single command. Also when its only a single case, I use `git stash`. (The workflow then is do random fix, git stash, then figure out where these should go, git rebase)

> How do you adjust the steps if there were conflicts between the changes we wanted to make to A and the changes already present in B?

I just resolve them? I think I don't understand this question.

Re: Jujutsu at Google [video]

#185

Post by 1718627440 »

steveklabnik wrote: post #182
1718627440 wrote: post #179

Earlier quoted context omitted.

> So, one big example is detatched HEADs: any changes you make to those, which still are contents of the repository, are not tracked in the reflog. $ git checkout HEAD $ git commit --allow-empty -m "_" $ git checkout master $ git reflog a91 (HEAD -> master, origin/master, origin/HEAD) HEAD@{0}: checkout: moving from b94 to master b94 HEAD@{1}: commit: _ 28d (origin/feature, feature) HEAD@{2}: checkout: moving from fe…

Oh yeah I forgot HEAD Is a ref, whoops. Duh! (My git is getting rusty at this point...) jj still ends up keeping information in here that the reflog doesnt, but you're right that these aren't the strongest points.

Which, the stuff you said earlier is in the reflog?

I think Git will just gain a oplog. You just need to append a commit hash to a list before each command and implement undo as remove item and checkout. The hardest thing will be race conditions, but Git already knows how to be a database.

Re: Jujutsu at Google [video]

#186

Post by martinvonz »

1718627440 wrote: post #184
martinvonz wrote: post #180

Earlier quoted context omitted.

Ah, I see, so you avoid interactive rebase and instead make all changes in the working copy and use `git commit --fixup` and `git rebase --autosquash` . Makes sense, but doesn't it break down when there are conflicts between the changes you're making in the working copy and the target commit? How do you adjust the steps if there were conflicts between the changes we wanted to make to A and the changes already present…

> Ah, I see, so you avoid interactive rebase and instead make all changes in the working copy and use `git commit --fixup` and `git rebase -i . I wouldn't say I avoid this, I also run `git rebase -i` several times per day, and I also often use `git commit --fixup` during a rebase. > Makes sense, but doesn't it break down when there are conflicts between the changes you're making in the working copy and the target com…

> I just resolve them? I think I don't understand this question.

In order to make changes to commit A when there are conflicting changes in B, I was thinking that you would have to use interactive rebase instead because you can no longer make those changes in the working copy and use `git commit --fixup`, right? And because there will now be conflicts in commit B, you will be in this "interrupted rebase" state where you have conflicts in the staging area and it's a bit tricky (IMO) to leave those and look around somewhere else and then come back and resolve the conflicts and continue the rebase later.

> Yes, but wouldn't this be the same in JJ, when you do your changes on top of A, and later squash them into D?

The difference is that we don't end up in an interrupted rebase. If we squashed some changes into A and that resulted in conflicts in B, then we would then create a new working-copy commit on top of the conflicted B (I call all of the related commits B even if they've been rewritten - I hope that's not too confusing). We then resolve the conflicts and squash the resolution into B and the resolution gets propagated to the descendants. We are free at any time to check out any other commit etc.; there's no interrupted rebase or unfinished conflicts we need to take care of first. I hope that clarifies.

Re: Jujutsu at Google [video]

#187

Post by 1718627440 »

wbl wrote: post #143
koiueo wrote: post #81

Earlier quoted context omitted.

There are simply people who've rtfm and people who haven't

Quick, what does git pull foo do if foo is a branch vs a remote and how do you fix it if you messed up/which is preferred when both exist?

> if foo is a branch

It does `git pull foo`.

> vs a remote

It gives an error, because you haven't specified the remote.

I don't know what behaviour you find intuitive here?

> how do you fix it if you messed up/which is preferred when both exist?

git pull is YOLO mode, so I never do it, but I would just reset the branches where I want them to be? You get a summary with the old and new commit hashes, so resetting is really easy.

Re: Jujutsu at Google [video]

#188

Post by 1718627440 »

steveklabnik wrote: post #183
1718627440 wrote: post #181

Earlier quoted context omitted.

Sure, but this seams to be more of an issue with Dropbox, not with Git, when I run a database on Dropbox, the same problems occur. I wouldn't trust these to even preserve file attributes correctly, so I would put things into a tarball, before uploading (optionally also encrypting).

Sure, you could view it as Drobox's problem, but the core of it is that git relies on things that Dropbox doesn't support, while jj does not. And so it's usable more safely in more contexts. I fully agree that this is a niche use-case.

JJ works when an internal file is overwritten to another version, while it does an operation? I thought that's what we are discussing here.

Re: Jujutsu at Google [video]

#189

Post by martinvonz »

steveklabnik wrote: post #182
1718627440 wrote: post #179

Earlier quoted context omitted.

> So, one big example is detatched HEADs: any changes you make to those, which still are contents of the repository, are not tracked in the reflog. $ git checkout HEAD $ git commit --allow-empty -m "_" $ git checkout master $ git reflog a91 (HEAD -> master, origin/master, origin/HEAD) HEAD@{0}: checkout: moving from b94 to master b94 HEAD@{1}: commit: _ 28d (origin/feature, feature) HEAD@{2}: checkout: moving from fe…

Oh yeah I forgot HEAD Is a ref, whoops. Duh! (My git is getting rusty at this point...) jj still ends up keeping information in here that the reflog doesnt, but you're right that these aren't the strongest points.

One little benefit of the op log is that you can use a single `jj undo` to undo all the rebased branches/bookmarks in one go. If you have rebased many branches with `git rebase --update-refs`, you need to reset each of the branches separately AFAIK.

Re: Jujutsu at Google [video]

#190

Post by 1718627440 »

Agingcoder wrote: post #111
Y_Y wrote: post #16

Earlier quoted context omitted.

Ugh, I'd prefer people keep passion for the bedroom and just convey information straightforwardly without trying to "sell" it to me. Adding a false excitement signal to the information is a hindrance to me as a viewer. If you want Tony Robbins then go and see him. If you want an overview of the new product architecture lets keep calm and get on with it.

I disagree, but it doesn’t mean you’re wrong - we might just be looking for different things. My view is that if you’re going to talk like a bored robot, then I need a transcript or a paper which is much shorter than a talk. I distinctly remember not going to classes at university because the teachers wouldn’t give me anything beyond reading a book aloud. I just read the book at home. Now, if you’re able to indicate…

That's why it is called a lecture. :-)
Post reply on HN