Git Migration

[Goblin Hero]

Old auth with the forum name/pass is back. Please test.

[Agetian]

Looks like it's working well. Thanks!

- Agetian

[Seravy]

Today is the 2 months anniversary of starting the migration so...how is it going? Like, progress in percentages or something?

[friarsol]

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.

[Goblin Hero]

Should I put old SVN to read-only mode or just shutdown it?

[KrazyTheFox]

We should leave it read only for the time being, just to be sure everything transferred correctly.

[Goblin Hero]

Should be read-only now.

[hidalgo]

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?

[Seravy]

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)

[friarsol]

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.

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.

[Seravy]

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.

[silly freak]

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.

[Seravy]

Thanks, that sounds a lot better!

[ShivaFang]

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.

[silly freak]

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.