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

211–220 of 233 posts

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

#211

Post by joseph8th »

em-bee wrote: post #91

jujutsu looks interesting, but one thing that i find missing from git is historical branch tracking. once two branches are merged, git does not tell me which series of commits used to belong to which branch. i can't check out main from two weeks ago if a merge happened in the meantime because that information is lost. i fear to add such a feature additional information would need to be stored in the git repo itself w…

I don't need to repeat that Git has terrible UI, but you can get this "history" with `git merge --no-ff ` (no fast-forward).

In fact, it's a pretty common branch-based flow. Our team pushes feature branches to remote, where they are vetted by QA, and we have a chance for review.

When pulling changes into any branch, we always `git pull --rebase`. When merging feature branches, we always `--no-ff`.

For small, local merges, we don't use `--no-ff` because it's useless noise. But if someone forgets out of habit... Oh well. I spend on average 0.000000001% of my time going through git log. And when I do, I tell it to show as a tree

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

#212

Post by joseph8th »

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…

Emacs `magit` might qualify, if you don't mind first learning Emacs

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

#213

Post by joseph8th »

omegalulw wrote: post #28
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…

> With Jujutsu, you'd instead use jj split to split the working copy commit into two commits. This is more confusing? Often times when debugging/writing a fix I would have extraneous code that I wouldn't want to commit. With an index I'm always sure if what I commit, but with this workflow you have to keep track of such stuff all the time and if you forget that stuff makes it in? Not to mention that another benefit o…

Yah... I have a long-standing habit of commenting `TODO` for some debugging or WIP code. Then, before I commit, I can just do `git diff | grep TODO` and see all the new TODOs I've added.

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

#214

Post by pjc50 »

stouset wrote: post #110
pjc50 wrote: post #102

Earlier quoted context omitted.

> 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 hal…

> if half of it has nothing to do with what’s intended.

Perhaps the focus should then be on making it easier to get that junk out of the working tree? Better stashing?

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

#215

Post by qbasic_forever »

CRConrad wrote: post #194
qbasic_forever wrote: post #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.

> there isn't a maintained p2p git implementation anymore. What, it isn't actually a decentralised distributed system any more?!? > I'd love to just dump a bare repo to a syncthing share and collaborate with a small group of people accessing it. Are you saying one can't do that with the latest versions of git? WTF, when did this happen and how can I have missed what must have been huge news when it happened?

You can have sync conflicts with multiple people pushing to a bare repo on a shared folder at the same time. This kind of file sharing with git only works on NFS or filesystems that support locking (look at the git manual for this warning). Syncthing doesn't support that--it _might_ work for some time, but stress it with multiple people all at once and it will explode into sync conflicts eventually.

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

#216

Post by qbasic_forever »

NateEag wrote: post #208
CRConrad wrote: post #194

Earlier quoted context omitted.

> there isn't a maintained p2p git implementation anymore. What, it isn't actually a decentralised distributed system any more?!? > I'd love to just dump a bare repo to a syncthing share and collaborate with a small group of people accessing it. Are you saying one can't do that with the latest versions of git? WTF, when did this happen and how can I have missed what must have been huge news when it happened?

As one who has set up skunkworks git boxes before, I think OP is probably referring to the fact that there is not a no-brainer out-of-the-box way for git repos on different dev machines to autodiscover each other, even on a local network. You can have everyone manually set up a git hosting env on their dev machine, then have everyone manually add a remote for every other developer's box, but it sure isn't convenient.…

Exactly, syncthing has flawless p2p discovery and networking/sharing of files. Being able to put a git bare repo effectively on a syncthing share would be super convenient for small private collaboration. Tailscale might be an option to make a bunch of local git repos all start pushing/pulling, but it has some headaches too and isn't really designed for opening up small single services.

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

#217

Post by cryptonector »

martinvonz wrote: post #103
cryptonector wrote: post #79

Earlier quoted context omitted.

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 desc…

I did, and it's almost certainly nicer than Git for commit splitting.

But even though I might use a tool specifically designed for user-friendly commit splitting, I still want: `git add -e`, `git diff --staged` (to see what I added with `git add -e`) vs `git diff` (to see what I left out), and `git commit` w/o `-a` to commit the contents of the index. This is easier for me than `$WHATEVER commit` followed by `$WHATEVER`'s commit splitting method.

That said, I have to congratulate you again on not taking the ugh-rebase-rewrites-history/history-rewrite-bad road. This is a huge step forward for DVCS.

It may well be that what rebase workflows needed was a UI that non-power users could use.

While we're at it, I wonder what you think of this: https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650...

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

#218

Post by cryptonector »

throwaway81523 wrote: post #54
AnonC wrote: post #35

I’m curious to know if this has any similarities with fossil ( https://fossil-scm.org/ ). If it does, it would be nice to see that in the documentation.

Fossil is ideologically different, it wants to preserve every artifact, no rebasing allowed.

That Fossil doesn't support rebase is a fiction, since it supports cherry-pick. All that's missing is a script around cherry-pick, which is all rebase is.

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

#219

Post by cryptonector »

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…

TIL about `git read-tree`. Thanks! I think it will prove very useful for me. That said, the easiest way to reorder commits is to `git rebase -i $some_base` and then reorder the `pick` lines in your $EDITOR into the order you want.

> In git, every commit is a snapshot and not a delta. (Repeat that three times.)

Yes, but every commit also is notionally a delta. That the delta is reconstructed as needed is not terribly important. It's best to accept a commit as both, a reference to a state of the world, and as a delta to the recorded parent(s).

Lastly, I avoid `git reset --hard`. I often have extant changes that I don't want to lose. Instead what I do is `git rebase -i --autostash`.

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

#220

Post by martinvonz »

cryptonector wrote: post #217
martinvonz wrote: post #103

Earlier quoted context omitted.

> 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 desc…

I did, and it's almost certainly nicer than Git for commit splitting. But even though I might use a tool specifically designed for user-friendly commit splitting, I still want: `git add -e`, `git diff --staged` (to see what I added with `git add -e`) vs `git diff` (to see what I left out), and `git commit` w/o `-a` to commit the contents of the index. This is easier for me than `$WHATEVER commit` followed by `$WHATEV…

That gist seems like a simplified version of https://github.com/mhagger/git-imerge, so check that out if you haven't. (I haven't looked at git-imerge in a long time, so I should read about it again myself.)
Post reply on HN