[Kde-scm-interest] Re: git repo of kdelibs

[Torgny Nyblom]

On Thursday 18 November 2010 10.24.20 Niko Sams wrote:
> On Thu, Nov 18, 2010 at 09:07, Cornelius Schumacher <schumacher at kde.org> 
wrote:
> > Is there an experimental git repo of kdelibs already somewhere? Nothing
> > to actually work with for developing kdelibs, but just the kdelibs SVN
> > module in form of a git repo for some experiments.
> 
> Hi,
> 
> You can clone that one:
> git at huey.kde.org:nsams/test-complete/KDE/kdelibs
> 
> I ran the conversion about two weeks ago using that rules file:
> http://gitweb.kde.org/kde-ruleset.git/blob/396176a0d4c3a0d23ca17094c31afdcc7
> ddcd04c:/kde-rules-main
> 
> a quick look showed no obvious errors.

That depends on what you are aiming at.
After a quick look at those rules I get the impression that they ignore any 
history a submodule/lib/app has had outside the module they currently live in, 
or atleast put that history in a different repository?
Also they seem to cut history for quite a few of the apps they match in 
kdereview as the commit that deletes them there most likely will delete the 
entire master branch for the coresponding repository.

For kdepim we have three options for how the conversion should be done 
(descision has not been made yet)
#1 "Flat history": Each submodule/dir is followed as it is right now in HEAD, 
ie if a submodule was merged from a branch then the history of that submodule 
in trunk is lost for the duration of the branch. This seems to be how most 
people have converted atleast the single application migrations so far.

#2 "Branch history": History is keept as close to the original history as 
possible, ie branches are branches. but not all are complete in the git sence 
as they might just contain a single subdir.

#3 "Pure module history": Any time a submodule has spent outside the current 
module is discarded.

The most attractive option (atleast to me) is #2 but "git log" has trouble 
following history due to a bug that makes it loose parent commits somehow. 
However "git gui blame" follows history correctly.

Due to this (and perhaps the young age of some pim modules) option #3 is more 
or less out for pim.

I think it would be nice if more peolpe could give there input on what they 
persive as the best alternative and then we should strive for using that 
accross the entire KDE code base.

/Regards
Torgny