Avoiding the merge trap

Posted Apr 19, 2023 21:42 UTC (Wed) by kleptog (subscriber, #1183)
In reply to: Avoiding the merge trap by taladar
Parent article: Avoiding the merge trap

Then I'm wondering what mean by a "topic branch"? In principle, one ticket is one patch unless it's something large. Bug-fixes are very small commits generally. New features also, but if they get larger you split it up across components, say, one for the API change, one for the frontend. The only times recently I've actually made what I would call a 'topic branch" was when we were doing a major refactor creating an entirely new component, that might require 10+ patches. For changes that require only a handful of patches I don't bother with a branch.

The only real criteria is that a single patch should be small enough to be easily reviewable, and must pass all the buildbot tests. Grouping patches by merging branches has always seemed like overhead to me. It's absolutely great that Git has merges and makes them easy, but I don't see how they add value the resulting history.

to post comments

Avoiding the merge trap

Posted Apr 28, 2023 6:34 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (1 responses)

> In principle, one ticket is one patch

Why?

There can be some refactor done while working on a certain area of the code, that isn't necessarily strictly the fix. If you put all in the same commit it's just harder to review for little reason.

Avoiding the merge trap

Posted Apr 28, 2023 11:11 UTC (Fri) by kleptog (subscriber, #1183) [Link]

> There can be some refactor done while working on a certain area of the code, that isn't necessarily strictly the fix. If you put all in the same commit it's just harder to review for little reason.

Sure, I did say "in principle". In my experience, the vast majority of tickets are single patch changes. If you're doing refactoring of course you split that out. Big changes should be split into logical components. It's a question of experience, you know what kind of thing you like reviewing. But every patch should build and pass the test suite.

In other words, I totally disagree with this proposal. This is working around a bad tool, squishing all the commits after the fact is terrible.

Avoiding the merge trap

Posted Apr 28, 2023 8:38 UTC (Fri) by laarmen (subscriber, #63948) [Link]

Topic branches are useful when you're working on multiple independent topics concurrently. It doesn't matter how many commits on the branches there are, it can be a single commit or dozens of them: while your patchset is being reviewed for inclusion you can switch to other topic branches to work on the other subjects.

To me, part of the value of a merge commit is that it records when and by whom the code was merged into the target branch.