Having a clean and coherent git history
Opened this issue · 2 comments
Hi, the current git history is weird. First thing, svn did not know what is an author/committer address so this information is missing. Second thing, There is plenty of useless anonymous empty commits done by a previous cvs2svn conversion. And there is some other issues too.
cleaning the noise
I've rebased the whole history on a personal branch:
The useless anonymous commits by cvs2svn are gone, and some redundant initial commits are squashed up. For example, the 6 commits between the first and the 8th are just pure noise.
crediting authors
I've used this conversion table to credit authors:
l-n <l-n@bac25679-d237-0410-bec6-f8029acc7ebe>
→Ludwig Nussel <ludwig.nussel(ad)suse.de><stevejankowski@bac25679-d237-0410-bec6-f8029acc7ebe>
→Steve Jankowski <stevejankowski(ad)yahoo.com>smolarek <smolarek@bac25679-d237-0410-bec6-f8029acc7ebe>
→Pierre Smolarek <smolarek(ad)users.sourceforge.net>
The direct consequence is contributors will be automatically linked if they are on Github too.
You can see as an example how Ludwig Nussel was automatically recognized.
Also, contributors will be automatically added to the QStat's contributor page.
You can see how it looks on the XQF's contributor page, contributors from the past were automatically recognized, even if they contributed only one commit.
So, in this history rewrite for Qstat, author date and committer date are preserved, committer name and email use author mail and email. If you know better email adresses for Steve Jankowski and Pierre Smolarek I can rewrite them.
release tags
I've added release tags: https://github.com/illwieckz/qstat/releases
problems and solutions
There is just a big problem, the whole history is rewritten, so you can't merge that change, you must force-push it which is bad when a repository is well-known and have many forks because it break merge. But currently, this not a problem for the QStat git repository. 😉
It's a problem for forks, they will not be able to merge after the rewrite. But I'm probably the only one who have some forks to merge, so I'm ok to handle this case myself. I'm already merging by hand a fork which were never based on the current git repository, so, the problem is already there.
If you want to rewrite the history, we just have to notice the rare people who have forked it to just drop their fork and to refork them. Github knows only 3 public forks, one of them is me, the second is well behind the current master and the third was just created yesterday and we are in touch with him.
So, since the repository is not yet known, if you want to do it can do it now, later will be too late.
There is one issue remaining, if one maintainer from a distribution have configured a package build procedure to checkout one specific commit. There is a solution to that: you can branch your master before rewriting it and keep this branch online for historical purpose.
Happy to do this if you can detail the full command line steps
git clone https://github.com/illwieckz/qstat.git -b rewrite-history- Apply all commits from this repo after bca7d6b.
2.1.git format-patch bca7d6b..in old repo dir.
2.2. Move all patch files to Thomas' repo dir.
2.3.git apply {*}.patchin Thomas' repo dir - Change origin to this repo and do force push.
3.1.sed -i 's/illwieckz/multiplay/g' .git/config
3.2.git push --force