Raul Fernandes schrieb: > 2008/12/4 Johannes Sixt <[EMAIL PROTECTED]>: > >> because if a fix is applied to the oldest live branch, then it will have >> to be merged into the later live branches: > > I think that the fixes is generally backported, not the way you said. > In any case, the merge is not the solution. It has to be > cherry-picking (getting one patch and applying to other branch).
Bad habits don't need to perpetuate. Backports are the absolutely wrong workflow. This workflow only exists because SVN does not help you with forward merges. In git workflows, cherry-picking a fix back to a maintainance branch is a sign that the maintainer didn't plan ahead carefully enough, and is the absolute exception. > When another new stable branch is out, another repository will be > create with the history until the point of *fork* and the work > continues in the *main* repository. With "another repository", do you mean a new history? So to say, start with a fresh import? This won't cut it. It makes merging more difficult than necessary. As has been said, if you don't want history, use clone --depth=1. >> Fair enough. 3.5 *is* a completely different beast. > > It's I talking about. It's like another project. Why do we want a copy > of the whole history in each developer's computer?? It's useless. I do agree that KDE 1 and 2 and by this time even perhaps KDE 3 history is uninteresting (and can be cut off). But /useless/? Not in the least. Have you ever had the chance to appreciate git's code archeology capabilities? It's just the contrary: Project history is worth every ton once you look at a piece of code and you have to ask "why the heck was this done this way?" -- Hannes _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
