Show HN: I made a git rebase TUI editor

Is there anyone else that enforces a simple "just squash & merge everything from PRs into main" across the entire team?

I'm comfortable git fooing w/e is necessary, but ever since we adopted this, git related conversations went to almost zero. It's great.

Yep, IMO this is always the best of the 3 strategies.

The PR is the unit of work, people get too hung up on the PR's individual commits.

Worst: rebase and merge - you end up with your coworker's broken WIP commits all over master, and have a terrible git revert story

OK: merge commit - you can revert, but there is a less intuitive `-m 1` flag (IIRC?) you have to pass into revert, and IMO you rarely need the intermediate history.

Best: squash & merge - you get one single commit representing the unit of work merging in, git revert is dead easy

Also setting the commit message in main to the `{title} (#{prNum})\n\n{prDescription}` format preserves all the good context from your PR and lets you get back to it if you need.

I generally dislike being told how to handle my commit history as 'i can do it better' - but this is really true.

Commit history on a (larger?) PR tends to be most useful during the PR itself; I tend try and make my commits tell a story I can walk people through (on the CLI during a call) moreso than anything that will be useful in 6mo/year.

I've been convinced on Squash/Merge. If the PR needs more granular commits; maybe it should be 2 independent PRs.

I do want something that will be intelligible for as many years from now as possible.

We constantly use that on the OSS project I’m occasionally involved with. “Well why is it like that…” and the project has enforced a good history so this can often be answered.

And that’s the primary benefit of Git. With some discipline the history becomes legible.

On the other hand it doesn’t give you much out of the box for code review. Unless the code review you use is covered by the email tooling.

Enforcing a good history can be as simple as writing a long commit message explaining things in detail. A good mental model is to default to a two-section message, explaining why a change is made and how it is made. And then when you squash & merge, include all of the detailed commit messages. Fun fact: at a previous company I'm in the top 1% for writing long commit messages.

Your commit message can be as long as it wants. If you squash twelve distinct changes you’re not going to see what part of the message corresponds to what change. Unless you invent some markup which points at the lines in the diff (but the diffs are dynamic so not something static you can count on). But at that point you’re doing so much work that you might as well use a regular merge.

Please if you have twelve distinct changes you are making twelve separate PRs.

Game of tag indeed.[1]

With Git you can work in, well, at least twelve different ways. But people discuss workflows with some built-in assumption that of course everyone else is using it like they are.

https://news.ycombinator.com/item?id=41839378

That's the point. This is not your individual repo[*]. This is a collaborative repo where different people contribute to it. It's a good thing that for each repo we standardize on the tooling and process. The individual's preferences are strictly subordinate to the team policy. And when something is team policy it is reasonable to assume that everyone indeed works the same way as they do.

FWIW for individual repos I don't even use PRs so the whole issue of how to merge them is moot.