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

A better merge workflow with Jujutsu

ofcr.se

Post reply on HN
Print view View original

31–40 of 93 posts

Re: A better merge workflow with Jujutsu

#31

Post by stevage »

rob74 wrote: post #23
pc86 wrote: post #22

Earlier quoted context omitted.

This will sound flippant but it's an honest question: who cares? I use git all day, every day. Sometimes CLI, sometimes a dedicated UI (e.g. GH desktop but have also used Tower and other dedicated tools), sometimes a UI in something else a la VSCode. I write code every day. Why should I care at all about rebase vs. merge, whether the internals of git are optimal, whether index needs to exist at all or what it even is…

I would care if a new VCS would make my life easier. This quote from the linked article: > very few working developers have a good mental model for Git. Instead, they have a handful of commands they have learned over the years: enough to get by, and little more. ...pretty much describes me TBH. I know enough of git to get by day to day, but if I need to do more than that, I have to rely on StackOverflow et al. Which…

I have used git for many years, have over 250 repos on GitHub and have written several blog posts about it.

This is definitely me. I will never understand it.

Re: A better merge workflow with Jujutsu

#32

Post by michelledepeil »

chasinglogic wrote: post #2

> Using Jujutsu, “amending a commit” also produces a new commit object, as in Git, but the new commit has the same change ID as the original. This is confusing to me, though to be fair I'm a "git expert" by trade. If you're amending a commit surely the "change" has changed so the change ID should also change? If the "change" isn't tracking the actual changes then what could it be tracking? Overall I think this is jus…

TIL about worktrees, a feature I've needed in the past but didn't expect to even exist.

Re: A better merge workflow with Jujutsu

#33

Post by steveklabnik »

packetlost wrote: post #29
stevage wrote: post #21

Earlier quoted context omitted.

Nah, git has lots of bad design choices that are deeper than UI. The index doesn't need to exist. There is a lot of state that is not recorded anywhere - history lost forever. The rebase vs merge disaster. Etc etc.

> git has lots of bad design choices that are deeper than UI. The index doesn't need to exist. The index is a useful tool. You can opt out with `git commit -a` > There is a lot of state that is not recorded anywhere Examples? > The rebase vs merge disaster ??? How is this a disaster? They serve different purposes and have entirely different semantics. You can use rebase to force fast-forward merges (which do not crea…

(Not your original parent, my take)

> The index is a useful tool

To be clear, jj retains the full power of the git index, without having one. To use git terms, the index is just a normal commit like any other. The index is one of my favorite features of git. I don’t miss it in jj.

> Examples?

For one… the index! It’s not part of your history. The working directory can contain dirty state that’s not tracked anywhere. Those are the big two off the top of my head.

> how is this a disaster?

I’m on your side with this one, and jj supports both just fine.

Re: A better merge workflow with Jujutsu

#35

Post by steveklabnik »

michelledepeil wrote: post #32
chasinglogic wrote: post #2

> Using Jujutsu, “amending a commit” also produces a new commit object, as in Git, but the new commit has the same change ID as the original. This is confusing to me, though to be fair I'm a "git expert" by trade. If you're amending a commit surely the "change" has changed so the change ID should also change? If the "change" isn't tracking the actual changes then what could it be tracking? Overall I think this is jus…

TIL about worktrees, a feature I've needed in the past but didn't expect to even exist.

Jj also supports worktrees, though they call them workspaces.

Re: A better merge workflow with Jujutsu

#36

Post by pc86 »

rob74 wrote: post #23
pc86 wrote: post #22

Earlier quoted context omitted.

This will sound flippant but it's an honest question: who cares? I use git all day, every day. Sometimes CLI, sometimes a dedicated UI (e.g. GH desktop but have also used Tower and other dedicated tools), sometimes a UI in something else a la VSCode. I write code every day. Why should I care at all about rebase vs. merge, whether the internals of git are optimal, whether index needs to exist at all or what it even is…

I would care if a new VCS would make my life easier. This quote from the linked article: > very few working developers have a good mental model for Git. Instead, they have a handful of commands they have learned over the years: enough to get by, and little more. ...pretty much describes me TBH. I know enough of git to get by day to day, but if I need to do more than that, I have to rely on StackOverflow et al. Which…

