Jump to content

Why not moving to Git?


Recommended Posts

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.  

  • Like 2
Link to comment
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 

  • Like 1
Link to comment
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

 

  • Like 1
Link to comment
Share on other sites

  • 2 months later...

(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.

  • Like 11
Link to comment
Share on other sites

  • feneur pinned this topic
  • 7 months later...

Part of the problem migrating is that there's a bunch of stuff in the repository that shouldn't be in a code repository at all.  Plus

  • We have all of the "default" 0AD mod/resources in the same repo as all engine code.  These are really orthogonal, and belong in separate repositories.
  • We have many dependencies in the repository.  These do not belong in a code repository, but some sort of binary repository/dependency management system (eg, Nuget in the C# world, or maven for Java).  C++, however, has not traditionally used one of these systems.  
  • The final, built binaries, are in the repository.

Ideally, we should probably be doing something like:

  • Git repository for main engine code (+ some small default resources).  This can be self-hosted, or use an existing provider and backup a copy every day.
  • Dependency management repository for code artifacts.  There are some out there for C++, although we will likely have to host at least some of our own.
  • Git repository for the "default" 0AD mod code
  • Repository/ies for art source files.  Note that the goal would be to have no "built" items in a live repository, instead:
  • Dependency management repository for built art files.  This also gets used by:
  • Binary repository that combines art files and mod + engine code into the finished product.

 

.... which would be quite some work to set up.  I think the best first step, though, would be to start getting dependencies out of the main repository and into a package management system.

  • Thanks 1
Link to comment
Share on other sites

Which package management system remember that we support three separate platforms so three systems would be needed and who would by necessity code them they do not exist for Windows or OSX those binaries are only for Windows as most of our users share that OS and very few have the knowledge to build from source these users are also mod developers that need access to the latest build.This has been proposed several times and the consensus has been it's to much work for minimal benefit we already have have a Git mirror though it does trail the main SVN repository by a few commits.

Enjoy the Choice :)

  • Like 1
Link to comment
Share on other sites

On 16/01/2017 at 7:32 PM, niektb said:

re: git GUI: for Mac and Windows there is a fairly non-programmer client available: https://desktop.github.com/ 

SmartGit is much more user-friendly, it supports Git & SVN, it's free for personal use (you just have to enter a fake email during the setup/installation process).
PS: no, I am not affiliated in any way with them. :rolleyes:    I have just tested many git GUIs.

 

Regarding "moving to github", while I understand the arguments for not moving the whole repository to github (and I agree with most of the points), I still think it would be interesting (in term of "ease of use", speed, sorting options) to just move the bug tracker to Github. There are tools to perform this task : https://github.com/robertoschwald/migrate-trac-issues-to-github

Frankly, Trac is sooo slow and so un- user-friendly. It's sort of a pain to use it.

With Github, you can create milestones, tags (labels), assign developers to issues, link other issues in comments by just typing the issue ID, get donations for fixing issues (with Bountysource), mute comments, embed code lines in comments, ... but the speed and ease of use guys, frankly it's night and day.


 

Edited by xanax
  • Like 1
Link to comment
Share on other sites

Do you think that the most known and largest open-source code hosting platform & version control system in the world would shutdown just like that?

Without warning the 20 million users and maintainers of 57 million repositories

The company announced, on 29 July 2015, that Github raised $250 million in funding and at the time, some financial reports valued the company at approximately $2 billion... I don't think they will shutdown anytime soon.... ^_^

CodePlex shut down but measures were taken for the migration and no developer was taken by surprise.

I understand your point to keep control of your repository and bug tracker but by doing that, you continue to use outdated and inefficient tools while you could increase your productivity and interactivity with your contributors by using modern tools like the Github bug tracker. You are afraid of a possible future Github shutdown but it's not going to happen before many many many years.. (if that happens).

  • Like 2
Link to comment
Share on other sites

Trac is not outdated :) https://trac.edgewall.org

I'm wondering though how using the github bugtracker here would help in efficiency ?

Phabricator though was a great tool for productivity
 

Quote

You are afraid of a possible future Github shutdown but it's not going to happen before many many many years.. (if that happens).

 

Not likely indeed, but who knows maybe 0ad will still be in developpement for the next 50 years ? :P

 

Link to comment
Share on other sites

There were 2 instances of big platforms creating problems in the last few years:

  • SourceForge chose to replace installers with their own and added ads/additional software to them
  • Google Code shut down (to be fair to them, they made it easy to migrate to GitHub)

Also, GitHub (as opposed to Git) isn't free/libre.

So, as long as Wildfire Games has the manpower and money to maintain their own, they should stick with it. And a webserver maintainer isn't necessarily an application programmer as well, so maintaining the thing probably doesn't take that much away from development time.

Personally, I'm a big fan of Bazaar because the commands are dead easy, but sadly their tools are seriously undermaintained these days.

  • Like 1
Link to comment
Share on other sites

On 22/08/2017 at 2:15 PM, stanislas69 said:

I'm wondering though how using the github bugtracker here would help in efficiency ?

Just an example: clicking on Active Tickets takes ~ 20 seconds just to display the page...

And I am not talking about how painful it is to create custom tickets queries.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...