Aversion to Git?

● ARCHIVED · READ-ONLY
Started by Lemur 20 posts View original ↗
  1. Started RPGM somewhere around the 2000 versions way back when, and realized the scripting system for the new versions was in Ruby. Amusingly enough, I work professionally in it. Call it a nostalgia trip that I'm around looking through scripts a bit.

    I've noticed something odd though. It seems a lot of the scripts posted are on pastebin or dropbox. Why the aversion to git? There are a few more advanced types on here using it, but really a lot more should be.

    Speaking of which, if there are people looking for code reviews shoot me a link, or tag me in a comment on github ( @baweaver - http://www.github.com/baweaver )
  2. Well, some scripters AFAIK are not really a programmer. They just can script.

    Pastebin and dropbox offer more simple to use. While git offer many features yet they don't know what are they.

    When you just want to send a script, it's easier to use dropbox or pastebin. But if you want version control and better organization, you may need git. However, most scripter just want to send the script easily.
  3. TheoAllen said:
    Well, some scripters AFAIK are not really a programmer. They just can script.

    Pastebin and dropbox offer more simple to use. While git offer many features yet they don't know what are they.

    When you just want to send a script, it's easier to use dropbox or pastebin. But if you want version control and better organization, you may need git. However, most scripter just want to send the script easily.
    Too many people tend to put the term programmer on a pedestal for their own goods.

    I almost wonder why RM doesn't have a system like gems just to drop in and version components as well. Wouldn't it be so much faster just to have a collective repository that used something like Bundler to resolve all the dependency conflicts? The raw power from that component alone would make a lot of it worth it, but it depends on how far RGSS wants to approach Ruby I suppose. Thinking aloud a bit, don't mind me too much on that part.
  4. Were gems already widely used around 2012?
  5. Widely enough that I was using them fairly commonly. I know at least by February they were in very common use in the community. It was created back in 2003 as a way of managing code and got into the StdLib at ~1.9: http://en.wikipedia.org/wiki/RubyGems
  6. I haven't figured out a way to organize scripts that are


    -public


    -private


    -under development that should not be publicly accessible


    I can see putting up public stuff on git(hub?), but then I'd have to remember to copy stuff over cause not everything should be publicly accessible.


    If I maintain my own repository without public access I can then control which files are accessible or not through a single file.
  7. Tsukihime said:
    I haven't figured out a way to organize scripts that are

    -public

    -private

    -under development that should not be publicly accessible

    I can see putting up public stuff on git(hub?), but then I'd have to remember to copy stuff over cause not everything should be publicly accessible.

    If I maintain my own repository without public access I can then control which files are accessible or not through a single file.
    Yeah, that was always one thing that annoyed me about using it. I tended to cheat and just use bitbucket instead to get private repositories for free.

    Really though if you're developing things you can just keep the repo local and only push things to a test branch instead of merging them all to master.
  8. Lemur said:
    Widely enough that I was using them fairly commonly. I know at least by February they were in very common use in the community. It was created back in 2003 as a way of managing code and got into the StdLib at ~1.9: http://en.wikipedia.org/wiki/RubyGems
    Ah that would make sense. I was wondering if when VXAce was released, were gems already that popular. It probably was seeing as 2003. I guess the problem with this is that RM isn't really a program that does patches but releases every 3 years. 
  9. You know if the devs frequent here at all? That could be a major selling point if they properly integrate it.
  10. Lemur said:
    Really though if you're developing things you can just keep the repo local and only push things to a test branch instead of merging them all to master.
    Personally, I use an "unstable" branch to push all commits to until I'm at least fairly certain that a script I'm working on has reached a stable point; from there, I generally merge into the master branch, create a tag, and release. This ensures that anytime someone wants to access one of my scripts (or Enelvon's, since we work as a team very often) they will always get a stable version from the standard GitHub URL for the repository -- and if they want to try an unstable version, they can explicitly select that branch.


    As for the aversion to Git, I imagine a lot of it comes down to intimidation -- to be fair, Git can seem incredibly complicated at first to a lot of people; the vocabulary alone seems off-putting to many (commits, branches, stashes, refs, and so on). In addition to that, command-line interfaces can seem very intimidating in general, and most Git GUI tools don't really ease anyone into using it. At first, it can feel like an uphill battle that just isn't worth the time and effort to learn when you can just drop text files into a folder which is synchronized via Dropbox.


    Of course, the reality is that it's actually quite simple, and the benefits of using it are vast. As a relatively brief example, my SES Console script is available on GitHub: as such, anyone can easily download the latest stable version as soon as it's released (as a raw file), download any release they wish (at the Releases tab), browse changes committed to the code base (via Commits), and even view the developer documentation for it (on GitHub Pages). And that's not even mentioning the fact that anyone can fork the repository, make changes, and submit pull requests to us for any features or bug fixes they wish to see happen. Enelvon and I started hosting all of our scripts on GitHub for all of these reasons, and more.


    But there's a bit of a problem here, too: a lot of scripters in the community still view Git as something like Dropbox -- instead of storing actual source code, they store entire projects (I've seen this too many times now). That's not what Git is for, and the way Git works is really less-than-ideal for storing a large amount of binary data (or in RPG Maker's case, serialized Ruby data). In addition to that, storing serialized project data is also anathema to the entire point of Git (and GitHub, in particular): it's collaboration-hostile.


    Really, I'd love it if more scripters took the time to learn how to use version control, whether it's Git, Mercurial... even Subversion or something else. Unfortunately, I just don't really see it happening.


    I'd like to be wrong.
  11. tbh, I find Git overly complicated and confusing.


    I just need somewhere to drop my scripts for others to be able to easily access. Pastebin does everything I need, and is easy to use.
  12. I think Git is awesome for projects that have more than one person contributing or working on it. Most of the people around here that can script, work alone though, and they probably see Git(/Hub) as an overkill if they just want to share the code they just created.
  13. Git is great for version control.


    Dropbox has version control but I find it difficult to use (you can only do it through the web-interface from what I've seen)


    There are many GUI tools available for git that make the process pretty simple if you just need to push and pull stuff. I'm currently using SmartGit and it works pretty well.
  14. Even tho, I also use git, I'm not very familiar with it. Release tab seems good, but I somehow a bit afraid to use if there will be something wrong happen. My code already released and I just noticed the release tab a month after.

    What I like in Git is the version control. And also the wiki!
  15. Why not simply use Gists? I do that for some RGSS-related scripts. Pastebin-alike + public or secret visibility + simple revision control + comments is good enough for me in this case, even though I don't think many people need the last two features.
  16. I just use SVN because it's simple, I'm the only person working on my project, and I just want version control and some peace of mind wrt. my work.

    I use Git at work and find it completely overkill for this type of project. I'd only really consider it if in a project with several others, and even then probably only paired with something that would automatically pack/unpack rvdata files into raw text and back, so I don't have to deal with managing that every time I want to commit something.

    Git itself is honestly not as complicated as it initially seems, but it's definitely got a learning curve to it. It made a lot more sense to me when I started using the command line interface. It's still extra overhead I'd want to avoid when possible, though. Then again, I don't spend much time working on public scripts. If I did, I might look at things differently.
  17. I used to use SVN, but with just me working on it (up until now), even that was a nuisance. I don't care much for version control - as long as I have the latest working version, I'm happy.


    That'll probably come back to bite me one day.
  18. Hm. What if I wrote up a tutorial for getting things set up? I tend to write tutorials as is. I might write a few on integrating Git and other tools into RGSS workflows as I get time later on.
  19. Shaz said:
    I used to use SVN, but with just me working on it (up until now), even that was a nuisance. I don't care much for version control - as long as I have the latest working version, I'm happy.

    That'll probably come back to bite me one day.
    It will, and when it does, you'll wish you used version control. Been there, cried my tears. Never again :)

    The benefit of using software like Git and making many documented commits is that it improves your coding abilites as you go along: You start realizing that when you have to succinctly explain what your changes do, you learn to make better changes. For me it's an invaluable tool for "quality" control as well: After a few days I'll spend an hour or two going over my code changes and optimizing things, or patting myself on the back if all looks great still.
  20. Admittedly I'm tempted to bolt on some form of test-driven development to further increase the stability of scripts.