Github proposal for colonization branch

[Cjkjvfnby]

We have miniproject that require coloboration of developers. We can share patches in thread or personaly, but why not to try github?

Make fork from freorion repo.
Make new branch with changes. Master will remain unchanged to be synced with main repo.
Give access to other users.

Bonuses

All code is uptodate. You can push more often then adding patches to forum.
Easy switch between branches and merging them together.
Side users can send you pull requests. It is more easy then add patches to forum.
Github allow your to apply pull requests from browser. I really miss this feature, because it is greatly speedup merge of small fixes.

[em3]

@Cjkjvfnby ... I think this is because still the "main" master is on SVN, not git.

But yeah, git and github/gitlab are precious.

[Vezzra]

We have miniproject that require coloboration of developers. We can share patches in thread or personaly, but why not to try github?

Well, we could try that for this miniproject. I already have an account on github, but I'm a complete newbie with git and github. Is it possible to have a git repo on github that mirrors our svn trunk in the master branch of the git repo and do the dev work on a topic branch, where we can regularly merge the commits to trunk (which are mirrored in master)?

And if that setup works, how is that done?

[Cjkjvfnby]

We have miniproject that require coloboration of developers. We can share patches in thread or personaly, but why not to try github?

Well, we could try that for this miniproject. I already have an account on github, but I'm a complete newbie with git and github. Is it possible to have a git repo on github that mirrors our svn trunk in the master branch of the git repo and do the dev work on a topic branch, where we can regularly merge the commits to trunk (which are mirrored in master)?

And if that setup works, how is that done?

https://help.github.com/articles/fork-a-repo/
Check "Try git" tutorial

You need to
fork https://github.com/freeorion/freeorion
clone
create branch
apply your patch
commit
push
share link to repo

Other coloborators need to ge access to repo or fork it too and clone.

[Vezzra]

https://help.github.com/articles/fork-a-repo/
Check "Try git" tutorial

I have already read through the basic tutorials, but (at least the ones I read) they didn't cover the topic of interoperation with a subversion repository. But that's what I want/need to do.

You need to
fork https://github.com/freeorion/freeorion
clone
create branch
apply your patch
commit
push
share link to repo

Other coloborators need to ge access to repo or fork it too and clone.

Well, that approach uses the already established mirror of the sourceforge FreeOrion repo, which is not what I want to do. This mirror repo is not an official repo of the FreeOrion project, the repo as well as the "freeorion" organizational account on github is not under our control. AFAIK Marcel tried to contact the owner of this account and the repo, but apparently failed. And personally I refuse to depend on any resources that are completely beyond our control like this, and where there seems no communication possible at all.

Another problem is that this github repo only mirrors trunk. As I have created a branch to work on the new mechanics, the github repo is of no use.

So what I'd need to do is to create my own temporary mirror repo on github, which should only mirror the Revised Colonization branch in master. I know that there are git commands which provide some interoperability with subversion repos, but I don't know how to use them yet.

[Cjkjvfnby]

Well, that approach uses the already established mirror of the sourceforge FreeOrion repo, which is not what I want to do. This mirror repo is not an official repo of the FreeOrion project, the repo as well as the "freeorion" organizational account on github is not under our control. AFAIK Marcel tried to contact the owner of this account and the repo, but apparently failed. And personally I refuse to depend on any resources that are completely beyond our control like this, and where there seems no communication possible at all.

Another problem is that this github repo only mirrors trunk. As I have created a branch to work on the new mechanics, the github repo is of no use.

So what I'd need to do is to create my own temporary mirror repo on github, which should only mirror the Revised Colonization branch in master. I know that there are git commands which provide some interoperability with subversion repos, but I don't know how to use them yet.

Wow, did not know about freeorion organization. Who is updating github clone? Is it sourceforge hooks or some external script?

[Dilvish]

Who is updating github clone? Is it sourceforge hooks or some external script?

It had stopped updating for a while, back when our sourceforge URL changed. That is what triggered our investigating the matter, and github said they would forward a message to the email address they have on file, but we got no response from that. A short while later, though, the github clone started getting updated again. I think that's about all we know.

So it appears to me that one of the early freeorion project members with access rights at GitHub is running a chron job on their local machine to update the github clone. They cared enough to update their script once the issue came to their attention, but not enough to talk to us.

