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

Jujutsu for busy devs

maddie.wtf

Post reply on HN
Print view View original

341–350 of 552 posts

Re: Jujutsu for busy devs

#341

Post by gabrielgio »

palata wrote: post #333
gabrielgio wrote: post #297

Earlier quoted context omitted.

> I don't have a lot of problems with git that I need to solve, that's the thing. And I don't get why people keep trying to convince me You are in *forum* in a post *about jj* saying there is no reason to use jj. We are just interacting as you'd expect in forum. If you don't see any reason to use anything else and don't want to hear anything about it steer away from these posts. No one is trying to convince you perso…

> You are in forum in a post about jj saying there is no reason to use jj I honestly am not. I am genuinely interested. Everytime there is a post about jj I'm about to try, and then I see a comment like yours, saying "with jj you just use the intuitive syntax `jj git push -r '(trunk\(?.\).x#@ | @@.^)'`, which is a lot simpler than knowing about this weird concept of stash" and it makes me think that maybe, I'll try a…

> I honestly am not.

You literately are, look at you comments.

> I am genuinely interested.

If you are interest in learning you should take people words on good faith, my comment on "jj git push -r '(trunk()..@ | @::)'" is complex operation to update many stacked PRs not compared to local git index operations. Also in my comment I mentioned revsets and the "-r". It is a language to query logs which you should've check if you genuinely wanted to learn about it, which you don't.

Just look at your answer, you literately ignored everything I mentioned and took what I said out of context just to bash on jj for some reason.

Re: Jujutsu for busy devs

#342

Post by dilap »

stouset wrote: post #33

For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out…

There is a 3rd group (probably mostly gamedevs) who think it seems like a great idea and really want to try it, but are blocked waiting for git-lfs support.

Every time jujutsu pops back up on HN I check to see if they've added it yet. Not yet! But they are slowly getting there:

https://github.com/jj-vcs/jj/issues/80

Re: Jujutsu for busy devs

#343

Post by dilap »

Ayesh wrote: post #152
xelxebar wrote: post #136

Earlier quoted context omitted.

It's certainly a solid improvement in the space of VCS UI, but beware that jj has some current limitations which might prohibit switching, especially for the git power users. Lack of gitattributes support precludes git-crypt and git-lfs usage or anything that needs filters; line ending settings will get ignored, making Windows interop a little less smooth; etc. Also note that auxillary tooling, such as git-annex and…

I use gitattributes quite a lot (lfs, various diff engines, and export-ignore). Thanks for the heads-up, jj looked very interesting but I'm not going to give up gitattrivutes.

They are slowly working on it:

https://github.com/jj-vcs/jj/issues/53

(I am interested because I want to try, but need git-lfs, which needs gitattributes.)

Re: Jujutsu for busy devs

#344

Post by dubi_steinkek »

ants_everywhere wrote: post #257
baq wrote: post #238

Earlier quoted context omitted.

this is not as important as you're used to. I've been there, I've used git since early 2010s and yes autostaging was preposterous at first. in practice, it's barely relevant: the workflow changes from 'I pick what is tracked' to 'I pick what is pushed'.

You know your evangelists have gone haywire when they're explaining that your requirements are wrong instead of listening.

I don't think that's a fair characterization.

It's more that there isn't really a big difference between the workflow of

    # you're on
      staging area
    @ commit A
    # make some untracked changes and console logs you don't wanna commit
    git add -p && git commit # select only what you want
vs

    # you're on
    @ empty commit 
    | commit A
    # make some local changes (which are tracked in @)
    jj commit -i # select only what you want
You're still "in charge what gets tracked" if you treat the last @ commit as your local playground, exactly the same as the staging area. The only difference is that you can use exactly the same tools to manipulate your "staging area" as other commits. The only difference being that you can manipulate your staging area with the same tools as any other commit.

Re: Jujutsu for busy devs

#346

Post by Cthulhu_ »

amomchilov wrote: post #312
tomasyany wrote: post #266

Don't want to sound old school, but git works perfectly fine. The learning curve might be a bit difficult, but afterwards everything makes sense. And let's be honest, you just need a few actions (pull, add, reset, branch, commit) to use it in 95% of the cases.

Stacked diffs are a core part of my workflow, letting me “work ahead” without being blocked waiting for reviews. Setting them up in git is not to bad. Adding a change to the bottom of the stack, and restacking everything on top… that’s hell in git.

Check out the rebase.updateRefs option: https://dev.to/onepoint/git-update-refs-in-a-nutshell-574c

Re: Jujutsu for busy devs

#347

Post by Cthulhu_ »

killerstorm wrote: post #292
tomasyany wrote: post #266

Don't want to sound old school, but git works perfectly fine. The learning curve might be a bit difficult, but afterwards everything makes sense. And let's be honest, you just need a few actions (pull, add, reset, branch, commit) to use it in 95% of the cases.

If you work in a team you need to understand rebasing and squashing, unless you can convince team to never use these features. A lot of people are religious about rebasing, "clean" commit history. But it's pretty much incompatible with several devs working on a single branch. I.e. when you work on something complex, perhaps under time pressure, git habits bite you in the ass. It's not fine.

As soon as you have the situation of multiple people working on the same branch, forbid force pushes at all times. But it's better to avoid that in the first place, all work should be on its own branch at all times.

For larger features we often have a feature branch with merge requests for various task branches. Limits the review sizes as well.

Of course, you can also then consider to use feature toggles, so there's no feature branch but just your main branch.

Re: Jujutsu for busy devs

#349

Post by lolstarz »

stouset wrote: post #33

For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out…

I have noticed this trend too. I don't know if I'm simply too smooth-brained for `jj` or what, but I forced myself to use it for a month to give it a fair shake and simply couldn't grok it. I gave up and went back to rawdogging git. So there are at least some of us out there.

Re: Jujutsu for busy devs

#350

Post by Cthulhu_ »

baq wrote: post #235
arp242 wrote: post #15

Earlier quoted context omitted.

I don't especially like git. I stuck with mercurial for a long time. But that was ten years ago. Now git is kind of hard-wired in my brain. By and large, it works well enough. It's not really clear to me that Jujutsu offers a significant enough of a benefit to spend the time re-wiring my brain, never mind dealing with the initial setup (e.g. the unreadable colours, setting up some scripts/aliases for things I like).

> By and large, it works well enough. be wary of the stockholm syndrome. I too love git, but it is a very cumbersome tool for some workflows.

But does Jujutso solve those workflows, or does it add a layer on top that you need to figure out on top of what you already know about Git?

I don't run into any issues with Git during my day to day. Some things could be a bit more ergonomic but that's because I'm too stubborn to learn or set up some aliases or look up how to do it.

Following this tutorial, I can't say jujutsu feels like an improvement. More complicated log output (I use a shorthand (think "git log --oneline --graph" but with a custom output format to also show absolute and relative commit time and author)), automatic staging (that can be turned off but why should I when it's already off if I don't use jj?) while I use "git add -p" through an alias, and the rest is just push / pull / checkout / reset.

Post reply on HN