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 233 posts

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

#101

Post by jomar »

CorrectHorseBat wrote: post #58
halfdan wrote: post #56

Earlier quoted context omitted.

Try using git worktrees: https://geekmonkey.org/rethink-your-git-workflow-with-git-wo...

What is the advantage of using worktrees over another checkout in another folder?

When you're done with a worktree, you just delete it (via `git worktree remove`). Any additional branches or stashes etc are part of the repository that the worktree was part of, and they (of course) remain.

When you're done working in a separately cloned repository in another folder, if you're anything like me, before deleting it (via `rm -rf`) you'll want to check very carefully for additional branches, unpushed work, anything stashed. Deleting an entire repository that's been around for a while is a risky operation in that it may have accumulated other unrelated work in addition to the current branch (which was the primary reason for the clone), and you'll want to check carefully before deleting the whole lot.

Additional worktrees within the same repository are great for medium-term ephemeral separate strands of work. They can be created and removed without concern.

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

#102

Post by pjc50 »

stouset wrote: post #95
skrebbel wrote: post #27

Wow, this scratches a lot of my itches about Git. I teach a Git course at my alma mater, and the things that confuses people the most (the index, how to undo mistakes etc etc) all seem addressed head-on. At first glance, this seems substantially easier to teach than Git. The Git compat seems like a great idea for this to really take off. My team is totally PR based though so if/when doing (Git compatible) feature bra…

While I agree that git could use a rethink from a user tooling perspective, I really appreciate the existence of the index. I’m not tied necessarily to this specific implementation of it, but having a staging area where chunks are added piecemeal is an enormous benefit. I honestly wish git forced `-p` for operations that support it. I’ve worked on too many teams where people would just commit everything in their work…

> just commit everything in their working directory

But that's what they've tested. I've had far more problems in the other direction, where the commit doesn't contain the complete set of things that it's supposed to but because all the tooling - every single IDE and compiler - is looking at the working directory not the index, I've missed something.

The index is definitely confusing for new users and users of other VCS.

> having a staging area where chunks are added piecemeal is an enormous benefit.

It would be quite fun if we could have hierarchical commits, so I could add bits to a commit without having to squash/amend. Then you'd see the top-level work item as a "commit" and the individual changes as "subcommits".

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

#103

Post by martinvonz »

cryptonector wrote: post #79
martinvonz wrote: post #12

Earlier quoted context omitted.

