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

91–100 of 140 posts

Re: What I've learned from jj

#91

Post by esafak »

tome wrote: post #80
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!

It should be possible to do that with LLM integration. Consider it a feature request :)

Re: What I've learned from jj

#92

Post by overfeed »

marssaxman wrote: post #90
overfeed wrote: post #59

Earlier quoted context omitted.

How do you trace the origin of breaking changes, especially those arising from integration problems? For fairly busy codebases (>10 commits per day), and a certain subset of regressions, bisect is invaluable in finding the root cause. you can always do it the "hard way", so it's not the only way

I don't really ever find myself having to do that. I guess it's been a long time since I worked in an environment which did not use an "only merge to main after passing CI" workflow, and back then we weren't using git, anyway. There was one git-using startup I worked for which had a merge-recklessly development style, and there was one occasion when I could have used `git bisect` to disprove my coworker's accusation…

> I guess it's been a long time since I worked in an environment which did not use an "only merge to main after passing CI"

It's the same for me, but some integration bugs still escape the notice of unit tests. Examples from memory: a specific subset users being thrown into an endless redirect due to a cookie rename that wasn't propagated across all sub-systems on the backend, multiple instances of run-time errors that resulted from dependency version mismatches (dynamic loading), and a new notification banner element covering critical UI elements on an infrequently used page - effectively conflicting CSS position. In all these cases, the CI tests were passing, but passing tests don't mean your software is working as expected in all cases.

Re: What I've learned from jj

#94

Post by EnPissant »

chrishill89 wrote: post #74
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.

They are the same if you use squash merge.

Re: What I've learned from jj

#95

Post by EnPissant »

wtallis wrote: post #27
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…

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

Squash merge gives you the same thing.

Re: What I've learned from jj

#96

Post by ngrilly »

andrewaylett wrote: post #79
ngrilly wrote: post #73

Earlier quoted context omitted.

> 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…

Thanks!

Re: What I've learned from jj

#97

Post by doublerebel »

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?

Graphite app helps with stacked PRs and has a good explanation. Not affiliated just a happy user

Re: What I've learned from jj

#98

Post by hdjrudni »

verall wrote: post #63
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…

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…

I've never really used Github's PR system, always something else, but once in awhile I stumble in there in there from an opensource repo and they seem impossible to read with the individual commits.

Why doesn't Github just flatten/squash the stack of commits visually? Like I don't care what they're doing inside .git, can't they just diff the latest commit against the base commit and display that? So it's visually merged even if it's not merged in git's log?

---

At my work we do single commit. I find it annoying to work that way, I sometimes try to make clones of certain commits so I can restore to that point if I need to, but for reviewing, having everything in one neat little bundle, it's nice.

Post reply on HN