[Cjkjvfnby]

Who is updating github clone? Is it sourceforge hooks or some external script?

It had stopped updating for a while, back when our sourceforge URL changed. That is what triggered our investigating the matter, and github said they would forward a message to the email address they have on file, but we got no response from that. A short while later, though, the github clone started getting updated again. I think that's about all we know.

So it appears to me that one of the early freeorion project members with access rights at GitHub is running a chron job on their local machine to update the github clone. They cared enough to update their script once the issue came to their attention, but not enough to talk to us.

This make things harder then I think.

I see next way:

We create new repo for freeorion (svn mirrow).
We will use update script to update it from svn. (for example manually once per day of more offen, I think it is ok for current situation)
All code related to this branch will be stored in this repo. (no back commit to svn)
All people involved to this branch will use git. (have two repos on local machine)
After branch is ready copy it to svn and freeze repo.

What I need:
Approve of all people envolved to this branch. (they will need to use git) after that I will do all steps.

[Dilvish]

Some feedback so far-- I do find the overall mechanism more convenient, and like it. My only concern so far is that the outpost pod base cost seems rather low at 50; I would suggest at least 70. Even if it returned to the current standard 80 the total cost of a colony would still be lower with the new mechanic since you don't have to pay for a ship hull (and probably armor & sensors), and the new mechanic is lower risk as well. That's my initial feeling anyway.

One project management issues:

I see next way:
We create new repo for freeorion (svn mirrow)....

What is the need for making a new git svn mirror? Just that we don't want to be reliant on the mystery person? There is some merit to that, eventually. But for now, I suspect it should wait until such time as it seems worthwhile to Geoff or Vezzra for them to maintain it. It's nice of you to offer to take care of it, but I think we should hold off on making yet another semi-official freeorion git account that isn't under Geoff's control.

As for the whole idea-- I see some benefits and some detriments and I have mixed feelings about trying to take on a totally git collaboration right now. Could you summarize what you see as the overall motivation and the pros and cons for this? At the end, when things got put back into svn, would all the git commit history get collapsed into a single svn entry, or would the commit history be preserved in svn? Who do we have active that could be responsible for that critical step? Marcel/adrian is the only svn-committer I know who seems likely to have enough familiarity with git-svn interworkings, but I haven't noticed him being active as of late. Of course, perhaps Vezzra is in the mood for an extra challenge...

[Cjkjvfnby]

I see next way:
We create new repo for freeorion (svn mirrow)....

What is the need for making a new git svn mirror? Just that we don't want to be reliant on the mystery person? There is some merit to that, eventually.

Just to have someone with write access.

But for now, I suspect it should wait until such time as it seems worthwhile to Geoff or Vezzra for them to maintain it. It's nice of you to offer to take care of it, but I think we should hold off on making yet another semi-official freeorion git account that isn't under Geoff's control.

I expect Geoff or Vezzra will be admin of this account. To update it form svn I need to be just coloborator.

As for the whole idea-- I see some benefits and some detriments and I have mixed feelings about trying to take on a totally git collaboration right now. Could you summarize what you see as the overall motivation and the pros and cons for this?

easy branching (create you fork, make any branch you want, if you have a lot of little fixes in different parts it is good.)
fast adding patch (it is faster to make Pull request then adding patch to forum)
fast applying patch (it can be done via web interface from mobile device)
easy to update outdated patches
comment for commits (part of forum discussion can be dont close to code)
diff via web (It look nice, I did not read diff in console any more)
all pull request in one place (less chance to forget some of them)
less commits with bulk changes (usually I join couple commits in one patch, because it is easy to do)
less such commit messages "Patch by Geoff fixing command-line auto-advance, with a small fix by me". Info about who done it should be in commit not in message.

Share your detriments. (everyone should know git, some time for setup it all, what else?)

At the end, when things got put back into svn, would all the git commit history get collapsed into a single svn entry, or would the commit history be preserved in svn? Who do we have active that could be responsible for that critical step? Marcel/adrian is the only svn-committer I know who seems likely to have enough familiarity with git-svn interworkings, but I haven't noticed him being active as of late. Of course, perhaps Vezzra is in the mood for an extra challenge...

As you want. We always have way to send it back as single patch. (MatGB will be glad when check commits to write changelog )

[Dilvish]

easy branching

