Integrate git Into The Beatmap Editor

Total Posts
This is a feature request. Feature requests can be voted up by supporters.
Current Priority: +7
Topic Starter
NOTE: This thread may contain some technical jargeon words. For clarification, please refer to "technical jargeon clarification" section at the bottom of the thread.
Since the beatmaps notes (.osu) is basically a plain text file. It would be a great idea to use git to control each subversion. Just like how OSU! is developed, it evolves over time for example, new feature is implemented, updates, patches, hotfixes, etc.

Creating a beatmap works simlarly to a software development cycle. It has to go through a lot of changes in order to get ranked officially. Upload beatmap -> Review (make changes) -> Modder Review -> QA -> RANKED.

The main idea is to integrate git into the beatmap editor. This allows mapper to track changes by each commits they made. If mapper made an unrecoverable mistakes, they can simply revert (reset HEAD) back anytime they like. If they come up with new ideas and would like to try, they can do so while lefting the original intact.

With version control, beatmapper have more freedom to map without worrying too much. Therefore, making better beatmap's quality and reduce the chance of map being thrown to the graveyard. Modders can easily review, compare, and give more precise explanation.

Although, one can easily instantiate git (git init) onto a beatmap folder. It becomes intimidating when comparing between 2 commits or branch because the file is not human-readable. Tracking changes works fine but you have to be quite skilled on using command-line.

Introduction to the problem
When creator creates a beatmap, they have to make backup often in case of something goes wrong. The problem is that there will be a LOT of backup files. Although OSU! editor allow beatmapper to revert back to last saved, it cannot reverted back far enough. If they would like to test a map. Editor requires them to save a file first. Undoing each step back seems very tedius. Let alone when they exit OSU!, comeback later realize that they made a huge mistakes at some part of the song. They have to fix it by hand or restart all over again.

Moreover, after the creator submit a beatmap, modder response back requesting a fix. To make sure modder approves, creator have to sends files (Post .osu content on the thread) or resubmit a beatmap and notify modder. They may have to create another backup again. Note that each .osu file posted on thread may get cluttered a lot on the forums.

The thread may also contains unrelated replies (ex. players comment on the thread). Both .osu file and modder request may not be noticed by mapper and modder respectively. In git, modder can update beatmap by simply using just one command call "git pull" to update beatmap without entering OSU! and find that beatmap

Modding beatmaps is like teaching friend's homework over a facebook chat group. It works, but it takes a lot of time to come up with the same understanding.

There are so many benefits of using version control (git) to beatmap

For Beatmap Creator

1. If mapper made a huge mistakes or they didn't like the outcome, they can revert to any previous commits.

2. If the creator has some awesome ideas and would like to try something new, all they have to do is just create a new branch from what they currently working on. If they like it, merge branch. Otherwise, simply go back to their original branch with all notes left intact.

3. Creator can work on multiple computers (by using "pull" command) to sync beatmap notes without having to carry a copy of files with them (Beatmap commits have to be pushed on github website first). NO MORE SENDING .OSU FILE ACROSS THE THREAD. Thus, reduce workload on osu!'s server side and avoid confusion between creator and modder.

4. Creator can freely continue mapping without having to wait for feedback from Beatmap Modder.
Creator release the finished-version on "release branch". Then, just continue working on "development" branch as usual. Modder will be notified automatically as long as they follow the reporsitory.

5. Enables Collaboration with other beatmap creators!!. Multiple creator can collab on the same difficulty with ease.

6. If modder request a fix, create a new branch -> fix it -> notify modder -> if modder is satisfied, merge the fix

For Beatmap Nominator/Modder

1. Can FOCUS on what really matters
By posting issues on github instead of being cluttered by all unrelated posts on the original thread
for more detail on git "issues" feature click here

2. Easily track changes without having to have a copy of previous version.
They can simply just compare diffrences between 2 commits. In fact, they can see changes in any versions they prefer. This will provides more flexablity on both creator and modder. The problem is that the raw .osu file is too hard to understand by human. If there is a program to interpret and visualize these data into user-friendly readable form, it would be awesome :)

3. Point out problems easier and more precise. They can assign type of issues and to whom. They can also verify what issue is solved.

4. Have their current-tracking beatmaps all-in-one place. Fork -> Pull for updates -> Done

5. Modder can track changes with changelog. Who made changes ?, what changes ?, when ?

For community

1. Get in touch with the latest pre-release from their favorite beatmapper. Note that Beatmap Creator has to have an account on github or other similar sites that host source control
By subscribing to RSS feed in "public activity" section on github. It also kind a solve this popular feature request as well t/30678

2. They can also contribute to a beatmap too. By creating a pull request, creator can review change and decide whether to accept a request or not.

3. Fork beatmap with just a click a away!
From github, OSU! webboard, or even from a command-line

Analogy to software aspect.
Beatmap Editor <--> IDE (Integrated Development Environment)
Beatmap <--> reprository/project.
Beatmap notes (.osu) <--> source code.
music, custom skin, custom hitsounds and background image <--> libraries or software dependencies
Beatmap creators <--> Developer
Modders/Beatmap Nominators <--> Tester
Quality Assurance Team <--> Software QA
A beatmap ranked is similar to deploying a software. In this case, it is a beatmap that we all love.

