It is currently 20 Jun 2019, 05:55
   
Text Size

Git Migration

Post MTG Forge Related Programming Questions Here

Moderators: timmermac, friarsol, Blacksmith, KrazyTheFox, Agetian, CCGHQ Admins

Re: Git Migration

Postby Goblin Hero » 28 Aug 2017, 16:07

Old auth with the forum name/pass is back. Please test.
When you´re a goblin, you don´t have to step forward to be a hero -- everyone else just has to step back.
User avatar
Goblin Hero
Site Admin
Site Admin
 
Posts: 1930
Joined: 23 Oct 2005, 09:37
Location: Russia
Has thanked: 141 times
Been thanked: 316 times

Re: Git Migration

Postby Agetian » 28 Aug 2017, 17:52

Looks like it's working well. Thanks! :)

- Agetian
Agetian
Programmer
 
Posts: 3336
Joined: 14 Mar 2011, 05:58
Has thanked: 638 times
Been thanked: 495 times

Re: Git Migration

Postby Seravy » 19 Sep 2017, 14:33

Today is the 2 months anniversary of starting the migration so...how is it going? Like, progress in percentages or something?
Seravy
 
Posts: 363
Joined: 26 Oct 2016, 21:23
Has thanked: 5 times
Been thanked: 27 times

Re: Git Migration

Postby friarsol » 29 Dec 2017, 02:31

Hey folks, the Christmas break earned me enough time to figure out the issues that Krazy was having when trying to migrate our codebase over to Git. Well, with a few days of trial and error led us to our codebase properly migrated

https://git.cardforge.org/

git clone https://git.cardforge.org/core-developers/forge.git

If you were interested in helping out on Forge, please sign up for an account (if you don't have one already). Moving to Git allows anyone to create their own developer account and create a pull/merge request to pull code into the codebase.

In the past, Forge attempted to move to Git, but due to some of the core contributors not being as familiar with it, that migration caused more pains than it was worth. Currently, those contributors are no longer with the project, and some of Forge's tools have matured, to reduce the amount of stress involved in some of the release processes. Hopefully, there will be a minimal pain time while current contributors switch over to Git. On top of that, allowing new contributos in immediately, and allowing them to control how quickly they can contribute in a more formalized setting will help grow the contributor base.

Here's the basic flow of working with Git, for those of you who are new to it.

0. Create an account: https://git.cardforge.org/core-developers/forge
1. Fork the project: https://git.cardforge.org/core-develope ... /forks/new
2. Download a copy of the forked repo locally (clone it): git clone https://git.cardforge.org/<username>/forge.git
3. Create a new local branch for your "feature": git checkout -b <Name of Feature>
4. Edit whatever files you want to change
5. Stage your content to be added: git add <filenames>
6. Commit the change locally: git commit -m <message>
7. Push the change up with: git push
7a. If it's the first time pushing to this branch, you'll need to specify the remote: git push -u origin <branchname>
8. Create a merge request from your forked repo: https://git.cardforge.org/<username>/forge/merge_requests

If you haven't done so already, please join us in the Discord channel, where we can hash through more immediate resolutions for people.
friarsol
Global Moderator
 
Posts: 7440
Joined: 15 May 2010, 04:20
Has thanked: 240 times
Been thanked: 927 times

Re: Git Migration

Postby Goblin Hero » 29 Dec 2017, 06:37

Should I put old SVN to read-only mode or just shutdown it?
When you´re a goblin, you don´t have to step forward to be a hero -- everyone else just has to step back.
User avatar
Goblin Hero
Site Admin
Site Admin
 
Posts: 1930
Joined: 23 Oct 2005, 09:37
Location: Russia
Has thanked: 141 times
Been thanked: 316 times

Re: Git Migration

Postby KrazyTheFox » 29 Dec 2017, 09:24

We should leave it read only for the time being, just to be sure everything transferred correctly.
User avatar
KrazyTheFox
Programmer
 
Posts: 724
Joined: 18 Mar 2014, 23:51
Has thanked: 66 times
Been thanked: 226 times

Re: Git Migration

Postby Goblin Hero » 29 Dec 2017, 09:49

Should be read-only now.
When you´re a goblin, you don´t have to step forward to be a hero -- everyone else just has to step back.
User avatar
Goblin Hero
Site Admin
Site Admin
 
Posts: 1930
Joined: 23 Oct 2005, 09:37
Location: Russia
Has thanked: 141 times
Been thanked: 316 times

Re: Git Migration

Postby hidalgo » 30 Dec 2017, 05:18

friarsol wrote:8. Create a merge request from your forked repo: https://git.cardforge.org/<username>/forge/merge_requests
Should a new merge request be assigned to someone?
User avatar
hidalgo
 
Posts: 294
Joined: 17 Oct 2016, 21:51
Location: Russia, Moscow
Has thanked: 42 times
Been thanked: 63 times

Re: Git Migration

Postby Seravy » 30 Dec 2017, 12:42

Trying to figure out how to make this work.
So far I managed to install egit in Eclipse, register, fork, clone and create a branch.
Where I'm stuck is, it used to be a right click then in the menu select "apply patch" to load one of the patches I already made (or "create patch" to make one but I guess that won't be needed anymore). But I can't seem to find that anymore, the entire menu is different now. So how do I import the patches into "branches" and what do I do after that?

