121–130 of 140 posts
Earlier quoted context omitted.
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.
Earlier 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 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 th…
In the cases you mentioned, robust e2e and integration tests would ideally be able to catch the bugs. And for the UI issue in particular, I wouldn't think to track down the commit that caused it, but just fix it and move on.
Earlier quoted context omitted.
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.
But you also say it's pure dogma?
I'm confused.
Earlier quoted context omitted.
> If you treat a PR as a unit of work, then there is nothing to bisect. You're bisecting the history of PR merges.
You ignored the part where I claimed that without squash merging, people will just do it manually with git rebasing or amending.
I responded to the first case. Of course I ignored a claim you made about the second case. If I didn't ignore that, I would be making a strawman out of what you said, mixing up your words in a way that doesn't make sense.
Earlier quoted context omitted.
It's comparing carefully manicured git history hacking to unregulated PRs. It's pure dogma.
You agree that they are making a real comparison between two different things. But you also say it's pure dogma? I'm confused.
Because this is exactly what a squash merged PR is. There is no meaningful difference unless you say "but commits are done by good people and PRs are done by bad people".
Earlier quoted context omitted.
You agree that they are making a real comparison between two different things. But you also say it's pure dogma? I'm confused.
>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. Because this is exactly what a squash merged PR is. There is no meaningful difference unless you say "but commits are done by good people and PRs are done by bad people".
The preference they have is not exactly a problem with github PRs, but github PRs are much more likely to review a big pile of code at once.
The amount of code being reviewed at once is a meaningful and extremely objective measure, and that's the thing they're concerned with. Not who made it.
Earlier quoted context omitted.
>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. Because this is exactly what a squash merged PR is. There is no meaningful difference unless you say "but commits are done by good people and PRs are done by bad people".
They make it very clear that they are praising small commits, and squash merge commits are usually not small . Squashing is the opposite of what they want. The preference they have is not exactly a problem with github PRs, but github PRs are much more likely to review a big pile of code at once. The amount of code being reviewed at once is a meaningful and extremely objective measure, and that's the thing they're con…
I probably wont be able to respond to any more comments. Dang put a slowban on my account because he interpreted one of my comments as right wing.
Earlier quoted context omitted.
They make it very clear that they are praising small commits, and squash merge commits are usually not small . Squashing is the opposite of what they want. The preference they have is not exactly a problem with github PRs, but github PRs are much more likely to review a big pile of code at once. The amount of code being reviewed at once is a meaningful and extremely objective measure, and that's the thing they're con…
There is zero chance that any shop that reviews individual commits is not squashing them. I probably wont be able to respond to any more comments. Dang put a slowban on my account because he interpreted one of my comments as right wing.
But even if they're lying about achieving it, the preference they have for reviewing small commits is a preference that makes sense. It's not some nonsense "us versus them" thing.
I began using Jujutsu as my VCS about 2 months ago. Considering most of my work is on solo projects, I love the extra flexibility and speed of being able to safely fixup recent commits. I also love not having to wrangle the index, stashes, and merges. `lazyjj` [1] makes it easier to navigate around the change log (aka commit history) with single keypresses. The only workflow it's currently missing for me is `split`.…
Check out jjui - it is VASTLY better, and the dev is extremely open and responsive to feature requests. https://github.com/idursun/jjui
> You don’t need to explicitly tell jj about what you’ve done in your working copy, it’s already tracked. This removes the need for an “index” or staging area Does this mean that you have to proactively remember and undo any config file changes you made e.g. while fixing an issue in a test environment? Sounds a little risky.