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

61–70 of 93 posts

Re: A better merge workflow with Jujutsu

#61

Post by kazinator »

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…

You cannot "opt out" of the index. It's always sitting there.

   $ ls -l .git/index
When it gets corrupt, though, you can blow it away. It gets rebuilt.

The reason it can be casually rebuilt is that there is a copy of it in the HEAD commit.

The git index is an intestinal appendix. It has no reason to exist.

There is no need to "stage" changes and then move them to a commit. What is called staging should just create a new commit.

The index creates duplicity. Many commands operate on both the work tree and index, or separately on either one.

Your working tree can differ from the index, which differs from the HEAD commit, so then you have "git diff" (tree to index), "git diff --cached" (index to HEAD) and "git diff HEAD" (tree to HEAD).

What's the point of staging a commit, when a commit can be amended? You need staging for something that cannot be easily fixed once it is deployed.

Re: A better merge workflow with Jujutsu

#62

Post by kubanczyk »

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…

>> The rebase vs merge disaster

> ??? How is this a disaster?

Not a disaster, but merge was not strictly needed. We could've lived with rebase only.

But in git (unlike in jj) rebase is deeply flawed. If you ever needed to resolve the same conflict through several commits you know it. That flawed git implementation is why people kept using merge yo solve the problem on a single final commit.

Re: A better merge workflow with Jujutsu

#63

Post by rkangel »

stouset wrote: post #40
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 in…

"New VCS, but Git is a first-class backend" is an amazingly smart decision. It's the only chance you actually have of supplanting git. It's a new VCS with enough workflow benefit to be worth making a user switch (in contrast to most git alternate command lines) but provides an easy migration path where you don't have to make a "whole repository" decision. It's an individual engineer decision, that still allows using your existing servers (Github/lab).

Re: A better merge workflow with Jujutsu

#64

Post by arccy »

xlii wrote: post #58

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…

can't you just add them to gitignore? if you want it to be local only, there's also .git/info/exclude or for all your repos with ~/.config/git/ignore

Re: A better merge workflow with Jujutsu

#65

Post by arccy »

0cf8612b2e1e wrote: post #45
epage wrote: post #27

Earlier quoted context omitted.

imo revision is worse. I feel like the best terms are patch id and patch revision id.

I am sad I read this, because patch is perfect, but I doubt they will change the language again.

patch sounds too specific... like an actual patch file tied to the actual contents of the patch.

change is probably the right word, you want to change something, the exact operations of the change (multiple revisions of different patches) can evolve over time.

Re: A better merge workflow with Jujutsu

#66

Post by dolmen »

I have lot of old local Git branches. Most were pushed on the central server. The central server also have some old branches. Some local branches have been rebased locally. Some have been rebased on the server. Some have been merged on the server (with rebase or not).

I need to clean-up both my local clone and the central server from the branches which contain changes that have been fully merged

Can Jujutsu help with that task? If not, any other solution?

Re: A better merge workflow with Jujutsu

#67

Post by KingMob »

Zambyte wrote: post #10
KingMob wrote: post #8

Earlier quoted context omitted.

Yeah, after the first month of jj, I abandoned git forever, because it's already so much better. There are some hiccups, though. I switched over to colocation for all repos, because too many things expect git directories to be where they expect. I think the revset language is cool and powerful, but if I'm honest, it's tempting me to spend too much time trying to master, when 99% of the time all I need is, "show me th…

> I think the revset language is cool and powerful, but if I'm honest, it's tempting me to spend too much time trying to master, when 99% of the time all I need is, "show me the nearby ancestors and descendants within k revisions". I just spend enough time to write a new function for what I want to do, and then just know the basics for regular day to day stuff. I feel like that gets me really far.

Yeah, I've done that as well. I wonder if the revset docs should be split into "Basic" and "Advanced" sections.

Re: A better merge workflow with Jujutsu

#68

Post by KingMob »

epage wrote: post #27
KingMob wrote: post #6

Earlier quoted context omitted.

> 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? The author is using newer terminology around "changes", but I prefer the older "revisions", as being less overloaded. But yes, the revision/change ID remains the same even if the commits underneath changes. `jj obslog` will show you the hi…

imo revision is worse. I feel like the best terms are patch id and patch revision id.

I mean none of the options are great, imo.

- "commit" is overloaded with git, and jj still uses commits for other things under the hood. - "patch id" is overloaded with patch files, and jj still uses git's snapshots, not patches (unlike darcs/pijul, iiuc) - "patch revision id" isn't bad, but it's a bit wordy - "change id" just seems vague, since it's unclear where one change begins and another ends

"revision" at least captures the idea that you are revising the same piece of functionality, but then you might expect each snapshot/commit to be a different revision, and not have the same ID, which also isn't quite right.

Re: A better merge workflow with Jujutsu

#69

Post by KingMob »

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 ?

> Are Jujutsu users all using it from the command line ?

Yes. Even with no UIs or editor support, it's already a better experience than git for me.

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

For tools that expect git, you can assist them by using a colocated repository, so they can still see git. It works well enough, though most of the time, they will think you're on a detached HEAD.

That being said, I avoid git's mutating operations. I've heard that can cause trouble.

Re: A better merge workflow with Jujutsu

#70

Post by KingMob »

whoomp12342 wrote: post #18

the core issue with GIT is this: it requires cognitive overhead. JJ doesn't seem to solve that.

I would say it's about the same. jj adds some concepts, like change/revisions and revsets, but it also has lower cognitive load than git on things like branches, the index, and the CLI. The ease of undoing anything alone makes it way easier to learn jj, since you can be fearless.

It's not quite clear to me how much simpler DVCS concepts can be.

Post reply on HN