balduin

Why not moving to Git?

17 posts in this topic

https://github.com/0ad/0ad

https://github.com/0ADMods

Curious, was there ever a discussion about moving everything to Github @ any point?  I tend to find Trac under large histories to be extremely slow while doing queries (even w/ small teams).  Something that Github developed which might help w/ large blobs ... https://git-lfs.github.com/

I don't do enough game development to give opinion but just curious where previous discussions might have ended up.  

2 people like this

Share this post


Link to post
Share on other sites

Moving to Github was not really considered because we want to be in control of things ourselves and not have to depend on another service working or even existing years down the line.

4 people like this

Share this post


Link to post
Share on other sites

@feneur Thanks for making that clear!

While GIT may be an alternative revision controll system for us to use (as main repo) we definitely should have the project on our "own" server.

(Also there should be a clone on a PC physically owned by a team member)

1 person likes this

Share this post


Link to post
Share on other sites

Good point about GitHub ... a friend recently moved a rather large project from Trac to GitLab (which is like a self hosted GitHub, probably even better) but his only reason was that pull requests were easier to manage than manual patches.  Will leave the links here (but this sounds like a case of - the process is not broken, so don't fix it ;-) It seems like SVN/Trac has been used here for so long.

https://about.gitlab.com/

https://github.com/moimael/trac-to-gitlab 

1 person likes this

Share this post


Link to post
Share on other sites
On 10/20/2016 at 1:12 AM, jonbaer said:

<...> but his only reason was that pull requests were easier to manage than manual patches

Btw, it's possible to clone 0ad repo on github, create a branch for some feature and in any moment have a SVN-compatible patch for these changes.

I'm currently slowly working on #2305, I initially attached a SVN patch for it, but then realized that I want to do a lot of small incremental updates to it, a final version won't be ready soon and it would be much more convenient to have a git branch for an interim period: the latest version is published as soon as I push a new commit, all changes are visible as separate commits with messages and diffs and the ticket isn't cluttered with a lot of intermediate patches (it's already cluttered enough with all those research results, current state reports and discussions :)).
'Comparing changes' page allows to see both overall diff and log of all commits present in the branch: https://github.com/0ad/0ad/compare/master...AlexanderOlkhovskiy:stk-stun
Diff can be downloaded and applied to SVN copy using the same link (with appended '.diff'):

curl https://github.com/0ad/0ad/compare/master...AlexanderOlkhovskiy:stk-stun.diff | patch -p1

 

2 people like this

Share this post


Link to post
Share on other sites

Is there any news or anything one could do to help to make the transition from SVN to Git possible?

Share this post


Link to post
Share on other sites

If you want you can use the git clone on git hub. Biggest issue with git is binary files which if hosted on their local server would reduce HDD space drastically. AFAIK @Itms is looking for a way to avoid that but until then no git migration will be made.

Share this post


Link to post
Share on other sites
1 hour ago, balduin said:

Have you thought about using Git Large File Storage (Git LFS): https://git-lfs.github.com/.

If we use that we don't have the files on our server - which is what we want to avoid.so that's not an option IMO.

1 person likes this

Share this post


Link to post
Share on other sites

@FeXoR In this case I misunderstood the problem. However, what is so different besides using SVN and Git for large files? I mean yes, small changes on big binary files require to rewrite the files and create a lot of traffic, but how is SVN different or more efficient?

Share this post


Link to post
Share on other sites

(I guess I should write a slightly longer answer to this and related questions since this seems to pop up regularly.)

TL;DR: SVN works. Why don't you use git, you can do so right now (either one of the clones on github/gitlab, or via git-svn)?

Why (still) SVN?
It works.
More details: Partial checkouts are supported (which some contributors needed due to network limits), it doesn't require users to download the whole history (same reasoning), checkouts can be resumed (helps with unstable network connections). Apart from using shallow clones or incremental shallow clones this isn't possible with git. Keeping autobuilds for windows users (which is needed for artists) in the repo is not an issue (yes, there have been discussions and plans for how to solve this for git; but that is some work nobody has volunteered for yet).

Why not git?
There's a git clone (github and gitlab) so nothing stops you from using it right now, and we do accept git patches just the same as svn patches. If you don't like that you can use git-svn directly (which works fine). Educating users about git is more work than doing the same for svn, also this question ignores artists and modders and increases the barrier of entry for new contributors. Also most git GUIs are quite bad, which is somewhat important for those users. Programmers should be able to use their tools and can already use git right now.

Why not git-lfs or git-annex or git-whatever?
Those are third-party extensions and require more administration work. Of course we could move all to some third-party hosting platform, but those might impose arbitrary limits or just cease to exist. Also that seems to counteract one of the main advantages of a DVCS namely being distributed and not being locked to a single central repository. (These approaches tend to have issues with having the full history available locally, which makes bisecting issues harder. Also they do list merge conflicts for binary files as one of the rough edges. (I'm not sure how those would interact with signing commits, which would be one of the things to consider if switching to git.))

But I want to submit pull-requests?
No. Diffs work, man git-format-patch might be worth reading.

Why not just merge things?
A merge-based workflow creates issues with bisecting issues, so one would have to educate users about rebasing their work on top of the main branch. (Not very entertaining in the long run (and that refers to both points).)

What could be done instead?
Reroll the git clones in a nicer way by excluding all build artifacts (the current clones have a few incremental stages, and are likely not excluding everything). However this should be planned carefully, since this is going to break the "upstream" for a lot of people and I would strongly recommend against doing this more than once.

10 people like this

Share this post


Link to post
Share on other sites

I pinned this topic as it's one that comes up often and Georg's reply explains things nicely.

Share this post


Link to post
Share on other sites
21 minutes ago, FeXoR said:

Maybe also set @leper's last post as "Best answer"?

That would require changing the settings for this forum, and I generally don't think it's going to be a matter of questions and answers very often here. Feel free to convince me otherwise though :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now