[Kde-scm-interest] Fwd: ideas to git conversion

[Johannes Sixt]

Raul Fernandes schrieb:
> 2008/12/4 Johannes Sixt <j.sixt at viscovery.net>:
> 
>> 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