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

51–60 of 93 posts

Re: A better merge workflow with Jujutsu

#51

Post by stouset »

steveklabnik wrote: post #39
rob74 wrote: post #38

Earlier quoted context omitted.

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.

Three or four for me. Or, however long since there was a jj introduction posted here that got some traction. The only person on my team who’s even aware is the one other person I converted. The interop is that smooth.

I feel like you and I must have the same taste in technologies. I got into Rails (and Ruby itself) around 2007 then fell in love with Rust around 1.0. Now here I find out you’re a jj convert too!

Please let me know the next thing in advance ;)

Re: A better merge workflow with Jujutsu

#52

Post by gpm »

simonmic wrote: post #47

Are Jujutsu users all using it from the command line ? Is there anything magit-like yet ? Or do you use magit with it ? Have you run into extra complexity and messes because of having two VCSes interacting in one working copy ?

I'm an extremely light user (just on a few small projects), but

> Have you run into extra complexity and messes because of having two VCSes interacting in one working copy ?

Well, making git commits in a colocated jujutsu repository was a very confusing experience, because at some point I realized I wasn't on a git branch like I thought I was (after a few commits!). jj somehow magically did the right thing though and after switching back to it I had the commits I tried to make in jj and they worked just fine.

Re: A better merge workflow with Jujutsu

#53

Post by CJefferson »

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…

My main issues with git are all about version control of branches.

Which branches were commits originally created on.

What commit was branch X on 2 weeks in the past?

(My personal biggest issue) -- there is no way to delete a branch in a version-controlled way (that is, let me un-delete it later). 'reflogs' don't count, I want to be able to version-control my branch deletions.

And if people (I'm not accusing you, person I'm replying to, but I get this a lot) say "git isn't for that", well then it's really annoying that git has become "the version control system for everything".

Re: A better merge workflow with Jujutsu

#54

Post by steveklabnik »

stouset wrote: post #51
steveklabnik wrote: post #39

Earlier quoted context omitted.

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

Three or four for me. Or, however long since there was a jj introduction posted here that got some traction. The only person on my team who’s even aware is the one other person I converted. The interop is that smooth. I feel like you and I must have the same taste in technologies. I got into Rails (and Ruby itself) around 2007 then fell in love with Rust around 1.0. Now here I find out you’re a jj convert too! Please…

Ha! ... I want it to be buck2, but I'm still not quite sure how exactly stuff is shaking out. If the open source prelude was better, I'd use it over Cargo.

Re: A better merge workflow with Jujutsu

#55

Post by wmf »

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.

Step one is for you personally to start using jj or sapling or gitless. Step two is to convince two other people.

Re: A better merge workflow with Jujutsu

#56

Post by CraftThatBlock »

simonmic wrote: post #47

Are Jujutsu users all using it from the command line ? Is there anything magit-like yet ? Or do you use magit with it ? Have you run into extra complexity and messes because of having two VCSes interacting in one working copy ?

I am (slowly) working on a TUI: https://github.com/Cretezy/lazyjj

Re: A better merge workflow with Jujutsu

#57

Post by ramon156 »

wmf wrote: post #55
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.

Step one is for you personally to start using jj or sapling or gitless. Step two is to convince two other people.

And since you're early, you'll benefit the most (:

Re: A better merge workflow with Jujutsu

#58

Post by xlii »

I really tried to like jj but I couldn’t make it work for my workflow:

There are files that are committed to repository that I need to edit (e.g. .envrc files, which cannot be overridden). There is no way I can ignore those in Jujutsu.

In plain git I can do sparse checkout using negative paths and it works. jj doesn’t support it, and using positive path doesn’t work as I never know if new files are there.

Every push was a dance around removing my changes. I’m checking if there’s progress from time to time but there’s no so far.

But just yesterday I decided to check git branchless as I’m exploring stacked PR workflow and I can say it’s intriguing and even if more rough around the edges than jj I haven’t yet found any showstoppers.

Re: A better merge workflow with Jujutsu

#60

Post by sunshowers »

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…

To my knowledge there is nothing the git index can do that Jujutsu can't, in a more sensible fashion.
Post reply on HN