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

71–80 of 140 posts

Re: What I've learned from jj

#71

Post by sam_bristow »

ajb wrote: post #42
marssaxman wrote: post #38

Earlier quoted context omitted.

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.

It's useful when the codebase is difficult to debug directly. Eg, your users have a bug that maybe appears on specific hardware, which the developers don't have. The users can't be expected to comprehend the code base enough to debug, but bisect is a mechanical process that they are capable of. Having said that, bisect is also an O(log N) method and it's useful where otherwise you might end up spending O(N) time debu…

Git bisect is one of those tools that - once you learn how to use it effetively - fundamentally changes how you think about your git repos. I have had people tell me that a clean git history isn't worth the effort but once they really grok what you can do with that solid foundation really come around.

One case where git bisect really saved me was when we discovered a really subtle bug in an embedded project I was working on. I was able to write a 20 line shell script that built the code, flashed the device, ran 100 iterations of a check, and do some basic stats. I left the bisect chugging away over the weekend and came back to an innocuous-looking commit from 6 months earlier. We could've spent weeks trying to find the root cause without it.

Re: What I've learned from jj

#72

Post by shakna »

matkoniecz wrote: post #67
MrJohz wrote: post #58

Earlier quoted context omitted.

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…

Fossil can purge certain checkins, but it isn't intuitive, and will throw away both what you want to remove, and anything that you wanted to keep. Its a bit of a manual rebuild.

Re: What I've learned from jj

#73

Post by ngrilly »

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…

> GitHub has introduced stacked PRs which queue up

I missed that. How does it work?

Re: What I've learned from jj

#74

Post by chrishill89 »

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…

Here’s the most relevant (to me) difference:

- The real unit of change lives in Git

- The real unit of change lives on some forge

I want it to live in Git.

Re: What I've learned from jj

#75

Post by chrishill89 »

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’ve just used it two times in the last few months. One was to track down a commit which triggered a bug I found in Git. I wouldn’t be able to troubleshoot it myself. And I couldn’t send the whole repository because it’s not OSS. But with a script to reproduce the bug and half an hour I was able to find the problematic change.

I also tried to make a minimal reproduction but wasn’t able to.

Re: What I've learned from jj

#76

Post by shandor »

sigmonsays wrote: post #46

i'm growing tired of these git alternatives. I feel like people should just learn to use git.

Why on Earth would these be in any way incompatible?

I’ve been using git for 15+ years,and definitely share the sentiment that basically everyone needs to learn it well as it is just that entrenched.

…but I love that people are coming up with potential alternatives that have a meaningful chance of moving the whole VCS space forward.

Re: What I've learned from jj

#77

Post by Thorrez »

EnPissant wrote: post #51
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…

What's the difference between this and squash merging PRs? A commit or a PR can be large. I don't see the difference.

I think it's the review process. Do you review 1 commit or multiple?

Re: What I've learned from jj

#78

Post by Thorrez »

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 don't use git much. But at my job, where we use mercurial, where the unit of work is commit, I use bisect frequently. When one of our automated tests starts failing, I can run bisect and easily find the commit that caused it.

Re: What I've learned from jj

#79

Post by andrewaylett »

ngrilly wrote: post #73
andrewaylett wrote: post #25

Earlier quoted context omitted.

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…

> GitHub has introduced stacked PRs which queue up I missed that. How does it work?

It's only available for orgs, not for personal repositories, and when we tried to use it in my team the size of our OIDC claim meant something broke so we had to turn it back off again :P. So I didn't get much experience with it.

But it seems like it gives you a place in a queue, meaning you don't need to keep rebasing as earlier PRs get merged: you can see what the state of the main branch should be by the time your PR reaches the head of the queue and develop accordingly.

https://docs.github.com/en/repositories/configuring-branches...

Re: What I've learned from jj

#80

Post by tome »

esafak wrote: post #49

When I'm developing I inevitably fix one thing after another as I pass through the code. What I'd like is a tool to take such PRs and automatically split it up into loosely coupled, cohesive chunks.

I have a tool called git-split for splitting commits: https://github.com/tomjaguarpaw/git-split/

I'm not sure you'd call it "automatic" though. Were you thinking of using an LLM to split the commits with some semantic awareness? It doesn't do that!

Post reply on HN