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

41–50 of 233 posts

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

#41

Post by martinvonz »

detaro wrote: post #36
martinvonz wrote: post #19

Earlier quoted context omitted.

> I am interested in how to do this with jj `jj split -r `, where ` ` may be the working copy commit (which is the default). See https://github.com/martinvonz/jj/blob/main/docs/git-comparis... for more examples.

so just for understanding: repeated `git add -p` followed by a `git commit` turns into repeated `jj split; jj squash`, since you create a commit each time?

That would work, yes, but there's also `jj squash -i` to move part of the child commit into the parent. There's also the more generic `jj move` command for moving part of any commit into any other commit (ancestor, descendant, sibling), so you `jj squash -i` is equivalent to `jj move -i --from @ --to @-` (where `@` is syntax for the working copy commit and `@-` is syntax for its parents).

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

#42

Post by lillecarl »

blagie wrote: post #38

This seems really nice. git got the data model really right, and the user space really wrong. The data model is more important than the user space. This is the first project I've seen which appears to understand and respect /how/ and /why/ the git data model is so elegant.

The pijul model makes even more sense to my brain, being patch based solves a lot of branching issues.

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

#43

Post by mdaniel »

martinvonz wrote: post #9
mdaniel wrote: post #2

That's quite impressive, congratulations! The git comparison docs have: > Start working on a new change based on the branch -- jj co main Did you consider the recent git nomenclature change to use "switch" for branch operations, and "co" for file operations? I actually can't tell from so deep in my "git Stockholm syndrome" whether that distinction is really hard on new users or not, but the fact that git expended the…

Thanks! > Did you consider the recent git nomenclature change to use "switch" for branch operations, and "co" for file operations? Actually, isn't "restore" for file operations? My impression was that everyone agrees that `git checkout` does too many different things. In particular, it's both for switching branches and for restoring file content. So they added the new `git switch` and `git restore` with limited scope…

> No, that's not something I've even started thinking about. I'll have to read up on how it works in Git first. Patches welcome, though :)

I opened an issue and provided links to the docs, and a link to the current way that git implements it: https://github.com/martinvonz/jj/issues/58

As I was trying to find the correct command in jj for where to add the new argument, I realized that this may not play nice-nice with jj's commit-everything model, so I'm actually prepared for the issue to be closed WONTFIX :-)

As for the patches welcome part, I notice that the Google CLA bot is on your repo. While I do have the CLA signed for my Gmail address, it seemed like some major tomfoolery to try and add my current github email address (and the one which backs my GPG key, to bring this full circle!) to the existing CLA process. Do you intend to keep that CLA mechanism in place, or was it just an oversight?

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

#44

Post by bonzini »

masklinn wrote: post #18
bonzini wrote: 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.

> 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.

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

#45

Post by usrusr »

tuwtuwtuwtuw wrote: post #23
kyrra wrote: post #15

For those that didn't look, this is 100% rust.

Seems irrelevant to me. Why do you care about the language choice?

People do tend to see tools written in a systems language in another light than tools written in a glue language. Did you read it as "rust (not C)" or did you read it as "rust (not Python)"?

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

#46

Post by kuboble »

1) What are the advantages of using native backend as compared to git?

2) Are there any potential issues one has to be aware of when using jj contributing to git repository?

I remember when I was the only team member using git-svn plugin my coworkers were confused when I svn-committed many commits at once with some of them breaking the time order of the svn history (as git-svn commits in svn were recorded with git timestamp and not the actual svn- commit timestamps)

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

#47

Post by wcarss »

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…

> 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?

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

#48

Post by martinvonz »

mdaniel wrote: post #43
martinvonz wrote: post #9

Earlier quoted context omitted.

Thanks! > Did you consider the recent git nomenclature change to use "switch" for branch operations, and "co" for file operations? Actually, isn't "restore" for file operations? My impression was that everyone agrees that `git checkout` does too many different things. In particular, it's both for switching branches and for restoring file content. So they added the new `git switch` and `git restore` with limited scope…

> No, that's not something I've even started thinking about. I'll have to read up on how it works in Git first. Patches welcome, though :) I opened an issue and provided links to the docs, and a link to the current way that git implements it: https://github.com/martinvonz/jj/issues/58 As I was trying to find the correct command in jj for where to add the new argument, I realized that this may not play nice-nice with…

> I realized that this may not play nice-nice with jj's commit-everything model

Yes, I suppose you might not want to sign every working copy commit, but as you noted on the issue, it would probably make sense on `jj close/commit` (aliases).

> Do you intend to keep that CLA mechanism in place

I started working on this project internally and then open-sourced it. I don't think I'm allowed to remove the CLA bot. I understand that it's annoying :(

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

#49

Post by intrepidhero »

wcarss wrote: post #47
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…

> 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?

Post reply on HN