Hacker News Reader

Comment by stavros | Hacker News Reader

I've been a developer for twenty four years. I've seen a lot of people have strong opinions about whether to merge or rebase, to squash or not to squash. I haven't seen one single time where it made a difference whether something was merged or squashed, as I've never seen anyone look at commit messages in depth, versus tickets or PRs or bisecting.

View on HN

I read 'git log -p' often, and linear history makes it so much easier. The same with bisecting. I'm yet to see any practical advantage of not allowing rebase/squash in feature branches. Preserving all history of feature branches is not an advantage to me. The history I care about is the history of the main branch and I don't want to see it splint into many tiny commits, especially not into commits looking like add/fix/fix/fix/fix where at all point except the last the code is broken.

The problem I run into is when a developer merges the main line branch into their feature branch repeatedly to get new changes. Now your branch is completely tangled up and difficult to change

I do this like... all the time. At least weekly for the last 5 years maybe? I can't remember a time where this has caused anything to get tangled or difficult.

Cherry-picking is harder. Splitting up the branch is harder.

I cherry pick occasionally. I don't see how it's affected at all? Edit: If another dev and I both cherry pick the same commit concurrently, that might do something weird. Maybe that's it?

I don't know what splitting up a branch means.

Let's say I'm working on a feature branch, and end up realizing I should really be opening two PRs because this one PR is going to be two hard to review. It's much more difficult to reorganize commits on your feature branch if you have merge commits from the main branch mixed in with your changes. If there was merge conflict resolution along the way as well - good luck making sense of things.

Merge commits 'lock' you in to the commits you've made so far.

https://lore.kernel.org/lkml/CAHk-=wjbtip559HcMG9VQLGPmkurh5...

Merges I create from the CLI don't really look that differennt from the ones through some forge UI PR process. I don't know what Linus is getting at. If I was working under someone who had a process like this, I could ask them to clarify what they wanted me to do. I don't have that. And I need to be able to justify all of my decisions. So this isn't useful to me.

I don't doubt that Linus has good reasons for all this. I just don't know what they are. And I don't know if they're applicable to other repos.

...why? Isn't this exactly what rebase is for? Just plain, boring, non-interactive rebase.

Maybe? But it's also what merge is for.

If I used rebase like this regularly it would become difficult to determine if a given commit is an ancestor of HEAD. Sometimes I like to do that.

Yes this is exactly what rebase is for, but a lot of developers do the merge based workflow.

For what it's worth, I often look at commits/commit messages in-depth.

I wouldn't do so if the history were a mess

I would like to do it more, but it's hard to convince people to not produce absolutely useless commit messages, and trust me I've tried.

Looking through my work project git log, it's a sea of random ticket numbers followed by absolutely nothing helpful or descriptive, usually just the title of the ticket if you're lucky.

Really?

I certainly have used commit messages and seen others do the same. Perhaps this is more an indictment of the quality of the commit messages than anything else.

In my experience, rebase and squash makes it easier to collect work into meaningful groups and thus write more helpful/informative commit messages.

I can think of a few times off the top of my head when I referred back to a detailed commit message in a repo to understand why a change was made.

If I'm making a change that people are likely to wonder about, I tend to add comments. Basically, anything that's not obvious tends to get a comment, change or no.

Reply on news.ycombinator.com