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

What I've learned from jj

zerowidth.com

Post reply on HN
Print view View original

61–70 of 140 posts

Re: What I've learned from jj

#61

Post by arp242 »

epage wrote: post #30
cornstalks wrote: post #26

> The idea, particularly as realized in the GitHub pull request workflow, is that the real “unit of change” is a pull request, and the individual commits making up a PR are essentially irrelevant. I loathe GitHub PRs because of this. Working at $dayjob the unit of change is the commit, and every commit is reviewed and signed off by at least 1 peer. And you know what? I love it. Yes, there's some overhead. But I can u…

My ideal workflow is commits are as small as possible and PRs "tell a story", meaning that they provide the context for a commit. I will split up a PR into - Individual steps a a refactor, especially making any moves their own commits - I add tests *before* the feature (passing, showing the old behavior) - The actual fix or feature commit is tiny, with the diff of the tests just demontstrating how behavior changed Th…

One of the problems is that GitHub's UI and workflow isn't very good for this in various ways (can't review commits, can't really diff with previous after amending commit).

So as a rule, I tend to stick with "1 PR == 1 commit", except when there's a compelling reason not to.

Re: What I've learned from jj

#62

Post by arp242 »

marssaxman wrote: post #38
wtallis wrote: post #27

Earlier quoted context omitted.

Worrying about individual commits is also what makes it possible for you to later use git bisect without going crazy.

How often do you find that command useful? In ~18 years of git use, I have never needed it, but I see it mentioned often as an important reason to handle commits in some certain way. I wonder what accounts for the difference.

I used it a few weeks ago to track down a weird regression/bug in Firefox. A few years ago I used it to track down a regression in Wine.

That's probably the most important case: large complex codebases with lots of changes where "wtf is going on" isn't so obvious from just the code.

I've never used it for any of my personal projects or even at my dayjob, because they've much smaller with far fewer changes (relatively speaking).

Re: What I've learned from jj

#63

Post by verall »

andrewaylett wrote: post #25
KwanEsq wrote: post #5

Huh, reading the penultimate "“Units of change” and collaboration" section reinforces the feeling that Github PRs really are a poor way to do code submission/review, and have been holding back a lot of the industry from better ways of working for a long time.

GitHub-style PRs are the worst way of reviewing changes, except (in practice, if not in theory) for all the others :P. When my then-employer first stated using git, I managed to convince them to set up Gerrit -- I had my own personal Gerrit instance running at home, it was great. I think it lasted about a year before the popularity factor kicked in and we switched to GitLab. At least part of the difficulty is that ap…

I get to use both Gerrit (rebase-cherrypick workflow) and gitlab (PR/MR workflow) at work.

I think that MR is better for smaller projects i.e. ~10devs - it's lower overhead, just commit while you work then write up a description when you push.

I think rebase-CP is better for larger projects like ~100 devs committing to a repo - linear git history and every commit having a clear description+purpose+review is worth the overhead at that point.

So one-off tools and infra and stuff get chucked into gitlab while "the product" is in Gerrit.

Re: What I've learned from jj

#64

Post by rcxdude »

marssaxman wrote: post #38
wtallis wrote: post #27

Earlier quoted context omitted.

Worrying about individual commits is also what makes it possible for you to later use git bisect without going crazy.

How often do you find that command useful? In ~18 years of git use, I have never needed it, but I see it mentioned often as an important reason to handle commits in some certain way. I wonder what accounts for the difference.

Occasionally, but when it's useful, it's very useful. But generally only if most commits are buildable and roughly functional, otherwise it becomes a big pain (as does any manual process of finding what change introduced a regression).

Re: What I've learned from jj

#65

Post by nasso_dev »

manchmalscott wrote: post #45

I've tried out jj a little bit personally, but without exaggeration I am using git submodules in every single "real" project I'm actually working on, so lacking support for submodules is a complete non-starter for me :/

What I do is I git clone --recursive and then init a colocated repository. JJ will find the submodules and ignore anything in them, it works decently well.

Re: What I've learned from jj

#66

Post by matkoniecz »

marssaxman wrote: post #38
wtallis wrote: post #27

Earlier quoted context omitted.

Worrying about individual commits is also what makes it possible for you to later use git bisect without going crazy.

How often do you find that command useful? In ~18 years of git use, I have never needed it, but I see it mentioned often as an important reason to handle commits in some certain way. I wonder what accounts for the difference.

I used it multiple times to track down which commit introduced confusing bug.

Re: What I've learned from jj

#67

Post by matkoniecz »

MrJohz wrote: post #58
account-5 wrote: post #2

I would really love a comparison between JJ and fossil. I use fossil for personal projects instead of git. So I'd like to know if I should consider JJ.

I think the biggest difference is one of philosophy: in Fossil (as I understand it) every change you make to the code is tracked, and there's no concept of rebasing or making the history prettier. If you make a commit and then realise you've left some debug logs in the code, you've got to make a new commit to delete those logs. This has the advantage that you never lose data, but the disadvantage that all of those co…

> I think the biggest difference is one of philosophy: in Fossil (as I understand it) every change you make to the code is tracked, and there's no concept of rebasing or making the history prettier. If you make a commit and then realise you've left some debug logs in the code, you've got to make a new commit to delete those logs. This has the advantage that you never lose data, but the disadvantage that all of those commits end up in your long-term project history, making things like bisecting or blaming more difficult.

how you deal with accidental committing of text that was not supposed to be there (say, accidental pasting a private email)?

Re: What I've learned from jj

#69

Post by matkoniecz »

nonethewiser wrote: post #40

As entrenched as git is, I feel like its only a matter of time until it's dethroned. The basic workflow is fine. And there are some very powerful features. But then you try find the parent of a given branch and you're left wondering how the f#!@ thats so hard. It's definitely nit picking. It's probably 85-90% of what you want it to be. But there is definitely enough room for improvement to warrent moving beyond it. I…

> you try find the parent of a given branch

what you mean by that?

Re: What I've learned from jj

#70

Post by matkoniecz »

cadamsdotcom wrote: post #18

It’s clear from multiple posts over years that jj has a better UX than plain git. Why not just merge it into git?

personally, I am not interested in learning bunch of new interfaces to be - maybe - marginally more efficient

and deal with more abstractions layers if anything goes wrong

> It’s clear from multiple posts over years that jj has a better UX than plain git.

it is clear that multiple people like it

not that UX is strictly superior

Post reply on HN