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

81–90 of 93 posts

Re: A better merge workflow with Jujutsu

#81

Post by 0cf8612b2e1e »

arccy wrote: post #65
0cf8612b2e1e wrote: post #45

Earlier quoted context omitted.

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.

Maybe because I have never used an actual patch file, but patch just feels right to me. As an end user, a patch is an intentional delta blob resulting in some difference to the software. Writing software is just organizing those deltas. If I need to cherry pick between branches, pulling a patch from one to another feels more right than “changes” as a collective object.

Oh well, naming things is hard.

Re: A better merge workflow with Jujutsu

#82

Post by stouset »

dolmen wrote: post #66

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…

Yes, almost certainly. Jujutsu has an embedded mini-language to specify revsets. It’s not too hard to make a revset for “all branch names that are descendants of trunk (main/master)”.

You can feed this directly into `jj branch delete`, which will remove your local copy of each branch and flag them for removal from the remote during the next `jj git push`.

Re: A better merge workflow with Jujutsu

#83

Post by technojamin »

Jujutsu seems really cool, and I love that I can use it in a Git repository alongside other contributors that don't. It seems like a lot of logging features from Git aren't present, though.

Besides the mentioned lack of blame functionality[1], things like path filtering (`git log -- `), file-following with rename detection (`git log --follow -- `), pickaxe (`git log -S `), and range evolution (`git log -L,:`) are missing. These tools have all become pretty indispensable to me in my day-to-day work since I've learned them, and I know I can still use them since jj can use Git as a backend, but I don't think I could adopt a tool that doesn't have them as first-class features.

Do any regular users of Jujutsu have thoughts on this?

[1] https://github.com/martinvonz/jj?tab=readme-ov-file#status

Re: A better merge workflow with Jujutsu

#84

Post by OJFord »

KingMob wrote: post #8
FranGro78 wrote: post #5

Earlier quoted context omitted.

I’ve also run into problems with tools that aren’t worktree aware so often that I’ve stopped using it. I’ve been using jujutsu for about 6 months now, and the only time I’ve reached back for git was when I had to rebase and amend someone else’s branch to get it merged (when they weren’t available to do so themselves of course). Switching between changes in jujutsu has been a pleasant experience for me thus far, altho…

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 diffs need work. Or I need to get comfy with 3-way diffs. It's unfamiliar, and an obstacle to fixing conflicts.

You should get comfy, you won't regret it. I haven't got around to trying jj yet, but I use them in git; frequently see people messing things up or just having a hard time resolving a conflict that they wouldn't if they used (& understood) diff3.

In brief: a regular 2-way diff shows you the current state, and what you wanted to change to right? Well 3-way just adds an extra bit of information (the middle) which shows you from what state you were changing to the bottom.

So say you have:

  >>>>>> (deadbeef Abstract wazzle implementation to own package)
If you didn't have the middle, it might not be at all clear why you were getting the conflict, and what the appropriate fix is. It allows you to see that Ah ok, master (or whatever I'm rebasing on or whatever) has changed to return a bool indicating success or error, that's fine, I was just trying to change the wazzle method to pass it to a library function instead.

Or you might have it that the same change is already in the HEAD part at the top, but there's a conflict because they put the import elsewhere. The middle then allows you to see that you were making essentially the same change, you don't care where the import goes (or like their idea better), you can just remove it and stick with the changes on HEAD.

My point is that it's strictly more information, that can help or make it easier to resolve the conflict. It shouldn't be confusing at all, because the same 2-part thing you're accustomed to is there too.

Re: A better merge workflow with Jujutsu

#85

Post by sea-gold »

dolmen wrote: post #66

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…

A tool such as git-delete-merged-branches[1] may also be helpful.

[1]: https://github.com/hartwork/git-delete-merged-branches

Re: A better merge workflow with Jujutsu

#86

Post by OJFord »

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 can opt out with `git commit -a`

I wish you couldn't!

Re: A better merge workflow with Jujutsu

#87

Post by OJFord »

This is essentially GitButler's 'integration branch' idea, but via CLI. I tried it briefly, found it frustrating to use a GUI and not helped by (it's early days) bugs.

It occurred to me I could just do the same 'manually' or with some git aliases to help, but I haven't, and I'm glad I've seen this (and the reminder to try out jj in general) because it's certainly far nearer than it would be in pure git.

Re: A better merge workflow with Jujutsu

#88

Post by xlii »

bbkane wrote: post #78
arccy wrote: post #75

Earlier quoted context omitted.

the simple workaround would be to have .envrc optionally load another gitignored file if it exists, which sounds much safer than accidentally committing local changes, even with plain git.

If that's not possible, maybe OP can rename it to .envrc.example, and commit that. Then put in the instructions to rename .envrc.example to .envrc on checkout

Unfortunately neither of that worked, as those are multiple monorepos with different code owners. JJ is nice, but not worth that much of a work around it..

Re: A better merge workflow with Jujutsu

#89

Post by kubanczyk »

technojamin wrote: post #83

Jujutsu seems really cool, and I love that I can use it in a Git repository alongside other contributors that don't. It seems like a lot of logging features from Git aren't present, though. Besides the mentioned lack of blame functionality[1], things like path filtering (`git log -- `), file-following with rename detection (`git log --follow -- `), pickaxe (`git log -S `), and range evolution (`git log -L , : `) are…

> These tools have all become pretty indispensable to me in my day-to-day work

How much indispensable, in dollars?

Re: A better merge workflow with Jujutsu

#90

Post by technojamin »

kubanczyk wrote: post #89
technojamin wrote: post #83

Jujutsu seems really cool, and I love that I can use it in a Git repository alongside other contributors that don't. It seems like a lot of logging features from Git aren't present, though. Besides the mentioned lack of blame functionality[1], things like path filtering (`git log -- `), file-following with rename detection (`git log --follow -- `), pickaxe (`git log -S `), and range evolution (`git log -L , : `) are…

> These tools have all become pretty indispensable to me in my day-to-day work How much indispensable, in dollars?

What? That's a weirdly money-minded question. I'm not gonna do some Google interview-esque estimation question to answer that, but I'll elaborate on how I use those features, because I enjoy discussing them.

I use line range history the most, multiple times per day, since it's a much better alternative to line blame in most situations. You get the full historical context of a line instead of just the last commit.

File blame is really useful when I'm encountering new code, and I want to quickly find out who has the most "responsibility" over it, oftentimes so I can go and ask them about it if I need more clarification.

File history is especially useful when I come back to a file that I originally wrote or was familiar with, some time has passed, and now I want to re-familiarize myself with all the changes since the last time I was familiar (could be years). Rename detection is useful when there are repository-wide restructures, which has happened a couple of time in the main repository I work on. Otherwise, your history will cut off at that refactor, which is really irritating.

I use path history like file history, but to re-familiarize myself with large modules (admittedly less often than file history, but it comes up).

I'm newer to pickaxe, but I've used it 2 or 3 times in the past year to track some chunks of code throughout a refactor. That's how a lot of these little tools that Git has work. You might only use them a few times per year, but when you need them, they're really amazing.

It seems like Jujutsu focuses a lot on the commit authoring and modification flows, and it looks like it offers improvements in those areas, but I don't see much functionality in the history investigation area. They might be considered niche features to some, but I think this functionality becomes more valuable the older and larger a codebase gets.

Post reply on HN