Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jujutsu VCS: Introduction and patterns

kubamartin.com

Post reply on HN
Print view View original

91–100 of 128 posts

Re: Jujutsu VCS: Introduction and patterns

#91

Post by mixmastamyk »

stouset wrote: post #90
mixmastamyk wrote: post #89

Earlier quoted context omitted.

Just said I don't want color==never. That's the problem, no one can cogently/concisely explain why. I don't love git but have sanded its rough edges already. Gitlab did the rest. I recommend this Spolsky classic on how to convince one to try a new VCS: https://hginit.github.io/ Doesn't have to be this long but note his writing style.

> no one can cogently/concisely explain why There are literally dozens of examples of comments in this thread doing exactly that. Perhaps those explanations don't resonate with you and that's fine.

You're still missing the why and more specifically how. It's not enough to tell a story full of vague assertions, you have lead the reader through what amounts to a tutorial.

Re: Jujutsu VCS: Introduction and patterns

#92

Post by stouset »

mixmastamyk wrote: post #91
stouset wrote: post #90

Earlier quoted context omitted.

> no one can cogently/concisely explain why There are literally dozens of examples of comments in this thread doing exactly that. Perhaps those explanations don't resonate with you and that's fine.

You're still missing the why and more specifically how. It's not enough to tell a story full of vague assertions, you have lead the reader through what amounts to a tutorial.

There are plenty of specific, pointed assertions being made. Maybe they don’t resonate with you. Again, that’s fine. You are not owed an explanation that meets your personal set of criteria.

Re: Jujutsu VCS: Introduction and patterns

#93

Post by ahartmetz »

sunshowers wrote: post #66
saulrh wrote: post #65

Earlier quoted context omitted.

I guess I was thinking in terms of the patches you push up to github. `jj` is a joy to use and it absolutely enables me to implement workflows that I wouldn't even vaguely consider without it helping me; the big one I think of is the one where you work in a merged dir with like six parents and use `jj absorb` to instantly spread your changes out to the different PRs. I've been forced to do that in git. It was a night…

Absolutely! jj is a real advancement in the state of the art. I think it's the second time in the history of source control where the authors of a new system have spent a long time working on existing systems + deploying them at scale, and have brought their full expertise to bear on the design of the new system. (The first was BitKeeper, which also was a tremendous achievement.)

Third time? SVN was a big improvement over CVS. CVS was full of UX blunders, kind of like Git compared to something with good UX.

Re: Jujutsu VCS: Introduction and patterns

#94

Post by sunshowers »

ahartmetz wrote: post #93
sunshowers wrote: post #66

Earlier quoted context omitted.

Absolutely! jj is a real advancement in the state of the art. I think it's the second time in the history of source control where the authors of a new system have spent a long time working on existing systems + deploying them at scale, and have brought their full expertise to bear on the design of the new system. (The first was BitKeeper, which also was a tremendous achievement.)

Third time? SVN was a big improvement over CVS. CVS was full of UX blunders, kind of like Git compared to something with good UX.

Did the Subversion creators have a lot of prior experience working on CVS?

Re: Jujutsu VCS: Introduction and patterns

#95

Post by rob74 »

ahartmetz wrote: post #93
sunshowers wrote: post #66

Earlier quoted context omitted.

Absolutely! jj is a real advancement in the state of the art. I think it's the second time in the history of source control where the authors of a new system have spent a long time working on existing systems + deploying them at scale, and have brought their full expertise to bear on the design of the new system. (The first was BitKeeper, which also was a tremendous achievement.)

Third time? SVN was a big improvement over CVS. CVS was full of UX blunders, kind of like Git compared to something with good UX.

...and don't ask about the first version control tool I had the "pleasure" of using, M$'s Visual SourceSafe o_O

Re: Jujutsu VCS: Introduction and patterns

#96

Post by renox »

dartos wrote: post #8
cupofjoakim wrote: post #3

I think I'm at risk of sounding like a broken record here. I've read about jj many times now but i'm still confused as to what problem it actually solves. I get the same feeling as when some dude wants to sell me on using vim as my primary code editor - arguments are there but it doesn't really solve an issue. I'll go over to jj when that's the primary tool for the job, or when I can see something that beats the git…

I switched from git to jj a few months ago, so I may have some insight. I used it at work, where everyone used git, and there were 0 issues. What I really like about it is how changes are sort of soft committed right away and, when I checkout a different branch or change, I don’t need to stash my changes and remember the stack of stashes. Rebasing and merging feel a little easier, but that might just be because “ours…

