RFC: Do we want the entire commit history to be pushed if code is moved to another repository?

[David Faure]

On Saturday 26 April 2014 09:20:08 Frank Reininghaus wrote:
> Hi everyone,
> 
> when kdelibs was split into the different frameworks repositories, the
> git history was dropped. I think that this was a good idea - splitting
> the history properly would have been an extremely complex task, and
> everyone who wants to do source code archaelogy can just look at the
> kdelibs history after all.

... or they can set up git graft in the framework repos, as documented in the 
initial commit.

> Examples of this are the move of the about kioslave to kde-baseapps (I
> noticed it this morning because of all the commit emails I got, many
> of which are 1-line changes from 2006), and the recent move of
> kpasswdserver to kio [1].
> This is inconsistent with the kdelibs approach

No it's not. This is a different issue: how to *merge* code (with the history) 
from a module to another.

The kdelibs (and qt) splitting is an easier case: making a brand new git 
module, with history pointing back to the initial module after git graft.

> , and I see several reasons not to do it:
> 
> 1. It makes using tools like git log, qgit or gitk for browsing the
> recent history extremely painful if lots of 10-year old commits are
> shown on top.

It will do the same in any framework if you set up git graft.
But yes, at least that is optional, while the history brought over when moving 
subdirs is not.

> 2. People who receive commit notification e-mails for a repository get
> lots of noise in their inbox.

Yeah there's a bug somewhere, I'm not sure why I got some emails in my inbox 
(as opposed to properly filtered).

> OTOH, the only reason to push all those old commits to the new
> repository would be to make browsing the history easier, but as the
> kdelibs splitting approach shows, this can also be done in another
> way.

Finding the old module will be kind of hard in the far future, unless it's 
very well documented in the initial commit, as you suggest below.

> I would like to suggest the following approach for situations like
> this in the future:
> 
> If code is moved to a new repository, then the current state of the
> corresponding directory from repo A is pushed to repo B in a single
> commit. The commit message should indicate how one can find out about
> the history of the code, i.e., which repository it is from, and what
> the commit hash is.

I would be OK with that, I guess.
But I'll let those who do the work (e.g. Alex Merry) have the final word.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5