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 https://guides.github.com/features/issues/
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 ?
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 https://github.com/makemek/ATOLS_Awaodori 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 GitHub.com
for more glossaries, please go to this link
https://www.kernel.org/pub/software/scm ... ssary.html