Andreas Pakulat wrote: > On 16.02.11 00:12:16, Stephen Kelly wrote: >> Hi, >> >> I've added a section for proposed workflows. I think eean wants to create >> a couple of proposals too. >> >> http://community.kde.org/20110213_GitWorkflowAgenda#Proposed_workflows >> >> Please poke holes in mine and let me know if something just won't work in >> it: >> >> http://community.kde.org/20110213_GitWorkflowAgenda/StevesIdea > > Whats missing in that idea is why rebasing all the time should be better > than merge'ing?
Well, 'all the time' is not really true. I say it's preferred. I can't think of any normal cases where merging is definitely better. I would call a long lived branch with a lot of contributors an exceptional case by the way. > Also your proposal creates a purely linear history in > master, which means you're completely loosing the information that > certain commits belonged to a topic-branch. If you really think that's useful information to have, then merge with --no- ff. I don't know if it can be enforced technically (the tip of a push must have two parents or whatever. That would be very annoying), but if it can't, having to make it visible from in the history that certain commits were in a topic branch once can never be more than a recommended policy. You can do it, sure. You can even propose a workflow where it's recommended. > This may be useful in some > cases when looking at history as one can easily discard a whole sequence > of commits easily by seeing they're coming in through a merge from a > topic-branch. That depends entirely on why you are looking at the history. If you're looking for something specific and you happen to know that it didn't happen in that topic branch then fine, you might be able to skip a small number of commits, but that's a bad idea because you assume the topic branch is strictly on topic. What if I do some bug fixes in the branch as well as what the topic is about, and that happens to be what you're looking for? Can you rely on everyone in kde to keep topic branches strictly on topic? The only way you'd know is by looking through the commits in the branch, and then the benefit you claim is gone. To me that benefit seems like a major what-if scenario that is not useful in normal cases. Sure, maybe there's exceptional cases where it is useful. I think we should focus on benefits to the normal cases. In normal cases I'd much prefer to see small commits refactoring, then adding features instead of large commits experimenting, and fixup commits etc just for the reason that 'that's what actually happened'. Creating a nice stream of commits makes it possible to find out whether refactoring introduced the bug or was it the new feature. Steve. _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
