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

[Frank Reininghaus]

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.

However, it seems that people follow a different approach now when
code is moved to a different repository - the entire history of the
code is being re-pushed to the new repository.

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, 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.

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

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.


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.

Opinions?

Thanks and best regards,
Frank

[1] I already asked about this in
http://lists.kde.org/?l=kfm-devel&m=139601591605309&w=2