Follow

Another issue with GitHub's pull request model, which encourages you to "push new commits to your branch" rather than rebase to address feedback, is that it treats the pull request itself as the atomic unit of change. Where this falls apart is that, once it gets merged, the information in the pull request is lost, and an uncohesive set of "fixes thing" commits is a poor substitute for anyone browsing the git log.

Reminder that we have a guide to git rebasing that's helpful for avoiding this kind of problem: git-rebase.io

@sir Have you seen this? learngitbranching.js.org/

I've learned a lot from that one. I tend to give it to people.

Also magit, great tool. It made me better at git.

@sir I’m not wild about the mode either, but doesn’t changing the merge strategy to ff-only address this?

@djmoch @sir if you need to change your strategy how to work with the repository, because the tool requires you, the tool is broken, not your workflow!

@musicmatze @sir If I’m right, then calling it broken vis-a-vis this issue is overreach and the worst you can say is it lacks sane defaults.

@sir GitHub can squash and merge (project setting maybe?), producing a single commit. I suppose, this solves the problem of "fixing things" comments.

@oioi @sir But then it's harder to use git bisect to find problems because the issue may be in a very big commit.

@tomleb @oioi it doesn't *really* fix it unless you have the human touch making judgement calls on how the commits should be split up and merged

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!