Sorry for late response.
I had to reconvert the repository again, because I was completely unaware of the troubles that creep up with line endings. I already have written a post about that
viewtopic.php?p=75851#p75851 . Fortunately this problem is not really complex to solve, it just took some cpu hours to rewrite all text-ish file with LF line endings in the git history and a few minutes to find out how to check out the text files with the native line ending, keeping the special needs of visual studio and Xcode in mind.
Migration status (bold entries are new):
* The whole repository now roots in the FreeOrion directory.
* The /trunk/FreeOrion/WindowsKit.zip (Windows SDK for version v0.1 and v0.2) was deleted from history.
* The /trunk/DesignerTools was split into a separate repository. I guess we can delete it.
* All authors were renamed to their name given on github, sourceforge and the credits file, prioritized as listed.
* All authors emails were fetched from github and the SVN repository UUID, prioritized as listed.
* All branches were retained, except of /branches/python-integration, which were never merged back to /trunk and is really old.
* All branches were renamed consistently lowercase, replacing underscores with dashes.
* Open branch endings and beginnings were stitched to their corresponding split/merge commit, except /branches/release-0.4.4 as this branch was and should never be merged back to /trunk.
* All tags were retained and converted to annotated tags, except of /tags/RELEASE_V_0_1_INSTALLER, /tags/RELEASE_V_0_2_INSTALLER and /tags/start
* All version tags were renamed to match semantic version tagging vMAJOR.MINOR.PATCH
* All missing tags from
http://www.freeorion.org/index.php/Compile#Tarballs were added with Geoff as tagger, copying the commit date and the commit message to commit tagged.
* Enforced LF line endings for whole commit history.
* Added .gitattributes to apply proper native line endings when checking code out, normalizing text files to LF when checking in. Adding special cases for VS and Xcode specific files. Excluded binary files from line ending normalization.
* Stitched release v0.4.4 back into master (can be undone without much work, but please read arguments below).
* Applied most recent commits from freeorion:freeorion repository master branch with proper author, time and committer (No time traveling for you).
* Repacked the whole repository from 853Mb to 469Mb.
TODO:
* Add logging-migration branch from freeorion:freeorion-fixed to the new repository.
* Upload new repository
* Replace new repository
Vezzra wrote:I don't know... I mean there are some commits on a release branch you would not want to merge back into master (like the commenting out of test features like the super testers, changing some default settings that we want to be different in releases than in test builds etc). If you merge release branches back into master, you'd have to be careful to exclude these things.
Bigjoe5 wrote:In my experience, it is a bad idea to merge the release branch back into master. It's best to just make the call for each new branch whether to merge it into only master (features), only the release branch (release-specific bug-fixes/hacks), or both (general bug fixes).
The points you both are making is valid, but the argument behind it works in both directions. Considering the r8051 commit from SVN is about cherry-picking the change log from the v0.4.4 branch there can also be the case where change in the release branch must be part of the main development branch. Forgetting bugfixes or documentation on the release branche can't happen when merging it to the main development branch.
Finally this boils down to: "Be aware of what you're doing".
So stitching release branches gains us
+ All release branch only fixes will be part of master.
+ A working git describe.
+ Less branch clutter.
but
- All release branch only changes will be part of master.
Maybe it's the better approach to reduce the 'release branch only' changes in general, like, for example, instead commenting out/in super testers use some other mechanism to disable/enable cheats.
wheals wrote:So when branching, you'd tag the release branch with 0.4.5b (for "beta") and the master branch with 0.4.6a
It's a way to approach this problem, but keep in mind that this adds clutter to the tags and tags are mapped mostly to releases in github. It is a working solution, but IHMO it's not a tidy solution.
Vezzra wrote:Here is what I've done to fix the commit history in detail
Looks okay. Instead of uploading the repository you could have force pushed the master and logging-migration branch to the current repository instead.
Vezzra wrote:The impression is right, however, to be sure to preserve their commit history I've pulled them in before I made my fixed repo. If I had only pulled in master and logging-migration and fixed those, I'm not sure if my fixed repo would have lost the commit history of all the other branches. I'm, after all, a git newbie too still.
The commit history is kept even if you don't have local branches (or tracking branches) mapping to them. You have a local copy of them as long as you have the remote. The remote repository even doesn't need to exist for that.
Vezzra wrote:Once we've got this whole migration thing completed for good, we can remove all the branches that are no longer active. I guess... Marcel?
All branches (except release-v0.4.4) are merged back into master. So yes, all those branches can be removed without loosing anything (git would warn you anyway, if you want to delete a branch where not all commit are reachable from some kind of other ref (a tag or another branch).