3 ms·

Is your statement about topic branches based on experience on a real product team with 5+ engineers working on the same codebase? If so, what's your preferred

Is your statement about topic branches based on experience on a real product team with 5+ engineers working on the same codebase? If so, what's your preferred workflow?

kazinator 11y ago
Can't speak for grandparent, but in my real product experience, every change its its own topic. Multiple related changes are reviewed as separate Gerrit items and merged separately. Sometimes out of order, and with other things intervening. Every change is built, and has to pass some smoke tests. The exception are external change sets (i.e. from open source upstreams). If you have some 53 commit feature from some kernel stream elsewhere that you would like to include, that doesn't turn into 53 individual cherry picks in the trunk. A topic "temp" branch is used for that, which is treated as one review item and merged. Very few git repos need this workflow; it wouldn't be used for anything developed in-house. If you have set of related changes, they are almost never the same "topic". Each change has its own topic. For instance, you'd like to implement some feature. But it requires refactoring of some code first. That refactoring is its own topic; it can go into the stream if your feature doesn't. The mere dependency of the feature on the refactoring doesn't make them the same topic. The team should be able to say: "hey that refactoring is a good idea, we approve it---but, hold it, there are issues with the feature requiring more work". So a situation is possible that the refactoring work goes into the stream, and other people's changes start to be based on it prior to the approval of the original feature it was intended for. The idea that several individual dependent commits are one topic is just the biased opinion of the original developer. What is true is that if some other stream wants the feature, then the dependent commits have to be picked up also. However, so what? The other stream can be so diverged already that it needs to pick up a truckload of other dependent commits for that feature to apply. In general, you can't just take a "topic branch" in isolation, only sometimes.

Is your statement about topic branches based on experience on a real product team with 5+ engineers working on the same codebase? If so, what's your preferred workflow?

kazinator 11y ago

Can't speak for grandparent, but in my real product experience, every change its its own topic. Multiple related changes are reviewed as separate Gerrit items and merged separately. Sometimes out of order, and with other things intervening. Every change is built, and has to pass some smoke tests. The exception are external change sets (i.e. from open source upstreams). If you have some 53 commit feature from some kernel stream elsewhere that you would like to include, that doesn't turn into 53 individual cherry picks in the trunk. A topic "temp" branch is used for that, which is treated as one review item and merged. Very few git repos need this workflow; it wouldn't be used for anything developed in-house. If you have set of related changes, they are almost never the same "topic". Each change has its own topic. For instance, you'd like to implement some feature. But it requires refactoring of some code first. That refactoring is its own topic; it can go into the stream if your feature doesn't. The mere dependency of the feature on the refactoring doesn't make them the same topic. The team should be able to say: "hey that refactoring is a good idea, we approve it---but, hold it, there are issues with the feature requiring more work". So a situation is possible that the refactoring work goes into the stream, and other people's changes start to be based on it prior to the approval of the original feature it was intended for. The idea that several individual dependent commits are one topic is just the biased opinion of the original developer. What is true is that if some other stream wants the feature, then the dependent commits have to be picked up also. However, so what? The other stream can be so diverged already that it needs to pick up a truckload of other dependent commits for that feature to apply. In general, you can't just take a "topic branch" in isolation, only sometimes.