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

11–20 of 93 posts

Re: A better merge workflow with Jujutsu

#11

Post by Zambyte »

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…

Others have explained the change IDs already in detail, but I want to try to give a short and sweet explanation: changes in Jujutsu are a mutable, high level abstraction built on gits immutable commits. Change IDs are stable across mutations.

Re: A better merge workflow with Jujutsu

#12

Post by christianPerdu »

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

Same here, exact same here !

Re: A better merge workflow with Jujutsu

#13

Post by roland35 »

Zambyte wrote: post #11
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…

Others have explained the change IDs already in detail, but I want to try to give a short and sweet explanation: changes in Jujutsu are a mutable, high level abstraction built on gits immutable commits. Change IDs are stable across mutations.

Sounds like how Mercurial handles commits!

Re: A better merge workflow with Jujutsu

#14

Post by [deleted] »

roland35 wrote: post #13
Zambyte wrote: post #11

Earlier quoted context omitted.

Others have explained the change IDs already in detail, but I want to try to give a short and sweet explanation: changes in Jujutsu are a mutable, high level abstraction built on gits immutable commits. Change IDs are stable across mutations.

Sounds like how Mercurial handles commits!

[deleted]

Re: A better merge workflow with Jujutsu

#15

Post by Zambyte »

roland35 wrote: post #13
Zambyte wrote: post #11

Earlier quoted context omitted.

Others have explained the change IDs already in detail, but I want to try to give a short and sweet explanation: changes in Jujutsu are a mutable, high level abstraction built on gits immutable commits. Change IDs are stable across mutations.

Sounds like how Mercurial handles commits!

The people who work on Jujutsu explicitly draw a lot of inspiration from Mercurial :)

Re: A better merge workflow with Jujutsu

#17

Post by whoomp12342 »

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.

humans are creatures of habit. fixing these flaws is not enough to motivate us onto something new, it has to be groundbreaking.

Re: A better merge workflow with Jujutsu

#19

Post by jFriedensreich »

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.

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.

Re: A better merge workflow with Jujutsu

#20

Post by packetlost »

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.
Post reply on HN