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

[Torgny Nyblom]

On Thursday 18 November 2010 11.23.59 Ian Monroe wrote:
> On Thu, Nov 18, 2010 at 4:16 AM, Torgny Nyblom <kde at nyblom.org> wrote:
> > 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/396176a0d4c3a0d23ca17094c31
> >> afdcc7 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.
> 
> Which option do you think makes it the easiest to track a given file
> though history? From what you say it sounds like option #1. I think
> being able to give an easy answer to "hey, when did this code get
> here" is the most important thing. Accuracy is secondary, since we can
> keep SVN in storage somewhere for that.

Well  I guess the real question buils down do do people use log or blame to 
find where code originates from and should we take the opportunity to clean 
history?
 
> But as Niko points out, if the module opts to be split then the
> question is somewhat moot.

Only if the app has been 100% self contained from day 1.

/Regards
Torgny