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

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

#161

Post by CRConrad »

feanaro wrote: post #120
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…

> But that's what they've tested. https://pre-commit.com/ helps with that. > It would be quite fun if we could have hierarchical commits, so I could add bits to a commit without having to squash/amend. Yes! I've been saying this for years. Branch merge commits are already this, kind of. However their UI sucks and there's an idea gap which prevents them from being fully understood as such "supercommits" composed of su…

>> hierarchical commits, so I could add bits to a commit without having to squash/amend.

> Branch merge commits are already this, kind of. However their UI sucks and there's an idea gap which prevents them from being fully understood as such "supercommits" composed of subcommits.

Isn't that "idea gap" mainly the fault of all these weird newfangled git workflows that discourage or outright forbid branching? If you have no branches to merge, you can't have a merge commit to act as a "supercommit".

Call your "supercommit" a "feature", and what you need to implement it is... A feature branch.

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

#162

Post by bitcharmer »

CGamesPlay wrote: post #114

Interesting ideas! I especially like the automatic rebasing and associated ideas. It's a bit strange to see "jj st" will automatically add all files to the "working copy" commit. This means that when I initially create my project, run "npm install" to install 500 MB of dependencies, and then run "jj st" to figure out what to include in my first commit, the command is going to copy all of that into a commit object for…

Why put 500mb worth of downloadable dependencies in your source tree? This sounds like a terrible thing to do.

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

#163

Post by martinvonz »

intrepidhero wrote: post #49
wcarss wrote: post #47

Earlier quoted context omitted.

> My team is totally PR based though so if/when doing (Git compatible) feature branches lands in JJ I'm excited to switch. I'm trying to find the part of the docs that refers to this functionality as missing but I can't -- does jj not have the ability to create, update, pull from, merge branches, etc?

> For example, pull-request workflows currently require too many manual steps. Supported but not great I guess?

Yes, they are supported, and documented at https://github.com/martinvonz/jj/blob/main/docs/branches.md. I need to document better how to use them for common workflows like GitHub PRs.

FYI, here's one way to use them with GitHub PRs:

1. Create a fork via GitHub's web UI 2. Clone using the SSH protocol (`jj git clone git@github.com:...`) 3. Make your changes and "commit" (`jj close/commit`) 4. Create a branch pointing to the commit you just created (`jj branch my-feature -r @-`) 5. Push it to your fork (`jj git push`)

So that doesn't seem too onerous, I guess? Maybe the "too many manual steps" are to clean up afterwards. I just tried it in a test repo and deleting the branch from the fork and then `jj git fetch` from there does delete the local branch, but it doesn't abandon the commits, so you need to run `jj abandon` on them if you don't want them anymore.

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

#164

Post by martinvonz »

Aeolun wrote: post #130
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…

I’m not sure I understand how you can have a git compatible data store, but not have git compatible feature branches?

I don't think skrebbel was saying that the branches are not git-compatible, I think they were just wondering if there is support for branches at all, but I'm not sure. Anyway, there is support for branches. They behave more like Mercurial's "bookmarks" in that they are assumed to have the same name on all remotes. That usually works well, but it gets annoying if there are unrelated branches all called e.g. "fix-formatting" on multiple remotes you pull from. Jujutsu would then tell you that the branch has a conflict because it doesn't know where it's supposed to point. I'll probably add some way of telling `jj git fetch` which branches to import, but I'm not sure yet what the best solution is.

See https://github.com/martinvonz/jj/blob/main/docs/branches.md for more information.

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

#165

Post by martinvonz »

martinvonz wrote: post #158
gmfawcett wrote: post #90

Earlier quoted context omitted.

If you get it working, please share a flake. :)

I filed https://github.com/martinvonz/jj/issues/61 about having Nix packages. I should learn about Nix packaging some day, but I'd appreciate any help I can get.

FYI, there was an update on that issue saying that they're going to create an overlay tomorrow.

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

#166

Post by gmfawcett »

martinvonz wrote: post #165
martinvonz wrote: post #158

Earlier quoted context omitted.

I filed https://github.com/martinvonz/jj/issues/61 about having Nix packages. I should learn about Nix packaging some day, but I'd appreciate any help I can get.

FYI, there was an update on that issue saying that they're going to create an overlay tomorrow.

Awesome! Thanks for sharing the update.

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

#167

Post by hinkley »

tragictrash wrote: post #160
hinkley wrote: post #94

Earlier quoted context omitted.

I am by all accounts the SME on git at my company. I often am the VCS expert at my company. I don't like using tools I don't understand, and my brain is pretty good at handling problems that look like graph theory. After using git for 6 years git still terrifies me. After 9 months of svn I performed open heart surgery to remove a 1GB zip file that some dummy merged before anyone thought to stop him. It was at least 1…

It's not that hard man. Really isn't. Your anecdote sounds like someone who thinks they're awesome at git setting a noob up for failure and then mansplaining when they fuck up. It's not hard to be better at git than 85% of people, most devs I've met don't understand the basics beyond pull commit push.

You don't get to work on a git repository by yourself.

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

#168

Post by martinvonz »

lostintangent wrote: post #139

This is awesome! And it’s so exciting to see folks investing energy into this problem space. Out of curiosity: did you add support for multiple backends because you don’t think Git will ultimately be sufficient for the experience you want to create? Or did you just want to ensure that the tool didn’t become unnecessarily coupled to Git?

Good question. You're right on both guesses. One reason is that I want to make sure the API works well enough that it's easy to replace the backend. The current native backend is called `local_store` because it stores files locally (just like the Git backend does). I want to be able to add another backend that fetches objects from a remote instead (and caches them locally), although another option is to hide that part inside the backend like Git does with its partial clone support. I also want to be able to add more functionality that the Git backend doesn't have. Maybe that would be tracking of renames, or maybe something I haven't though of yet.

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

#169

Post by martinvonz »

hinkley wrote: post #150
martinvonz wrote: post #52

Earlier quoted context omitted.

> 1) What are the advantages of using native backend as compared to git? Very few. The disadvantages are generally much larger. The main advantage is that you won't run into a (harmless) race that happens once in a while with the git backend ( https://github.com/martinvonz/jj/issues/27 ). Disadvantages include not being able to interact with git repo and performance problems (both size and speed). I should add a note…

> The backend exists mostly to prove that it's possible and to make sure that the backend API doesn't become tied to Git. Do you expect this to always be the case or are you waiting for inspiration/collaboration to make a better go of it?

I hope to one day make it better, but it's very low priority right now because the Git backend works well and has the big advantage that it's compatible with Git :) Also see https://news.ycombinator.com/item?id=30403737.

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

#170

Post by cryptonector »

c-smile wrote: post #100
cryptonector wrote: post #85

Earlier quoted context omitted.

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

Are you human? > detached HEAD mode Ah, I see, not anymore...

Lol, have an upvote!
Post reply on HN