[Kde-scm-interest] Re: git repo of kdelibs
Torgny Nyblom
kde at nyblom.org
Thu Nov 18 11:16:04 CET 2010
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
More information about the Kde-scm-interest
mailing list