That does sound like a benefit of git in general, though this current subproject is so focused that this aspect seems very minor in this case

fast adding patch (it is faster to make Pull request then adding patch to forum)

I think this point brings up some broader workflow issues. It seems to me that most of out patches wind up having/needing some discussion along with them, so a forum post is helpful and attaching a patch, or a link to a diff as you've sent me via pm, seems rather easy. There may be some established practice among git users about how to organize such discussions, but I think this point would need more discussion here.

fast applying patch (it can be done via web interface from mobile device)

Via web interface if someone wants to commit someone else's patch without trying it out? We generally try to avoid that. I don't see where git really has an advantage over svn here.

easy to update outdated patches

Also quite easy with svn.

comment for commits (part of forum discussion can be dont close to code)

I'm not really understanding your point here and what the difference with git would be

less commits with bulk changes (usually I join couple commits in one patch, because it is easy to do)

At least for the commits into the git repository, I can see that. I'm still not sure how it would work out getting back into svn.

Share your detriments. (everyone should know git, some time for setup it all, what else?)

The learning curve and associated hiccups, and interoperability challenges with svn seem to me the primary detriments/costs. It's a bit more than 'everyone should know git' -- we have a number of people here who apparently use git quite a bit, but many of them have still frequently had trouble making the interoperation with svn work out smoothly. So it looks like a nontrivial amount of learning to be required here -- useful learning, sure, but likely to involve hiccups. That's just a cost to be considered against the benefits. Perhaps, though, a small project like this is an ideal situation to take something like this on for the first time.

At the end, when things got put back into svn, would all the git commit history get collapsed into a single svn entry, or would the commit history be preserved in svn? Who do we have active that could be responsible for that critical step? Marcel/adrian is the only svn-committer I know who seems likely to have enough familiarity with git-svn interworkings, but I haven't noticed him being active as of late. Of course, perhaps Vezzra is in the mood for an extra challenge...

As you want. We always have way to send it back as single patch. (MatGB will be glad when check commits to write changelog )

But if we don't want it going back as a single patch (avoiding things like that was one of the benefits you listed), it's not clear to me we have someone who can/would manage that.

[Cjkjvfnby]

easy branching

That does sound like a benefit of git in general, though this current subproject is so focused that this aspect seems very minor in this case

Look at this patch -> look at this branch
It is ok to have couple of branch with different implementation of same feature. Just to discuss wich is better.

fast adding patch (it is faster to make Pull request then adding patch to forum)

I think this point brings up some broader workflow issues. It seems to me that most of out patches wind up having/needing some discussion along with them, so a forum post is helpful and attaching a patch, or a link to a diff as you've sent me via pm, seems rather easy. There may be some established practice among git users about how to organize such discussions, but I think this point would need more discussion here.

Some need some not. I dont sent a lot of small patches with typos because it takes a lot of time. So we will win in case when not need discussion and speedup on others (it is faster for me to attach link to diff then patch.) And it is faster to checkout branch from git then apply patch.

fast applying patch (it can be done via web interface from mobile device)

Via web interface if someone wants to commit someone else's patch without trying it out? We generally try to avoid that. I don't see where git really has an advantage over svn here.

Some small patches can be applyed with out testing. It is mostly related to stringtables.

easy to update outdated patches

Also quite easy with svn.

Delete patch from forum and upload new?

comment for commits (part of forum discussion can be dont close to code)

I'm not really understanding your point here and what the difference with git would be

https://github.com/Cjkjvfnby/freeorion/ ... a0d1bR1477 Some part of discussion can be done near code. It is ok to discuss how ships fly on forum, and typo in variable near code.

Share your detriments. (everyone should know git, some time for setup it all, what else?)

The learning curve and associated hiccups, and interoperability challenges with svn seem to me the primary detriments/costs. It's a bit more than 'everyone should know git' -- we have a number of people here who apparently use git quite a bit, but many of them have still frequently had trouble making the interoperation with svn work out smoothly. So it looks like a nontrivial amount of learning to be required here -- useful learning, sure, but likely to involve hiccups. That's just a cost to be considered against the benefits. Perhaps, though, a small project like this is an ideal situation to take something like this on for the first time.

It is small project and not many of people involved.