I would try a new VCS if it made my life easier too, but I think my point is just that the quote you posted is not only accurate for most developers, but that there's nothing wrong with that. Having a perfect mental model of how git works is going to be a waste of time for anyone who doesn't want to actually work on git itself.

Re: A better merge workflow with Jujutsu

#37

Post by jFriedensreich »

epage wrote: post #24
jFriedensreich wrote: post #19

Earlier quoted context omitted.

you can start using sapling today. its github compatible and production ready. as long as the new tools support github or whatever forge/hub you are using, there is no need for critical mass for adoption. This is not possisble for radical approaches like pijul, but that approach is not fully proven yet.

Isn't sapling only compatible with git servers and not local repos? That is a huge impediment with so many tools expecting git. That is what i find impressive about jj is it is compatible with local repos.

that is true, i have a separate clone of my repos with sapling and git and use 98% of the time the sapling one with sapling and most importantly interactive smartlog (which is 1000 times better than most git tooling so would be reason alone to do this.) for the few times i need my git tools i sync the git clone via the git remote and then use the git tools on that repo.

Re: A better merge workflow with Jujutsu

#38

Post by rob74 »

packetlost wrote: post #20
stevage wrote: post #16

All these things just remind me how depressing it is that we all use this deeply flawed tool, git, and no one can get enough critical mass for a substantially better version.

the world if filled with "good enough" tools and I don't foresee that ever changing tbh. You'd have to offer something really substantially better than the status quo to gain critical mass. That being said, I think the only thing about git that doesn't make reasonable sense are the damn command line flags and subcommand names. The actual semantics of git are pretty much exactly what you want for source control.

Jujutsu tries to avoid that by being compatible with git. Quote from https://v5.chriskrycho.com/essays/jj-init/:

> I have been using the Git backend for the last seven months, full time, on every one of my personal repositories and all the open source projects I have contributed to. With the sole exception of someone watching me while we pair, no one has noticed, because the Git integration is that solid and robust. This interop means that adoption can be very low friction. Any individual can simply run jj git init --git-repo . in a given Git repository, and start doing their work with Jujutsu instead of Git, and all that work gets translated directly into operations on the Git repository.

Well that sounds... pretty good actually! Makes me want to try it too...

Re: A better merge workflow with Jujutsu

#39

Post by steveklabnik »

rob74 wrote: post #38
packetlost wrote: post #20

Earlier quoted context omitted.

the world if filled with "good enough" tools and I don't foresee that ever changing tbh. You'd have to offer something really substantially better than the status quo to gain critical mass. That being said, I think the only thing about git that doesn't make reasonable sense are the damn command line flags and subcommand names. The actual semantics of git are pretty much exactly what you want for source control.

Jujutsu tries to avoid that by being compatible with git. Quote from https://v5.chriskrycho.com/essays/jj-init/ : > I have been using the Git backend for the last seven months, full time, on every one of my personal repositories and all the open source projects I have contributed to. With the sole exception of someone watching me while we pair, no one has noticed, because the Git integration is that solid and robust.…

It’s been about five months of the same for me.

Re: A better merge workflow with Jujutsu

#40

Post by stouset »

aranw wrote: post #9

I really like the idea of Jujutsu and was really keen to try it out but when I looked at it several months back I found it really hard to get going with it and ended up just ditching it. This article looks to be a explanation to some of the concepts of `jj` and how to use it in a little more depth than some of the other tutorials I have seen out there. Definitely keen to give it another try at some point

On the flip side, I expected it to be a bigger migration than it was. But I was using it effectively as a complete git replacement the very first day.

I still had a few things I didn’t know how to do optimally, but it was close enough to be productive. Within a week I’d closed basically all of the gaps.

It’s been three or so months and I’m never going back. It’s been so transformative I can barely remember all the innumerable frustrations and papercuts I used to put up with daily. Rebase conflicts. Juggling the stash. Ugh.

I say this as someone who considered themselves extremely proficient with git. I mean, I wrote a compatible Ruby implementation of it over a decade and ago.

If it gains momentum, jj has a better chance than anything I’ve seen at finally dethroning git.

Post reply on HN