How was the (git) history flattened?

Question

How was the (git) history flattened?

LynxAbraxas opened this issue 6 years ago · 34 comments

Cool to see some work done on a linux port. I had worked on the svn linux branch some years ago and had that ported to git by github's svn import: https://github.com/LynxAbraxas/ctp2
It seems you did port to git somehow differently such that only the very first commit is the same in both repos. Furthermore your port somehow "flattened" the history of various branches all into one, where e.g. those from the original linux branch are empty commits (i.e. the changes to files got lost), compare e.g. these same commit messages, dates:
03a905a (0 changed files)
and
https://github.com/LynxAbraxas/ctp2/commit/29994a179e080b5a244411c2294d4b47a7a1b3bd (198 changed files)
So it seems you basically did a new port to linux, missing the changes already done on the original linux branch, which could e.g. be the reason for the missing resolutions (#1).

There have been quite a few tries to merge the original master and the linux branches ( https://github.com/LynxAbraxas/ctp2/branches), the latest was port-trunk. I once considered merging with git-imerge, but so far had not the time to try. I think a clean way of getting the old stuff and your new contributions together would be to do a merge (with e.g. git-imerge) of the original master and linux branch and then rebase your new commits on top of that. It seems imerge could even handle merging your current master with the original linux branch, but the resulting history would be very screwed then due to the different commit SHAs for the same commit content.
What do you think? Would you want to give it a try?

PS: There is one other github repos for ctp2 (https://github.com/talentlesshack/C2P2) which was also imported differently and lacks all branches except master but seems to have some more commits in common than only the very first, not sure how that git port was done.

Answer 1 · 2018-10-06T16:15:30.000Z

Well, I don't remember much how I did. I think I just got the svn version somewhere and simply create a new git from that. Also, I think I manualy "merged" the latest version of trunk (so windows only) with (your?) linux changes, to have the most up-to-date version to work with.

That's not how your are supposed to do, I know :( sorry about that.

Now, about what your are proposing. Well, I'm ok I guess (but as you probably already understood, my git-fu isn't that great), and I'm unsure what will be the aim: send all the linux changes back to the linux branch of the svn repo? And then merge that branch to trunk so only one source for windows / linux exist?

Answer 2 · 2018-10-07T15:36:44.000Z

Well, I don't remember much how I did. I think I just got the svn version somewhere and simply create a new git from that.

Hm, to my understanding that could be the source for the mixup, but I am not sure. As far as I know it would be best either to log into GH and at the + button choose import repository and then supply the svn URL. This way GH does the import and apparently quite a good job, except that the SHAs do not turn out the same for corresponding commits if you or someone else does the same again. That way the git repos do not sync as they could.
I just tested if using git svn prevents this problem and it seems it does. I converted from svn to git (see below) mulitple times and always got the same SHAs. Therefore I would recommend to go with git svn, tough I have not tested any of the various svn2git tools.
Any way we should agree to a main git repos to work with and for others to fork from in order to be able to contribute back. I would prefer if it would not be me, because I have a tendency to get adicted to woking on ctp2 code... @DarkDust what would you recommend?
In any case it would be good if @DarkDust could add info about the git repos agreed on in the SVN info page to avoid contribution clashes. For example there are new svn commits by Manuel Selinger that are similar to @ptitSeb contributions which I guess originated from not knowing about the others. @DarkDust do you konw if Manuel Selinger is at GH (could not find him with his svn commit name) or could you point him to this conversation?

Also, I think I manualy "merged" the latest version of trunk (so windows only) with (your?) linux changes, to have the most up-to-date version to work with.

To my understanding your version is missing all changes from any other branch than master/trunk it only containes empty commits (like the one I pointed out above, identical in message, date and author but without any file changes) which fake the impression the changes are considered.

That's not how your are supposed to do, I know :( sorry about that.

No problem, one learns as one goes ahead, and here not only git-fu but also svn-fu is needed (which I mostly lack). I often wonder what odd commands or commits I did 10 years ago... Anyway, you are free to do what you want with open source but I would find it a pity if the very few efforts on ctp2 for linux would not be synced, and it seems we are very close to have it all wrapped up.

Now, about what your are proposing. Well, I'm ok I guess (but as you probably already understood, my git-fu isn't that great), and I'm unsure what will be the aim: send all the linux changes back to the linux branch of the svn repo? And then merge that branch to trunk so only one source for windows / linux exist?

As it appears to me, you only used the code from svn trunk. Your conversion to git just added empty commits from all other branches into master. E.g. 8437856 is also empty and originates from branch port-trunk.
Have a look at the graph of the history with e.g. gitk --all or in GH under network. Yours is one line (https://github.com/ptitSeb/ctp2/network) while the one from either GH import (https://github.com/LynxAbraxas/ctp2/network) or using git svn (https://github.com/LynxAbraxas/ctp2_git-svn/network) has 5/6 branches and 13 tags/releases (scroll to the left by dragging the mouse or with the <- key).

For https://github.com/LynxAbraxas/ctp2_git-svn I followed https://stackoverflow.com/questions/2244252/how-to-import-svn-branches-and-tags-into-git-svn

git init ctp2
cd ctp2

git svn init -t tags -b branches -T trunk http://ctp2.darkdust.net/anonsvn/
git svn fetch

# convert tag-branches to git tags and delete tag-branches
git for-each-ref --format="%(refname:short) %(objectname)" refs/remotes/origin/tags |
 while read BRANCH REF;   do         
 TAG_NAME=${BRANCH#*/*/};         BODY="$(git log -1 --format=format:%B $REF)";         
 echo "ref=$REF parent=$(git rev-parse $REF^) tagname=$TAG_NAME body=$BODY" >&2;          
 git tag -a -m "$BODY" $TAG_NAME $REF^  &&        git branch -r -d $BRANCH;   
 done

# checkout of each remaining branch once
git for-each-ref --format="%(refname:short)" refs/remotes/origin | 
 while read i; do git checkout $i -b ${i#*/}; done

# create GH repos and add as remote
git remote add origin https://github.com/LynxAbraxas/ctp2_git-svn

git push origin --all
git push origin --tag

After using git svn I added your repos as a remote and rebased you commits onto the last commit in common with svn trunk (https://github.com/LynxAbraxas/ctp2_git-svn/commit/ef644f69fd9002a3cb31bc45cd9fae057d58b13d) which did not yield any problems.

git remote add ptitSeb https://github.com/ptitSeb/ctp2
git fetch ptitSeb 
git checkout ptitSeb/master -b ptitSeb

git checkout master
git reset --hard ef644f69fd9002a3cb31bc45cd9fae057d58b13d #reset to last common commit
git rebase --onto master 62bd6ef8073507ceb7d7691f679c6d2ec6d8bb01 ptitSeb #rebase your commits

git push origin master -f # needs force push due to de-sync with trunk
git push origin ptitSeb

Due to the commits from Manuel Selinger ptitSeb, master and trunk are currently out of sync, which might be problematic for committing back to svn with git svn dcommit.
As I did the rebase, committer and author are not the same any more. Feel free to re-do the steps to preserve yourself as the committer (only commit and author date will differ then, see e.g. gitk).

We can then consider how to best merge things, e.g.:
master with linux (using e.g. git-imerge) and then rebase ptitSeb on top
or
merge master with ptitSeb (fast forward) and then imerge with linux (possibly more work)
or
merge master with ptitSeb and selectively cherry-pick commits from linux that have not yet been ported to master (some already were).

Answer 3 · 2018-10-07T22:21:01.000Z

Hi @LynxAbraxas and @ptitSeb

I had a look at existing ctp2 repos on GH and these are the repos I managed to find:

@ptitSeb's repo: https://github.com/ptitSeb/ctp2
@LynxAbraxas' repo: https://github.com/LynxAbraxas/ctp2
@RolandTaverner's repo: https://github.com/RolandTaverner/ctp2
@jleclanche's repo: https://github.com/jleclanche/darkdust-ctp2
@talentlesshack's repo: https://github.com/talentlesshack/C2P2

I fetched them all to one repo and did some analysis.
Here are my findings:
The last common change in all repos (on master branch which is the only one that all repos have) is:
"Failed slave raids cannot be heard anymore".
This change has different SHA1 hashes in each repo due to svn import, which are:

9d916e926434 in @LynxAbraxas' repo
d14c3a059b38 in @RolandTaverner's repo
6e0bb2a in @ptitSeb's repo
1c31cbcd5383 in @jleclanche's repo
77293b372439 in @talentlesshack's repo

I verified however that they all have exact same content: git diff for every pair shows no differences.
It may be good idea to base all further development on that commit, or alternatively on "Before doing anything else, let's clean up the vast amounts of white-space ...", which most repos have too (although not all in the same order for this one).

Now some comments about those different repos:

@LynxAbraxas, @jleclanche and @RolandTaverner repos are equivalents with regard to following branches:

linux
linux-merge
linux-rework
port-trunk

All seem to be imported from SVN using the same or similar method, and all those equivalent branches have identical content (i.e. git diff shows no differences), but of course still have different SHA1s.

Only @ptitSeb and @RolandTaverner have significant extra work done on master branch
@ptitSeb version seem to be working but changes are based on different (flattened?) import from SVN (empty commit etc.) and only has master.
@RolandTaverner seem to be properly exported (all the branches as in @LynxAbraxas, @jleclanche), but I have not examined his changes on mater.
@talentlesshack also has only master (added one extra commit with README file), but this is the only one exported with SVN references (SVN metadata included in export?)
which may possibly be helpful in some cases. For example, tip of the linux-rework branch is:

Author: richardh <richardh@34d2fc0c-33df-0310-8a34-85f8040ba873>
Date:   Sat Jan 13 23:31:11 2007 +0000

    Merged up to and including r390.

I can easily find this revision in @talentlesshack's repo thanks to SVN references:

$ git log --grep trunk@390 talentlesshack/master
commit 0af2464c2aa664253f5fc8c6ac720bcca8b84ab1
Author: Fromafar <Fromafar@34d2fc0c-33df-0310-8a34-85f8040ba873>
Date:   Mon Jun 20 21:04:33 2005 +0000

    AOM support added, crashes repaired
    
    git-svn-id: http://ctp2.darkdust.net/anonsvn/trunk@390 34d2fc0c-33df-0310-8a34-85f8040ba873

Now, in order to have correct history and also @ptitSeb's changes, I took two different approaches:

rebase @ptitSeb's changes onto @LynxAbraxas' master
merge @ptitSeb's changes into @LynxAbraxas' master

Rebase result is in my repo (https://github.com/DEVoytas/ctp2) on branch ptitSeb_master_rebased_onto_LynxAbraxas_master and it's content is exactly the same as original ptitSeb/master branch.
I.e. output of:
git diff --name-status ptitSeb_master_rebased_onto_LynxAbraxas_master ptitSeb/master
is empty.
This is due to (as mentioned above) base commits "Failed slave raids cannot be heard anymore" are the same in all repos.

For merge, which is on branch ptitSeb_master_merged_to_LynxAbraxas_master. I had to create artificial common commit combining both histories (more details on it in commit message).
The merge result is very similar to what is on ptitSeb_master_rebased_onto_LynxAbraxas_master (and ptitSeb/master) with some minor white space differences.
If someone pulls this merged branch it will probably results in having histories from both repos fetched.

I hope it's going to helpful to someone, and waiting for your feedback.

Answer 4 · 2018-10-07T23:22:47.000Z

For https://github.com/LynxAbraxas/ctp2_git-svn I followed https://stackoverflow.com/questions/2244252/how-to-import-svn-branches-and-tags-into-git-svn

Oh, now I realized you created another repo which also have advantage of SVN references (as @talentlesshack's repo I mentioned above).
I think this is probably the most proper way of exporting SVN to git so maybe that repo should be used as base for further changes?

Due to the commits from Manuel Selinger ptitSeb, master and trunk are currently out of sync, which might be problematic for committing back to svn with git svn dcommit.

Do you have access to SVN repo? If yes we could create 'trunk' branch in git that would track changes in SVN and we could merge back those changes to master.

As I did the rebase, committer and author are not the same any more. Feel free to re-do the steps to preserve yourself as the committer (only commit and author date will differ then, see e.g. gitk).

This is weird. If you rebase the changes the committer will obviously change, but the author should stay intact. At least this is how it worked in my case.

We can then consider how to best merge things, e.g.:
master with linux (using e.g. git-imerge) and then rebase ptitSeb on top
or
merge master with ptitSeb (fast forward) and then imerge with linux (possibly more work)
or
merge master with ptitSeb and selectively cherry-pick commits from linux that have not yet been ported to master (some already were).

Option 3 is exactly what I thought of.
My reasoning is that that @ptitSeb's version is already working, so we can selectively choose most important changes from linux branch, every-time checking everything is still fine with master branch.
Actually it could be hybrid solution: after enough changes from linux is cherry picked to master, at some point it should be fairly easy to merge it together, since remaining small changes should not result in many conflicts.
As for pure solution 1 or 2 I have a feeling that resulting merge (linux with master or linux with ptitSeb/master) would not initially produced anything working right away and some extra changes on top of that merge would be required. So if we really would like to go with this option, in I would suggest to do it following way, in order to not have broken master at any point: merge all the changes from master to linux (not the other way around, so master is still in untouched), and after all changes from master are on linux branch and it's tested that all works fine, then merge it back to master. To avoid conflict resolving again, this time we merge with strategy 'theirs' . This just to record the merge, because that way we completely overwrite what was on master, but this is OK, because at this point all changes from master are already on linux branch.

What do you think?

Answer 5 · 2018-10-08T07:19:16.000Z

Hi folks,

I couldn't remember any more how I actually got into hosting the CtP2 source… that was about 12 years ago. However, I always understood that the license dictated me to get the real names of everyone who wanted write access. Mostly as a safe-guard for me if anyone does commit things that violate the license agreement, but I vaguely remember there was another reason. Reading the license again there's only one part mentioning names: New Game Materials must contain prominent identification at least in any on-line description and with reasonable duration on the opening screen: (a) the name and E-mail address of the New Game Materials creator(s) and (b) the words “THIS MATERIAL IS NOT MADE OR SUPPORTED BY ACTIVISION.”

Anyway, this "I need the contributor's real name" was the main reason I didn't move to GitHub; I still have worries about legal issues but maybe I'm just overcautious. Also the SubVersion repository didn't need much maintenance and I rarely had to even think about it. I was only briefly involved with the project and to be honest, my priorities shifted to other things.

I have no issues with someone maintaining an "official" CtP2 GitHub repository and retiring the SubVersion repository. I'd be happy to redirect people to this repository on my CtP2 site. Maybe it would be a good idea to create a GitHub account just for that so that it can it easily be "passed on" to someone else without breaking things.

Answer 6 · 2018-10-08T11:36:42.000Z

Many thanks to @DEVoytas and @DarkDust for chiming in with feedback.

I fetched and rebased all other repos changes @DEVoytas found, i.e.
https://github.com/LynxAbraxas/ctp2_git-svn/tree/RolandTaverner
https://github.com/LynxAbraxas/ctp2_git-svn/tree/ScottGrant
While ScottGrant only differs by a readme, RolandTaverner continued to commit on Manuel Selingers commits on SVN. All rebases had no conflicts.

All this shows how the contributions go out of sync without an official git repos. I agree to @DarkDust suggestion to create an official CtP2 GitHub repository and to create a GitHub account or organization for that, so that we end up with a git repos like https://github.com/ctp2/ctp2 (or civctp2). Looking for volunteers to do so. If @ptitSeb is happy with him being the author and me being the committer for his contributions, https://github.com/LynxAbraxas/ctp2_git-svn/ could just be pulled and then pushed to the newly created user/org repos, pulled and pushed and not forked to make it the official one and to change the name to e.g. ctp2 or civctp2. After that everyone wanting to contribute could just fork on GH work on their own copy and contribute back via Pull-Requests that then can be merged by the maintainer of the official repos, if appropriate, i.e. the common GH workflow.
Also I would suggest to retire push access to the SVN repos to avoid additional snyc work for the maintainer (although git svn should allow to do so). Preserving read only access to the SVN while pointing to the official git repos on @DarkDust ctp2 svn info page. Only pushing to git repos (even cloned, forked ones) will ensure that SHAs for existing commits will stay the same and will avoid the SVN clutter if not git-svn was used.

Who would like to volunteer to be the maintainer of the official ctp2 GH git repos? Ideally for as long as possible. The overall maintenance work should be quite low, i.e. initially creating the user/org and the repos and then only sync work and PRs as it seems fitting.

Answer 7 · 2018-10-08T11:52:05.000Z

When should I turn off SubVersion write access? Would it make sense to do so right now or do we want to wait until the GitHub repo is ready?

Answer 8 · 2018-10-08T11:53:27.000Z

One pro for using GH for the main repos is that it is easily possible to see if others have made any new contributions in the Network-view, if they forked the project on GH and have pushed their commits to their fork on GH. Then it is even possible to merge in some of those contributions even if the contributor did not create a PR (which is basically just a hint to point the maintainer to the new contribs).

Answer 9 · 2018-10-08T12:05:08.000Z

When should I turn off SubVersion write access? Would it make sense to do so right now or do we want to wait until the GitHub repo is ready?

Hm, good question. Perhaps first put a link to this conversation and give others a chance to share their ideas on this for a day or a week?

This made me have a look whether it is possible to move this issue/conversation to the future official repo. Seems to be wanted badly, some non GH methods exist, see e.g. github/hub#886.

Answer 10 · 2018-10-08T12:06:09.000Z

Only pushing to git repos (even cloned, forked ones) will ensure that SHAs for existing commits will stay the same and will avoid the SVN clutter if not git-svn was used.

I just wanted to emphasize, that same SHAs will only be ensured, if clones and forkes are from the same SVN to git import. This is why it is important to agree to base all further work on the same import, so people can work on their owns copies (forks, clones) but are able to pull from each other as well.

Answer 11 · 2018-10-08T12:22:22.000Z

Yes, that is why I think removing write access to the SVN repos would be good so that when someone new wants to contribute is forced to read up on how further contributions are expected.
As the git svn import even preserves the SVN-refs (and would allow to push to SVN if needed for some unforeseen reason) I would vote to use that. I'm happy if my test repo https://github.com/LynxAbraxas/ctp2_git-svn is used (pull+pushed to rename and to be no fork as described above) to avoid the work of redoing this, I just would like someone else to be the official maintainer, because I would not be available more than once every few years in order to avoid lapse back into coding-adiction;-)

Answer 12 · 2018-10-08T13:23:34.000Z

Having a github account/organisation seems a good idea yes.

I think this is the first step to do (create the organisation, get all the contributor / maintainer inside it). Once this is done, the the SVN can be put read-only while the migration is done.

Answer 13 · 2018-10-08T13:45:42.000Z

@ptitSeb As you got the main master/trunk working under Linux (and got rid of the need for bothering about case sensitivity (a contrib I welcome very much because I ended up here with the intend to create a docker image which would be problematic with a vfat partition/image)), would you like to be the initial maintainer and create the official repo?

Answer 14 · 2018-10-08T14:43:19.000Z

Thank you @LynxAbraxas , but I think you can create it, you have contribute a lot to the linux port of ctp2, so I don't see why you should not initialize that ctp2 group.

Answer 15 · 2018-10-08T18:03:22.000Z

I switched the SubVersion repository to read-only and put up a note on https://ctp2.darkdust.net . Simply putting a note on the site won't do while maintaining write-access won't do, nobody is going to look at that site. 😁 If people want to commit and fail they're going to contact me and I can redirect them to this discussion as well.

Answer 16 · 2018-10-10T10:08:32.000Z

How about you @DEVoytas? Would you mind to be the initial maintainer?

Answer 17 · 2018-10-11T00:57:04.000Z

Hi @LynxAbraxas

I created new user and initial repo (based on your import) here: https://github.com/civctp2/civctp2/
So now this could be treated as an "official" repository, that people can be pointed to (especially after SVN access was changed to read-only), and from which people can fork and base their work on its current master branch.
Later, the civctp2 user account can hopefully be converted to github organization, similarly to this community for example: https://github.com/OpenRCT2/

With regard me being maintainer, thank you for the proposition, but I do not think I am the best person for that position.
Please let me explain why I think so.
First of all, I think maintainer should take responsibility for what lands on the official master branch and keep it in good health.
Since I have never contributed any ctp2 code, I just do not feel qualified to judge what changes are good enough and which require some more work.
This is especially important now, when there are few "competing" lines of development, each ahead of the current master.
The decision, whose changes will land first, has to be made very carefully in my opinion, because that means extra work on changes that will not be merged as the first ones.
It is also probably good idea, that maintainer initially supports authors of the changes that were not merged, in theirs effort to make them mergeable to new master again.
In case those authors are not interested in working on it any more, but have some good changes on their branch, maybe even he would need to resolve the conflicts himself.

For all those reason, I think that for the maintainer (even the initial one), someone with reasonably good knowledge of existing code base is needed.
That probably means someone who has contributed code to the project already.

I am happy to pass the new repo credentials to you, or @DarkDust or whoever you think should take a role of the initial maintainer.
Maybe @ptitSeb will reconsider :) ? Or @RolandTaverner will chime in to the discussion?
I really hope my position is reasonable enough, but I am open for discussion if you feel otherwise.

PS.
Maybe @DarkDust could add information to his site, that maintainer is wanted, with link to the new repo and information that all contributions are on hold, until maintainer is found?

Answer 18 · 2018-10-11T17:55:19.000Z

I've added a link to the GitHub repo. Regarding the search for a maintainer, I would recommend to add README.md to the repo and ask for a maintainer there. Also, some pointers to resources you deem valuable (forum? compile instruction?) would be a good good idea for the README.md.

Answer 19 · 2018-10-11T18:24:09.000Z

How many maintainer can there be?

Also, doesn't the next task, first, is to merge all changes from the different Repo before altering the README.md (plus, some changes included a new README.md :p ).

Answer 20 · 2018-10-11T21:08:59.000Z

Many thanks @DEVoytas for initiating the "official" repository. It is most important to have a central repo to fork from. Finding someone to decide on merges/PRs and directions might become easier then. So far I'm not sure how to contact those from old like Martin Gühmann, ctplinuxfan or Fromafar, as they do not seem to be active any more.
Also many thanks to @DarkDust for the pointer to the GH repos on the SVN page. I agree, a README.md would be good and that could be based on that from @ptitSeb. I'm currently testing his contributions inside docker. I needed a few additional instructions from the README.linux from the linux branch to make it playable. After some more test, I can adjust the README.md accordingly.
As far as I can judge @ptitSeb adjustments should not influence the successful compilation under windows, and would suggest to merge his commits into master (to e.g. use his README.md as base) but it would be good to be sure. Is there some way similar to .travis.yml to also test a windows build (I could only find Linux and OSX support from travis)?
The README.md should then definitely point to the old forum and SVN repos.
The search for a maintainer could also be the first issue.

Answer 21 · 2018-10-11T21:11:25.000Z

@DEVoytas, I just noticed that the "official" repository is missing the 13 "releases" i.e. tags. Did you do a push origin --tag?

Answer 22 · 2018-10-11T21:24:48.000Z

I will then delete my ctp2 and ctp2_git-svn repositories and only work with the fork of civctp2 to avoid confusion to others and to make PRs and easy merges possible. I would recommend that also to @ptitSeb, @DEVoytas, @RolandTaverner, @jleclanche, @talentlesshack and unknow others, but that is of course up to each repos owner.

Answer 23 · 2018-10-11T21:34:24.000Z

@DEVoytas : Did you create an organisation (using "Profile" menu and select Organisation then the "Create New Organisation" button) or is that a simple user account?

Answer 24 · 2018-10-11T22:01:16.000Z

About Windows build, my changes shouldn't break the build indeed, but I must say I haven't tried out.
About travis, it doesn't support Windows, and we need appveyor for that (https://www.appveyor.com/). I never tried it yet, but I will, I want to test Windows build on some of my projects.

Answer 25 · 2018-10-11T23:24:37.000Z

I have deleted my mirror. Thanks folks.

Answer 26 · 2018-10-11T23:25:49.000Z

Hi all.

@DEVoytas, I just noticed that the "official" repository is missing the 13 "releases" i.e. tags. Did you do a push origin --tag?

@LynxAbraxas, I indeed did not notice that push all does not actually pushes tags. Fixed now.
With regard to other comments I will try to refer to them tomorrow.

Answer 27 · 2018-10-12T22:40:23.000Z

@ptitSeb:

How many maintainer can there be?

I hope just one is enough :)

Also, doesn't the next task, first, is to merge all changes from the different Repo before altering the README.md (plus, some changes included a new README.md :p ).

Yes, it is the first task, but is should be done by the maintainer, who is currently missing. So in order to find him, we add the info about it in README file (as suggested by @DarkDust and @LynxAbraxas ). When someone agrees for the role, the new maintainer can remove "maintainer needed" info, and replace the content with "real" README file.

@DEVoytas : Did you create an organisation (using "Profile" menu and select Organisation then the "Create New Organisation" button) or is that a simple user account?

For now just regular user, but it can be easily converted to organization as I mentioned above.

@LynxAbraxas

and would suggest to merge his commits into master (to e.g. use his README.md as base)

Not sure I understood fully. You want merge all @ptitSeb's commits to master branch, or just use his README as a base?

@jleclanche

I have deleted my mirror. Thanks folks.

Feel free to fork https://github.com/civctp2/civctp2 then

Answer 28 · 2018-10-12T22:55:56.000Z

OK folks, I creted 2 new issues:

and added new README.md file

Please let me know what you think, especially if you find any errors/mistakes/misinformation.

Answer 29 · 2018-10-13T08:51:11.000Z

The new README.md is nice, but I guess the How to build on window is missing (I don't know how to build on windows.. using mingw?).

Also, I think the How to build on Linux will not work with the current sources, at least because of the FreeType (1!) dependancy (I have added the sources of it in my repo and it's built automatically).
I'll open an issue later to ask to move from FT to SDL_ttf (and I'll probably open another issue for optional use of SD2, but that's far less priority).
(EDIT Ah, I see you already mentioned that it may not be 100% working for current master, my bad... I should learn to read).

Also travis (and appveyor) would be nice to have soon (but I have no idea how the migration User -> Group Account work on travis/appveyor side).

Answer 30 · 2018-10-13T13:36:03.000Z

The new README.md is nice, but I guess the How to build on window is missing (I don't know how to build on windows.. using mingw?).

Unfortunately, I don't know either.

(EDIT Ah, I see you already mentioned that it may not be 100% working for current master, my bad... I should learn to read).

Yes, exactly. I was going to bring that up (I mean the fact that there is already a note that readme is for your branch, not the current master), but now it made me think that maybe this info is not visible enough, and the whole page is more confusing because of that. Maybe instead of pasting the copy of your page we should rather link to readme on your branch... What do you think guys ?

Also travis (and appveyor) would be nice to have soon (but I have no idea how the migration User -> Group Account work on travis/appveyor side).

Agree, but I do not know either. Maybe create new issue for that?

Answer 31 · 2018-10-13T17:48:52.000Z

Not sure I understood fully. You want merge all @ptitSeb's commits to master branch, or just use his README as a base?

I meant all @ptitSeb's commits, as in my test they all worked out well. Though it would be great to have a working appveyor for the windows build before (which I think used MS c compilers, see e.g. @RolandTaverner commit 4a60c81c31ed3a). Anyway I would suggest to move further discussion to either civctp2 issues or concerning the merge that @ptitSeb forks the new civctp2 repos and opens a PR for his contributions so far so that further discussion can go there. To not loose this discussion, I would either recommend to port it as an issue to civctp2 or ask @ptitSeb not to delete this repos but make it an archive (which preserves the issues as far as I know)

Answer 32 · 2018-10-13T18:28:51.000Z

I had planed to archive and not delete anyway.

For the appveyor, I tried to play with that yesterday on an other of my repo (https://github.com/ptitSeb/stuntcarremake ) and yeah, it's pretty easy to use, and similar to travis.

Answer 33 · 2018-10-13T22:29:56.000Z

@LynxAbraxas

Anyway I would suggest to move further discussion to either civctp2 issues

Agree! I created civctp2/civctp2#4 Let's continue there.

To not loose this discussion, I would either recommend to port it as an issue to civctp2

That one I do not know how to do, but since @ptitSeb agreed to archive the repo, the link from new issue to this discussion should probably be enough.

@ptitSeb

I had planed to archive and not delete anyway.

Great! Thank you! I put the reference to this discussion from there then.

EDIT:
Also created 2 new issues:

"Set up travis-ci for Linux builds": civctp2/civctp2#5
"Set up AppVeyor CI for Windows builds" civctp2/civctp2#6

Answer 34 · 2018-10-15T20:12:07.000Z

Let's close this issue. In short:

The source of the flattening of the git history (branch commits (all empty) all intermixed in one master branch) is unclear. Therefore, a git-svn import was made that preserves branches and SVN IDs and always results in the same SHA1 for each commit (details see above).

An official civctp2 git repository was created from this import:
https://github.com/civctp2/civctp2
which should be used as a base for issues and new contributions. For this, follow the common GH way of forking the repos on GH, add, commit, push and create a PR, like civctp2/civctp2#9.
Please do not use the GitHub import functionality to import ctp2 from the original SVN repos (which should only be seen as a reference/archive for contributions before the transition to git was made).