i'm growing tired of these git alternatives. I feel like people should just learn to use git.
git is dumb. it's in the name. it's good enough, but it is not the best possible tool. neither is jj, but it's a damn fine improvement in some workflows.
What I've learned from jj
111–120 of 140 posts
Re: What I've learned from jj
#112Earlier quoted context omitted.
They are the same if you use squash merge.
modulo the commit message, which github apparently takes a lot of effort to not surface when needed; the most egregious example is that it's a complete afterthought to fill out right before the 'squash and merge' button becomes green.
You can make the PR description the commit message through configuration.
Re: What I've learned from jj
#113> 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…
>Working at $dayjob the unit of change is the commit, and every commit is reviewed and signed off by at least 1 peer.
Respectfully, that's the dumbest thing I've ever heard.
Work on your feature until it's done, on a branch. And then when you're ready, have the branch reviewed. Then squash the branch when merging it, so it becomes 1 commit.
Commit and push often, on branches, and squash when merging. Don't review commits, review the PR.
I've had people at various jobs accidentally delete a directory, effectively losing all their progress, sometimes weeks worth of work. I've experienced laptops being stolen.
If I used your system, over the years me and various colleagues would have lost work irretrievably a few times now, potentially sinking a startup due to not hitting a deadline.
I feel your approach shows a very "Nothing bad will ever happen" attitude.
Yes, of course you should have a backup. Most of those don't run every few minutes, though. Or even every few hours.
"Just trust the backup" feels like a really overkill solution for a system that has, as a core feature, pushing to a remote server. And frankly, a way to justify not using the feature.
Re: What I've learned from jj
#114Earlier quoted context omitted.
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…
whats N here?
In the case of git bisect, the number of commits. In the alternate case, it depends what debugging strategy you decided to use.
Re: What I've learned from jj
#115Earlier quoted context omitted.
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 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. You _never_ have bugs that slip through the test suite? That is extremely impressive / borderline impossible. Even highly tested gold-standard projects like SQLite see bugs in production. And…
Bugs that slip through the test suite and it's important to trace the origin and it requires building more than a couple best-guess versions to find it. And even then, if it wastes an hour or two once in a blue moon that's not a big motivator for workflow changes.
You're skeptical of a far stronger claim than the one they actually made.
Re: What I've learned from jj
#116Earlier quoted context omitted.
Squash merges simply guarantee that git bisect will not be able to pinpoint a breaking change, because that history is gone .
If you treat a PR as a unit of work, then there is nothing to bisect. If you don't treat it as a unit of work, then people just edit their git history to merge commits just like a squash.
> If you treat a PR as a unit of work, then there is nothing to bisect.
You're bisecting the history of PR merges.
Re: What I've learned from jj
#117> 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.
> A commit or a PR can be large. I don't see the difference.
They made it pretty clear they're talking about not-large commits. And they're contrasting that with any-size PRs.
Re: What I've learned from jj
#118Earlier quoted context omitted.
What's the difference between this and squash merging PRs? A commit or a PR can be large. I don't see the difference.
> A commit or a PR can be large. I don't see the difference. They made it pretty clear they're talking about not-large commits. And they're contrasting that with any-size PRs.
That's a false dichotomy, lurker. A PR or a commit can be large or small.
Re: What I've learned from jj
#119Earlier quoted context omitted.
> A commit or a PR can be large. I don't see the difference. They made it pretty clear they're talking about not-large commits. And they're contrasting that with any-size PRs.
That's a false dichotomy, lurker. A PR or a commit can be large or small.
It's not a false dichotomy. They're just using different terms than you would, based on their experience with how the people around them use those systems.
Re: What I've learned from jj
#120Earlier quoted context omitted.
That's a false dichotomy, lurker. A PR or a commit can be large or small.
It's not a false dichotomy. They're just using different terms than you would, based on their experience with how the people around them use those systems.
It's comparing carefully manicured git history hacking to unregulated PRs. It's pure dogma.