Live data from Hacker News

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

github.com

81–90 of 233 posts

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

#81

> It combines features from Git (data model, speed), Mercurial (anonymous branching, simple CLI free from "the index", revsets, powerful history-rewriting), and Pijul/Darcs (first-class conflicts), with features not found in either of them (working-copy-as-a-commit, undo functionality, automatic rebase, safe replication via rsync, Dropbox, or distributed file system). You lost me at "free from the index". The index i…

> You lost me at "free from the index". The index is one of the most important parts of Git that makes my life easier. Opinionated DVCS UIs make my life harder -- all of them. Mercurial has an 'index' / staging area, but not exposed by default. You can access it with some extra CLI options, but there is an optional idea that may be 'better' and worth looking into: > If you need the index, you can gain its behavior (w…

I find Mercurial very difficult to use. I find Git much easier.

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

#82
That's very cool to have support for rsync/dropbox collaboration of the repo files. I'm always sad that there isn't a maintained p2p git implementation anymore. I'd love to just dump a bare repo to a syncthing share and collaborate with a small group of people accessing it.

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

#83

Earlier quoted context omitted.

Something probably got messed up on your setup (or maybe you checked out a commit instead of a branch?) because you definitely can see all worktrees' branches from inside each other when using git worktree.

That makes sense. Now I think about it, The issue probably was that I was working in a submodule and those branches are probably not shared.

Yes, as per my other comment, I’ve noticed with submodules that the references are isolated between the different folders, but they do share the same objects in the .git folder, so you still get efficiency there in not needing to store or pull duplicate data.

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

#84

> A Git-compatible DVCS that is both simple and powerful We all know the dig here - Git is not simple. Like many tools, Git has evolved significantly over the years. Git today was not like Git 10 years ago. Also, like many replacements to existing tools and software, they always start out simple and beautiful. Then they grow in complexity to serve the domain. The reason Git is complicated - not "simple" - is mostly b…

> I feel like Git is sufficiently complex - no more than it needs to be and certainly not less. Perhaps the biggest mistake (IMO) was to expose the index to the user. I happened to just watch https://www.youtube.com/watch?v=31XZYMjg93o (by the person behind Gitless). They explain the issues well there.

I'm gonna watch this video. What's been bugging me for a long time, as someone who didn't quite get to see all of the supposed ugliness of Subversion (which by description alone sounds an awful lot like the rerere situation with Git, which I have).

It really feels to me like a commit identifier should be the combination of a monotonically increasing number and a hash of the content, rather than an either-or. If I merge or rebase branches in git, I lose the index, just as I would in subversion. But at least in svn I have some notion of how far back commit 12345 is in the tree. ac4def2 could be HEAD or four years ago.

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

#85

> It combines features from Git (data model, speed), Mercurial (anonymous branching, simple CLI free from "the index", revsets, powerful history-rewriting), and Pijul/Darcs (first-class conflicts), with features not found in either of them (working-copy-as-a-commit, undo functionality, automatic rebase, safe replication via rsync, Dropbox, or distributed file system). You lost me at "free from the index". The index i…

If you can rewrite the history that actually got committed, do you really need a temporary pre-commit staging area?

Yes, I do. I often do this (usually in detached HEAD mode!):

  : ; $EDITOR some-file ...
  : ; $build
  : ; git add -e # take a few chunks, maybe change them
  : ; git diff --staged; git status -uno
  : ; # lather, rinse, repeat
  : ; git commit -m '...' -ev
  : ; 
  : ; git status -uno; git diff
  : ; git add -e # ..
  : ; # lather, rinse, repeat until happy
  : ; 
  : ; git fetch origin
  : ; git rebase origin/master
  : ; # fix any conflicts
  : ; 
  : ; # continue until all bug fix / feature
  : ; # activity for this issue is complete
  : ;
  : ; # review my changes:
  : ; git log --patch origin/master..
  : ;
  : ; # if I have to clean my history a bit:
  : ; git rebase -i origin/master
  : ; # re-order commits, `edit` commits, `drop`
  : ; # commits as needed
  : ; $build
  : ; # fix remaining issues...
  : ; 
  : ; # finally ready to push:
  : ; git push myclone HEAD:refs/heads/this-thing
  : ; 
  : ; # open a PR
Repeat as needed to deal with code review comments until done and integrated.

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

#86
post #11

Earlier quoted context omitted.

If you can rewrite the history that actually got committed, do you really need a temporary pre-commit staging area?

The index is mostly useful to me to split a commit in multiple ones. You do that with a sequence of "git add -p" and "git commit" commands. I am interested in how to do this with jj, because otherwise it looks like a very interesting tool.

`git add -e` is infinitely better.

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

#87
post #11

Earlier quoted context omitted.

The index is mostly useful to me to split a commit in multiple ones. You do that with a sequence of "git add -p" and "git commit" commands. I am interested in how to do this with jj, because otherwise it looks like a very interesting tool.

I prefer "git stash -p" to exclude unfinished changes, because if I build up a partial commit in the index there’s no way to test it.

I do that later. I do `git rebase -i` and add `exec` lines to build each commit that must build.

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

#88
post #44

Earlier quoted context omitted.

> You do that with a sequence of "git add -p" and "git commit" commands. You can do that with git commit -p.

True but there's usually a "git diff --staged" in the middle to check what I am committing.

Exactly!

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

#89

> It combines features from Git (data model, speed), Mercurial (anonymous branching, simple CLI free from "the index", revsets, powerful history-rewriting), and Pijul/Darcs (first-class conflicts), with features not found in either of them (working-copy-as-a-commit, undo functionality, automatic rebase, safe replication via rsync, Dropbox, or distributed file system). You lost me at "free from the index". The index i…

The index is a power user feature. Its forced presence in Git effectively constitutes a usability barrier for new users. After all, a VCS is effectively a glorified abstraction for "save a file." Any barrier imposed between changing a file and committing it can get in the way and confuse people. The Git index does this. Furthermore, the index is effectively a pseudo commit without a commit message. Any workflow using…

I don't deny that the index is a power feature and that it's difficult to explain it to newbies.

Perhaps there's room for new UIs.

All I'm saying is I need this power. And it has to be easy to reach for it.

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

#90

It would be nice if this were in nixpkgs, it's a pain to manage all the different language environments and it would save me from trying to get it to compile. Right now error[E0554]: `#![feature]` may not be used on the stable release channel --> lib/src/lib.rs:15:12 | 15 | #![feature(assert_matches)] |

If you get it working, please share a flake. :)
Post reply on HN