At the end, when things got put back into svn, would all the git commit history get collapsed into a single svn entry, or would the commit history be preserved in svn? Who do we have active that could be responsible for that critical step? Marcel/adrian is the only svn-committer I know who seems likely to have enough familiarity with git-svn interworkings, but I haven't noticed him being active as of late. Of course, perhaps Vezzra is in the mood for an extra challenge...

As you want. We always have way to send it back as single patch. (MatGB will be glad when check commits to write changelog )

But if we don't want it going back as a single patch (avoiding things like that was one of the benefits you listed), it's not clear to me we have someone who can/would manage that.

Single commit can save a lot of time. Some companies has such practice: make feature in single branch, test, fix and when it ready commit as single commit. Just to have more clear history. I think I can try to put commits back to svn (with my own repo and share instruction with someone who have access to official.)

PS. May be I should ask moderators to cut this discussion to separate thread?

[Dilvish]

Here's a few bits of info that seem useful/helpful/interesting to me--

• Here's a migration guide recommending that even in a situation with a definite plan to migrate from svn to git, that people start out by using git as an svn client, for a smoother transition. If/when we do try out collaborating via git, it sounds like this git-svn interface will be the key for nicely getting commits back to svn.
• Here's a git-svn guide, re using git as a local client for an svn repository.
• Sourceforge supports GIT now, so we wouldn't necessarily need to make a new FO account on github or whatnot to use git for this branch. Unfortunately, for some reason it appears that sourceforge doesn't actually directly/easily support automatically mirroring a sourceforge svn repository to a sourceforge git repository. I expect there is probably some way to do it with post-commit hooks associated with the sourceforge svn repository; see here and here.
• Here's an old-ish guide to DVCS (distributed VCS) such as git, which still seemed to me to have some useful info.
• for Windows folks, Tortoise-GIT is apparently derived from Tortoise-SVN and so probably worth looking at.
• An article on automatically mirroring an svn respository to a git repository. But bleh! That looks messier than I thought it had to be.
• Some info adrian had previously posted in this thread.

So, I can't claim to understand this all well enough to have a clear plan (or even a reliably accurate one ), but if/when we did proceed with something like this, to expand/adjust a bit of what Cjkjvfnby suggested above, it seems to me that the approach would be for Vezzra to use "git svn clone" to make a local git clone of this colonization branch. Then, hmmm, (ok really stretching my knowledge, lol), hopefully he could then put a fork of that into an FO sourceforge git repository, which other people would then fork off of (they would probably be putting their forks onto github or whatever). Pull requests would be used to merge code into the sourceforge git copy, and then from there into Vezzra's original git svn clone copy, and then he could use "git svn dcommit" to put changes back into the svn branch. A slight alternate would be for Vezzra to do the git svn clone of trunk, and then make a git branch that he adds the current colonization branch changes to, and then the sourceforge git copy would be a fork/clone of that git branch. Does that sound right?

[Mitten.O]

The principles seem sound to me. With freeorion I use git locally without telling it that the code is also in svn, but I use git svn at work (our company still uses svn, I'm working to fix that) and I am certain it can deal with such a process. One thing to note is that importing the entire history of the project into git will be quite slow, so for a temporary branch like this, you may want to just import a few hundred of the latest commits. Depends on your patience.

[Cjkjvfnby]

So, I can't claim to understand this all well enough to have a clear plan (or even a reliably accurate one ), but if/when we did proceed with something like this, to expand/adjust a bit of what Cjkjvfnby suggested above, it seems to me that the approach would be for Vezzra to use "git svn clone" to make a local git clone of this colonization branch. Then, hmmm, (ok really stretching my knowledge, lol), hopefully he could then put a fork of that into an FO sourceforge git repository, which other people would then fork off of (they would probably be putting their forks onto github or whatever). Pull requests would be used to merge code into the sourceforge git copy, and then from there into Vezzra's original git svn clone copy, and then he could use "git svn dcommit" to put changes back into the svn branch. A slight alternate would be for Vezzra to do the git svn clone of trunk, and then make a git branch that he adds the current colonization branch changes to, and then the sourceforge git copy would be a fork/clone of that git branch. Does that sound right?

Pull requests anf forks is features of github, not git. Github implements interface to manage patches. So I expect to have clone on github. It does not metter where remote repo located and how many remote repos setuped for local git repository.

Github have some ui tool for mac and windows. I did not check it, i prefer console or Pycharm vcs integration.