GitHub migration procedure

Discussion about the project in general, organization, website, or any other details that aren't directly about the game.
Message
Author
User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: GitHub migration procedure

#106 Post by Vezzra »

Geoff the Medio wrote:done but I don't presently have a way to view the log, so feel free to check it...

Code: Select all

Commit: 0f901e2d792de4377e85e2976c813f30588b64bf [0f901e2]
Parents: d0f68df641
Author: Geoff <[email protected]>
Date: 25. März 2015 23:22:12 MEZ
Labels: origin/geoffthemedio-patch-1

testing what happens when adding a file using the web interface
So, if you want your gmail address to be used when committing stuff through the github web interface, I guess you need to set it as primary (which, if I understood correctly, you've already done), and also uncheck that "Keep my email address private" checkbox. I guess it's only the email address you set as your public one that gets exposed anyway. But you can't keep it private and have it used for the commit log at the same time.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: GitHub migration procedure

#107 Post by Geoff the Medio »

[email protected] would be fine. I suspect most commits will not be done through the web interface, though.

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: GitHub migration procedure

#108 Post by Vezzra »

Geoff the Medio wrote:I suspect most commits will not be done through the web interface, though.
Will happen mostly when merging pull requests (unless you go the manual route: pulling the pull request to your local machine and pushing from there to our repo).

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: GitHub migration procedure

#109 Post by Vezzra »

adrian_broher wrote:It should be done tomorrow.
I just wanted to note that I won't be able to do FO stuff during the afternoon and evening today until I get back home, which might be quite late. So, in order for you to be able to proceed more independently without having to wait for me to do stuff you don't have sufficient access rights for, I just created the (temporary) "Migration" team, which is in charge of handling the migration process.

I gave that team admin rights and added Geoff, Dilvish, you and myself to it. That way you should be able to move the repo you're going to create into the freeorion organizational account. I also added the current freeorion/freeorion repo to the team, I hope that will enable you to rename it (please don't just delete it, so we can compare the results of both import attempts), so you can put the new repo as the freeorion main repo in its place. If you need anything else, just ask, I should be around till early afternoon, after that you're on your own - well, not really, I hope Geoff and/or Dilvish will be able to help too. ;)

Once we are done with the migration for real I will remove the "Migration" team.

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: GitHub migration procedure

#110 Post by adrian_broher »

I'm currently pushing the cleaned up repository to my github account and this needs some time so I'm off for the gym now.

https://www.github.com/adrianbroher/freeorion/

Things I changed:
* 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.
* Repacked the whole repository from 803Mb to 469Mb.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: GitHub migration procedure

#111 Post by adrian_broher »

I transferred the ownership to freeorion

The repository is now available as freeorion/freeorion
The old repository is now available as freeorion/freeorion-backup2
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: GitHub migration procedure

#112 Post by adrian_broher »

Geoff, pls staph!

I'm trying to pick the old commits from freeorion-backup2 here
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: GitHub migration procedure

#113 Post by Geoff the Medio »

adrian_broher wrote:Geoff, pls staph!
OK, sorry; Apparently I misinterpreted the meaning of "repository is now available"...

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: GitHub migration procedure

#114 Post by adrian_broher »

It's okay now.

Apparently you have gained time traveling abilities in the meantime.

Vezzra authored a day ago
geoffthemedio committed on 25 Jun 2008
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: GitHub migration procedure

#115 Post by Geoff the Medio »

The commit / version string I get with the new repository is something like "v0.4.3-1677-g23c3f2f". Presumably it should start with v0.4.4 or v0.4.4+

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: GitHub migration procedure

#116 Post by adrian_broher »

Geoff the Medio wrote:The commit / version string I get with the new repository is something like "v0.4.3-1677-g23c3f2f". Presumably it should start with v0.4.4 or v0.4.4+
The v0.4.4 branch is not a direct predecessor of the master branch.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: GitHub migration procedure

#117 Post by Vezzra »

adrian_broher wrote:I'm trying to pick the old commits from freeorion-backup2 here
That wouldn't have been strictly necessary - I'm surprised that there have been any significant commits anyway (aside from some test commits and my commits adding the README.md and .gitignore). But thanks! :)

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: GitHub migration procedure

#118 Post by adrian_broher »

adrian_broher wrote:The v0.4.4 branch is not a direct predecessor of the master branch.
I could stitch the commit back into master, but that would require a new import.

Another issue creeped up:

https://github.com/freeorion/freeorion/ ... 9824e59107

As you can see the whole CMakeLists.txt shows up as changed. Probably this is causes by different line endings. Geoff, what tool did you use to edit the files in this commit?

We maybe need to set up a gitattributes file to properly fix that.
https://help.github.com/articles/dealin ... e-endings/

See also
http://adaptivepatchwork.com/2012/03/01 ... your-line/
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: GitHub migration procedure

#119 Post by Vezzra »

adrian_broher wrote:It's okay now.

Apparently you have gained time traveling abilities in the meantime.

Vezzra authored a day ago
geoffthemedio committed on 25 Jun 2008
Ok, that seems to have screwed the commit history a bit:
StrangeCommits.png
StrangeCommits.png (104.28 KiB) Viewed 1409 times
Thats on the first page of the commit log. TBH, this looks quite weird, and it also screws the commit log graph in my git GUI client (SourceTree), when I switch the display mode to "date order" - because ancestor order and date order are in conflict now.

Is there any way to fix that...?

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: GitHub migration procedure

#120 Post by adrian_broher »

Vezzra wrote:Thats on the first page of the commit log. TBH, this looks quite weird, and it also screws the commit log graph in my git GUI client (SourceTree), when I switch the display mode to "date order" - because ancestor order and date order are in conflict now.
Yes, that was a little screw up by me. When I added the missing tags for v0.4.2, v0.4.1, … I didn't want to be the tagger and the tagging date shouldn't be 'now'. So I tested how to change the tag date and author by exporting the environment variables GIT_COMMITTER_DATE, GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL. I forgot to unset those after my test. git am (the tool I used to pick the commits from the other repository) also respects the values of those environment variables… which lead to the hiccup you can see there.
Vezzra wrote:Is there any way to fix that...?
We could do another re-import, fixing this and merging v0.4.4 to create a more beautiful commit version like

Code: Select all

$ git describe --always
v0.4.4-556-g3648957
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

Post Reply