> You lost me at "free from the index". If you click the link that text points you to (i.e. https://github.com/martinvonz/jj/blob/main/docs/git-comparis... ), there's an explanation there for how to achieve the same workflows. I get that it's different , but I don't think it's worse. I consider myself a (former) git power user (I think I have ~90 patches in Git itself) and I've never missed the index since I switched…

You cover `git add -p`, but I want `git add -e`. Also, I often rebase and `edit` commits to split them or undo parts of them. Rebase and all this is all about making commits that have just the right content, and keeping history clean and linear. The tools have to make this possible and easy. I get that git feels... barebones for this. You really have to understand what you're doing when using git like I do, so I get…

> You cover `git add -p`, but I want `git add -e`.

Interesting. I don't think I've heard anyone use `git add -e` before. It should be easy to add that feature, but it would be very low priority since so few users seem to like to manually edit patches.

> Also, I often rebase and `edit` commits to split them or undo parts of them.

You can do that by checking out the commit, then `jj squash/amend` (aliases) and all descendants will be automatically rebased on top, and branches pointing to them will be updated too. There's also `jj edit` for editing the changes in a commit without updating to it. And there's `jj split` for splitting a commit (without needing to update to it).

> Rebase and all this is all about making commits that have just the right content, and keeping history clean and linear. The tools have to make this possible and easy.

Yes, that's definitely a goal. I think Jujutsu does a much better job at that than Git does. Did you read https://github.com/martinvonz/jj#comprehensive-support-for-r...?

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

#104

Post by hpfr »

pjc50 wrote: post #99
halfdan wrote: post #56

Earlier quoted context omitted.

Try using git worktrees: https://geekmonkey.org/rethink-your-git-workflow-with-git-wo...

Surprise limitation: you cannot have two worktrees set to the same branch, or at least that confronted me when I tried it.

Can you elaborate on why you would want two worktrees set to the same branch? I think if I were trying to compare two approaches involving incompatible changes, creating a branch for one approach would feel more natural anyway, and then I'd be able to use the worktrees.

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

#105

Post by netghost »

fsloth wrote: post #75
jeltz wrote: post #40

Earlier quoted context omitted.

I totally agree. Back when I used Subversion it felt to me like there obviously must be a better way to version control and that the tool got in my way all the time. Git on the other hand almost always can solve my problems and while some things could be improved (confusing UX, a bit too complex, plus bad handling of conflicts) it is much closer to the right tool for VCS than Subversion ever was.

What are the problems that Subversion has? My only experience of svn is of simple personal projects and in that scope it worked pretty well - not contesting your opinion, but would like to know at which point svn becomes problematic.

If subversion had branches, they were not nearly as easy to use as in git. It also didn't have a great notion of offline work (to my memory).

For what it's worth, SVN was pretty straightforward and worked well enough at the time. Later, Mercurial addressed SVN's deficiencies with a familiar interface.

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

#108

Post by jomar »

pjc50 wrote: post #99
halfdan wrote: post #56

Earlier quoted context omitted.

Try using git worktrees: https://geekmonkey.org/rethink-your-git-workflow-with-git-wo...

Surprise limitation: you cannot have two worktrees set to the same branch, or at least that confronted me when I tried it.

If you had two worktrees set to the same branch and made a new commit in one of them (thus changing the commit the branch ref points to), what would happen in the other worktree?

Either it wouldn't have the right commit checked out anymore, or git would have to miraculously change what files are checked out in it -- which would likely come as a big surprise to whatever you were doing in that working tree.

Ergo, it is forbidden.

I periodically find myself creating a new (temporary) branch referring to the same commit when I want a new worktree looking at the same place, or just create a new worktree with a detached HEAD looking at the same commit.

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

#109

Post by mastazi »

kazinator wrote: post #97

In git you can reorder any sequence of commits without any conflicts. Howwever, there is no nice "porcelain" for it. The basis for it is the read-tree command. In git, every commit is a snapshot and not a delta. (Repeat that three times.) Any arbitrary snapshots of files can be arranged into a git history. They don't even have to be related. We could take a tarball of GCC, and make that the first commit. Then a tarba…

> In git, every commit is a snapshot and not a delta.

I know this, but also I cannot reconcile this whit what happens when you cherry-pick a commit from another branch. I'm confused because cherry-pick really seems to be taking out the delta not the snapshot.

I'm thinking that cherry-pick takes that commit and makes a diff with its parent and then that's what you get when you call it. Is it how it works behind the scenes?

I'm also thinking that the fact that each commit has at least one parent means that, conceptually, we can use it as if it was a delta (at least in the case of commit with one parent only), if you get what I mean.

EDIT: I'm not familiar with the internals of Git, just a user. Commenting out of curiosity.

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

#110

Post by stouset »

pjc50 wrote: post #102
stouset wrote: post #95

Earlier quoted context omitted.

While I agree that git could use a rethink from a user tooling perspective, I really appreciate the existence of the index. I’m not tied necessarily to this specific implementation of it, but having a staging area where chunks are added piecemeal is an enormous benefit. I honestly wish git forced `-p` for operations that support it. I’ve worked on too many teams where people would just commit everything in their work…

> just commit everything in their working directory But that's what they've tested. I've had far more problems in the other direction, where the commit doesn't contain the complete set of things that it's supposed to but because all the tooling - every single IDE and compiler - is looking at the working directory not the index, I've missed something. The index is definitely confusing for new users and users of other…

Like I said, I’m not sold on git’s specific implementation. But breaking things into smaller, focused commits is—in my experience—a hallmark of good development practice.

There should absolutely be better tooling around it, so that these piecemeal commits can be tested in isolation from one another. That’s a far better approach than just throwing up our hands and committing everything in the working tree, even if half of it has nothing to do with what’s intended.

Post reply on HN