> The only tangible downside for me is that it doesn’t support git hooks

Thanks for this information: at work we use them for creating gerrit review id, so I'll wait until jj get this feature.

Re: Jujutsu VCS: Introduction and patterns

#97

Post by hinkley »

stouset wrote: post #87
hinkley wrote: post #60

Earlier quoted context omitted.

I'll have to try it on a blank checkout because once I've run 'jj new' then 'jj st' does something similar to git st, but I had a situation on a fresh checkout where I know I'd saved changes in the IDE, git st showed them, but jj st came up as blank. It may be that this only happens immediately after jj git init. But any tool that lies to people is a huge red flag. Because while I can memorize that caveat it's presum…

With all due respect, it sounds like you might have some confusion about what happened. If you run `jj new`, `jj st` will virtually by definition show a clean working copy. You've created a new, empty revision, and as a consequence there are zero changes which have been made in that empty revision. Asserting that `jj` "lies to people" is… probably uncalled for here. I'm not going to say it's impossible for the two co…

If I have a working directory with active changes in it, that are not in the ignore file, I expect my VCs tool to show edits in its status. Full stop.

Re: Jujutsu VCS: Introduction and patterns

#98

Post by nulld3v »

hinkley wrote: post #40
gechr wrote: post #26

Earlier quoted context omitted.

Although it is currently undocumented, since v0.21.0 you can make `--edit` the default by adding the following to your configuration: [ui.movement] edit = true Ref: https://github.com/jj-vcs/jj/pull/4283

The config file needs a lot of love. As does the help. If you clone the repo there’s a bunch of documentation and example files, but if you install jj, those do not exist.

If your editor supports TOML schemas you can add the following to the config file to get autocomplete and in-editor documentation:

    "$schema" = "https://jj-vcs.github.io/jj/prerelease/config-schema.json"
More info here: https://jj-vcs.github.io/jj/prerelease/config/#json-schema-s... (I changed latest -> prerelease in the URL as this feature has been merged but not yet released).

Re: Jujutsu VCS: Introduction and patterns

#99

Post by zellyn »

BeetleB wrote: post #82
pkulak wrote: post #69

Earlier quoted context omitted.

> Nobody else knows you use `jj`, so no barrier to adoption. All my PRs now have branches named "push-kjasdfkhdf", so it's not terribly well hidden. :D

You can name them if you want.

Hah. I didn't even realize you could _not_ name them.

I just do:

    jj b c zellyn/appname-update-plugh-tests
    jj git push

Re: Jujutsu VCS: Introduction and patterns

#100

Post by tripple6 »

mamcx wrote: post #14
cupofjoakim wrote: post #3

I think I'm at risk of sounding like a broken record here. I've read about jj many times now but i'm still confused as to what problem it actually solves. I get the same feeling as when some dude wants to sell me on using vim as my primary code editor - arguments are there but it doesn't really solve an issue. I'll go over to jj when that's the primary tool for the job, or when I can see something that beats the git…

I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git. I have used it already for a few years and can't for the life of me figure out how to solve problems with it. I just have a bunch of aliases that abstract away for the inconsistency of its commands. Now, I switched to `jj` a month ago and basically, I have learned around 60…

I would never work with hg anymore since and I consider git much and much more flexible from both user and scripting perspective. Yes, git also suffers of command inconsistency, and unfortunately it seems to be never fixed.

> You can UNDO. Everything. That is the major thing

Everything is what? The things git cannot undo is removing untracked files (well they're untracked) on git-clean, or files added to the index for the first time and then reset. Maybe rebase in mid-rebase is a way to lose some changes so one has re-rebase again (it's really annoying, but reflog holds all rebase changes if I recall). I can't really see what you mean.

> You can switch from one `branch` to `another` and leave things incomplete, even conflicts, that is nice.

It's nice. I use git-worktree for multiple branches I work on, so my working copies may remain dirty even in conflict stage.

> The command made sense

It's nice.

> Nobody else knows you use `jj`, so no barrier to adoption.

It's really nice, but I'm not sure whether I understand it, but does it work as a front-end tool over git/other VCS?

> Rebases are not painful anymore. Stacking prs are finally nice to author, even of NOBODY ELSE KNOW IT!

I don't get it. What does make rebase hard? It's just re-applying a bunch of patches or possibly merges on top of the new base, and it doesn't even require interactive mode. Interactive mode makes magic I'm happy with. Seriously, what's wrong with it?

Post reply on HN