There are basically two things I'd like to know :
-How to load and submit the already made patches from half a year ago for inclusion which are ready for that
-Once I set up all these branches, how do I select which of those I want to include when I compile it into a working game? (as I definitely want to include stuff that's I'm currently using but likely not things I'll work on and are incomplete in the future)
Seravy
 
Posts: 363
Joined: 26 Oct 2016, 21:23
Has thanked: 5 times
Been thanked: 27 times

Re: Git Migration

Postby friarsol » 30 Dec 2017, 14:54

hidalgo wrote:
friarsol wrote:8. Create a merge request from your forked repo: https://git.cardforge.org/<username>/forge/merge_requests
Should a new merge request be assigned to someone?
Nah. Being unassigned will let people know noone is looking at it. Probably your best bet is jump into Discord and tell people what the branch does, and walk someone through it if they need to.

Seravy wrote:So how do I import the patches into "branches" and what do I do after that?

There are basically two things I'd like to know :
-How to load and submit the already made patches from half a year ago for inclusion which are ready for that
-Once I set up all these branches, how do I select which of those I want to include when I compile it into a working game? (as I definitely want to include stuff that's I'm currently using but likely not things I'll work on and are incomplete in the future)
So here's what the internet seems to recommend:
https://stackoverflow.com/questions/115 ... repository

For each patch:
1. Get a clean svn repo. (without any changes)
2. Apply your patch to svn.
3. Recreate your patch so that it's compatible with git (svn diff --git >> gitFormat.patch)
4. Create a new branch for this patch in git (git checkout -b <patch_name>)
5. Apply the patch to git (git apply gitFormat.patch)
6. Create a merge request for this branch

Typically, each branch you create should have a different feature-set (as you mention incomplete work will each have their own branch). Until your merge requests for each of your completed branches are merged into master, the simplest way to play Forge with all of your work combined is to create one last branch, apply the changes of each of your finished patches to it and use that for compiling, but not for a new merge request. (There's another way to do it, which is more complex, and probably not worth the headache)

After your features have been merged into master, you can go back to just pulling the latest from master and playing Forge with master or your latest feature branch.
friarsol
Global Moderator
 
Posts: 7440
Joined: 15 May 2010, 04:20
Has thanked: 240 times
Been thanked: 927 times

Re: Git Migration

Postby Seravy » 30 Dec 2017, 15:36

Guess that'll be the first thing to experiment with next year then, doesn't sound like something I can do in a few hours.

So to see if I understand right, a summary :
1. I switch back my Eclipse to the previous SVN setup (how? in that perspective menu I used to make Git appear?) and then do the same thing I used to do half a year ago, get a clean latest version and apply my patch.
2. I assume I enter the svn diff command in a DOS prompt, in the directory where the SVN workspace is?
3. Creating branches seem to work fine in Eclipse so I don't need to worry about that I guess
4. Again the git command goes to dos prompt but which directory? I don't seem to have a separate master and branch copy on my disk even though I created a branch, so how does that even work? How do I tell I want this to go into that branch or another?
5. And finally I need to read all that git book again as I forgot everything I read half a year ago...

Wait so to actually use my work I need to STILL make patches and apply them locally every time I want to compile but in a much more complicated way than before as Eclipse won't support it directly? That sounds horrible, ouch. How am I going to even resolve conflicts if it's not done in Eclipse...I thought the entire point of this is to be able to do it without the patching nonsense, directly from the branches.
(I'm not that optimistic to assume 100% of my patches will be merged into master all the time so I can rely on that to play...)

I guess I'll think about it next year.
Seravy
 
Posts: 363
Joined: 26 Oct 2016, 21:23
Has thanked: 5 times
Been thanked: 27 times

Re: Git Migration

Postby silly freak » 30 Dec 2017, 17:33

Seravy wrote:Wait so to actually use my work I need to STILL make patches and apply them locally every time I want to compile but in a much more complicated way than before as Eclipse won't support it directly?
(Disclaimer: I didn't work with patches before, and haven't worked with Eclipse in a while, but I do know my way around git)

That shouldn't be necessary. The reason for Patches with SVN is that there is only one central repository, and if you don't have commit privileges, there's no way to keep your changes other than a patch. In git, you can commit whatever you like, and even push to your fork - the only thing that depends on your privileges is whether you can work on and merge pull requests into core-developers/forge.git.

Code: Select all
master --*-------*---....
          \       \
patch-1    *---*---!*
            \   \    \
playing      *---*--*-*
                   /
more patches   ....
So, instead of keeping a patch, you keep a branch, e.g. patch-1. I assume when applying a patch to an updated version of Forge, you can get conflicts that you need to resolve. In Git, instead of applying a patch, you merge the updated branch into your branch. After resolving conflicts (I denoted that as "!*"), your branch contains the information of how you incorporated your changes, and how this relates to the "unpatched" branch. If you have multiple patches, you would have a branch that contains all your patches, and that's what you compile and play.

Regarding tools, if Eclipse really is horrible with git (I don't know), SmartGit is a really nice client that's free for noncommercial use.
___

where's the "trust me, that will work!" switch for the compiler?
Laterna Magica - blog, forum, project, 2010/09/06 release!
silly freak
DEVELOPER
 
Posts: 598
Joined: 26 Mar 2009, 07:18
Location: Vienna, Austria
Has thanked: 93 times
Been thanked: 25 times

Re: Git Migration

Postby Seravy » 30 Dec 2017, 18:23

Thanks, that sounds a lot better!
Seravy
 
Posts: 363
Joined: 26 Oct 2016, 21:23
Has thanked: 5 times
Been thanked: 27 times

Re: Git Migration

Postby ShivaFang » 31 Dec 2017, 21:35

friarsol wrote:5. Stage your content to be added: git add <filenames>
6. Commit the change locally: git commit -m <message>
7. Push the change up with: git push
7a. If it's the first time pushing to this branch, you'll need to specify the remote: git push -u origin <branchname>
8. Create a merge request from your forked repo: https://git.cardforge.org/<username>/forge/merge_requests
Okay, so I have a personal project I am working with that uses Forge as it's base. In order to stay updated, do I have to push the changes or is it enough to commit the change locally? Is it relatively easy to update my source to the latest version if I haven't pushed the change?

With SVN - all I typically have to do is update it every once in awhile and check for merge conflicts. Because SVN sends the entire file, it's easy to see where these changes are and decide how to proceed. I'm a little concerned that with git only sending the deltas that it might muck with what I'm trying to do.
ShivaFang
 
Posts: 101
Joined: 25 Jun 2016, 01:15
Has thanked: 26 times
Been thanked: 3 times

Re: Git Migration

Postby silly freak » 31 Dec 2017, 22:09

As long as your changes are in your local repository (i.e. committed, pushed does not matter), git will help you merge the files. That only deltas are transferred should be of no concern for your workflow.
___

where's the "trust me, that will work!" switch for the compiler?
Laterna Magica - blog, forum, project, 2010/09/06 release!
silly freak
DEVELOPER
 
Posts: 598
Joined: 26 Mar 2009, 07:18
Location: Vienna, Austria
Has thanked: 93 times
Been thanked: 25 times

PreviousNext

Return to Developer's Corner

Who is online

Users browsing this forum: Marek14 and 5 guests


Who is online

In total there are 6 users online :: 1 registered, 0 hidden and 5 guests (based on users active over the past 10 minutes)
Most users ever online was 287 on 31 Mar 2019, 04:11

Users browsing this forum: Marek14 and 5 guests

Login Form