PS. If this feature is implemented, it would be nice to have some guidelines on how to be effective using this feature. The explanation above is just a very basics of git. It can do much more beyond we need. One can feel intimidating when using it for the first time.

For those who interested in what it looks like, I have pushed beatmap to github as an example. You can see all changes that I made. I uploaded only necessary branch. There are a lot more locally (ex. Quick fix, off-timing fix)

Since beatmapper may not be a developer, the feature should be easy to use and not require much technical knowledge on using git.

------ Technical jargeon clarification ------
Git: What is it ?

Repository: A project where source code resides.
Commits: A commit, or "revision", is an individual change to a file (or set of files). Act like a restore point
Branch: A pararell version of a repository
Merge: takes the changes from one branch and applies them into another branch.
Pull: Fetching changes from server
Push: sending your committed changes to a remote repository such as

for more glossaries, please go to this link ... ssary.html
I have never released a map before, but this would be AWESOME to have.
I manually commit updates to my own repo, but If git was integrated in osu >.< It would save me lots of time.
While I agree that osu! should have some form of version based backup system, git is complete overkill.
i agree


1.) Helpful, but already requested
2.) Isn't this the same as 1.)?
3.) Can be helpful, but sending .osu is easy, and those files are just 10-50 kb
4.) Wut? You start looking for mods, AFTER you finished your map, I see no point in this
5.) Requested before
6.) NOOO. If a modder makes changes and sens you the .osu file, it's Always worse, considering mappers also have opinions, and thus find some things in the mod really bad. I also decline quite a lot of mods, just because they "break the map"


1.) What? They still need to focus on the same things for a map to get ranked, I don't understand how this would help them
2.) Why? If the mapper made a change he liked, but modders like it not, he'll just get some complaints about that part. If they don't know the old part, they will do this a lot less, also, .osu files are easy to understand if you work with it a lot (which I do)
3.) How exactly? Modding doesn't change anything AFAIK
4.) YOu can just search for mappers in the song select
5.) ONLY mappers should be allowed to make changes in his own beatmap, or it'll not be his style anymore


1.) Creator's need to upload a map first, before it comes available, this'll completely brake it, especiialy if it's for graveyarded maps
2.) GOD NO. I'm already strongly against modders editing the map, let alone the 'dumb' (not knowing much about mapping) people edit it
3.) To fork? Wut?
Strongly against
Can be useful, but it's already partly integrated, but this can make it go faster
Duplicate request
I don't understand this one, considering I'm not known to GIT

As you see, I really disagree with most parts in this
Sorry, I am a little late on this post.

baraatje123 wrote:

3.) To fork? Wut?
Means to create a copy of a project, and be able to change it without affecting the original... Its pretty much copy/paste in a single button.

This would be a big integration.
Although, you could simply 'Puush' your .OSU file and back it up yourself.

Since a part of the focus is about being able to say why you changed certain parts. This would only be useful for collab projects, and even then, usually you have a 'similar' idea as the other person in a collab project so you don't need to outline every little change. I just say 'I moved a couple things, tell me if you don't like them'. Easy!

It seems that this idea is involving people into someones project a bit too much,

baraatje123 wrote:

it'll not be his style anymore
There is a point where others get TOO involved in a map which can lead to a very inconsistent map.

To tell people why you changed a certain thing is time that could be spent making a map better instead.
Also, wouldn't everyone have to make a GitHub account then?

As I said before, a lot of your post seems to be focusing on 'Involving others' and 'Involving modders easier'. I kinda disagree with that. Now I've just realised I'm kind of echoing what 'baraatje123' said so I'll stop here...
Roxy Lalonde

TheVileOne wrote:

While I agree that osu! should have some form of version based backup system, git is complete overkill.
Git is built not just for version control, but for control across many collaborative systems. It's the kind of system that allows teams to work on high-standard software in a controlled system. A server to host repositories using Git would be costly, too. It's already known how much extra work the server goes through for graveyarded maps.

The authentication systems of Git may not sync well with osu!'s native authentication (I haven't looked too much into this.) and it also requires forced encryption using RSA keys.

I think a better solution would be an option to save historic backups of .osu files or even entire song folders on a host user's drive, rather than on the cloud.
As a mapper, I dont really need many backups, If there's something I want to change back, I'll remap it. If people suggest a mod, well, then I'll apply it if it's better. I wont apply it if I like a previous version more. Just wanted to point that out ... :v

As stated by 'Proph Nobster', Git is used to simulate a local network, allowing multiple clients to connect to a single SQL server and work on a single project at once. (Like google docs, but for programmers, and its more advanced) which means that if ever integrated with Osu! would bring a lot more features that many wouldn't understand and not need/use. It's just too much.

Proph Nobster wrote:

it also requires forced encryption
I always thought it used 'Force Protocol Encryption', not JUST 'Force Encryption'. Was I wrong?
For anyone wondering, YES, there is a difference between the two.

Proph Nobster wrote:

using RSA keys.
Haha, I'm trying to imagine everyone who maps having to carry around an RSA SecurID key XD
Why on earth did you have to bump this
Kinda serious, why did you bump this, As I only der negative feedback from you
It's better to keep it 'unbumped' then
As stated un my post 3months ago, I still really disagree with this
It's the mapper's choice to change things, not the modder's (and most definitely not the not-mapping-part-of-the-community)
Please sign in to reply.

New reply