I would like to implement a Rake task that automates some of the tasks I have to do to move my changes from development to production (and yes, I know there is something out like Capistrano, and it is way too much for me). In the center, there are some interactive commands like git add -i and a series of commit and push. On the production side, there will be pulls and assets tasks to do.
It is tedious to type in all the time the same commands so I would like to automate it completely. What I have not found is the Ruby API for Git.
It should work under Windows 7, and allow at least the following commands: git add, git status, git commit, git push, git pull.
I know, bad habit, but I would like to document the experiences of this weekend:
There is a similar question on https://softwareengineering.stackexchange.com/questions/62843/best-ruby-git-library that names the 3 relevant candidates: Git, Grit and Rugged.
Git and Grit are not developed further, Rugged is currently developed, but not finished.
Git works out of the box, but has some deficiencies:
There are known shortcomings (see the issues).
I had the problem, that added and changed items are not well matched, they can be in only one of the 2 states (which is not true for Git currently).
The API is reasonable, and works well in console, Ruby script or Rake task.
Grit did not work for me at all, and I did not found the reason. I got stack traces (low level ones), and tried a few patches that could be relevant for usage under Windows 7, but with no success.
Rugged is not installable for me, so I filed a bug to rugged which got some feedback. The problem seems to be that rugged only works for POSIX systems, so it is not compilable with DevKit for Ruby.
So I will try to find a compiled version of libgit2.dll for Windows 7, and will try to use that. I have done that in the past with sqlite3.dll, so perhaps that is the best try. For me, rugged is the most sensible solution, because there are people behind that project, they are interested to provide a solution that works cross platform.
This one seems to be quite popular. If you are more interested in GitHub then you might want to look at this one.
UPDATE:
Rugged seems to be the newest one out there though the Gem for it has not been built in a while. Might be best to use the source from Github.
July 2013 update:
It looks like Rugged is the tool of choice at the moment. It is being actively maintained and it looks like most (all) of the core committers work at github.
Even though grit is the most popular, and is created by one of the github founders, it hasn't been touched for 5 months and has had little activity.
See Ruby-Toolbox for details.
Related
We're using rack-test for our Cucumber specs. We've been trying to migrate over to Ruby 3 for a while now and the current issue is that the Cucumber tests crash due to rack-test using both keyword/positional args in their internal methods.
I'm up for patching it myself, but seeing how little activity there is on the repo (including PRs open for weeks/months) I fear that I'd do the work and there would be nobody to patch it.
The only alternatives I see are:
Do the work and pray there will be someone to review/merge the changes
Patch it locally & use the patched version locally from now on (yuck)
Find an alternative solution for rack-test
The last solution seems the best IMO. So, are there any alternatives?
As with all open source software, you have a few options:
Keep using the old software version (i.e. don't use ruby v3.0.0).
Hope that someone else updates the dependencies for you.
Do the update yourself.
Stop using the library.
At the moment, option 1 is totally viable; ruby 2.7 is still actively maintained, and support will probably continue until 2023-03-31. You could do this, simply hoping that option 2 becomes available soon.
The standard practice for option 3 is:
Fork the project, and make the fixes.
Open a pull request to the main repo with your fixes. Hopefully it gets merged.
In the meantime, if you need to be unblocked, reference your forked repo in other projects.
This is clearly more effort, but I wouldn't call it a "yuck" solution; not unless your changes are drastic/introduce compatibility issues with the main project, and the two branches diverge.
As for option 4, as with virtually any library replacement, there's always going to be some trade-off between compatibility/features, but clearly other testing frameworks do exist. It depends how you are actually using it. Your mileage may vary.
In summary, I can't really give an objective answer to such a subjective question, but my advice at the moment would be: If you have time/skill/motivation to update to ruby 3 right now, then fork the dependency and update it. (It's probably not a massive change needed!).
But if you lack the time/skill/motivation to do this, then just stick with ruby 2.7 for now.
I'm kinda new to using composer (but I think it is awesome) so please pardon the noob question.
Folks are requesting exports fancier than csv so I thought I'd install phpOffice excel using composer. But, the master is 'build failing' and the develop is 'build error'. An I correct in assuming the master build failed means I should not install this with composer because it won't work?
In researching this I also found phpOffice spreadsheet, but that appears to be in development still.
Any other alternatives if I cannot use phpOffice excel due to the build status issue?
Regardless of what package you are talking about, if the builds for any of the branches are failing it just means that the builds for any of the branches are failing, that's it.
The master and develop branches may be well ahead of the latest tag, and chances are the maintainers are experimenting with it, and working towards a passing build again.
If you trust the maintainers not to release broken software, then it's safe to use one of the tagged versions, so for example, run
$ composer require phpoffice/phpexcel:^1.8.1
to install the latest stable version.
Note It appears that phpoffice/phpexcel:1.8.1 has been released on 2015-05-01; quite some time has passed since. Whether or not this package works for you, then, is something you have to find out for yourself.
For reference, see:
https://packagist.org/packages/phpoffice/phpexcel
I've written a sprockets processor for losslessly compressing jpgs and pngs, you check it out it here: https://github.com/botandrose/sprockets-image_compressor
However, I can't use this gem on heroku, because the jpegoptim and pngcrush programs aren't available within their environment. Furthermore, users of the gem will need to remember to install these programs on every system they want to use my gem. So, I think it'd be nice if I could vendor in these binaries as a fallback if the system doesn't have them installed already.
So, is this totally crazy? Would I need to provide a 64bit binary as well as a 32bit? Would I still require some sort of external library to be installed? Would I be better off writing some sort of C extension that hooks into these programs?
I haven't seen many gems in the wild that do this sort of thing. One other option, however, is to provide rake tasks that go out and fetch the programs if they aren't already installed on the machine. It might be tricky to make it work for all the different platforms, though.
With regard to using your gem on Heroku: remember that Heroku has a read-only filesystem (except for the /tmp directory), so running Sprockets processors like yours on Heroku isn't really a practicable option anyways. I personally just use rake assets:precompile and commit all the precompiled assets to my Git repo before pushing to Heroku. Yes, I know it messes up the repo history, but it's the easiest way to go (at least for now). Hopefully Heroku will come up with some other option in the future.
As far as the main question you asked, hopefully someone else can provide a good answer. Your project looks very cool; I am just going to try it out.
I'm trying to understand how to use GIT with Xcode 4.2.
I haven't been using GIT actively, but while I was walking through a couple of git operations mentioned in this link it appears that I have a single repository with many projects in it and a recent project in a repository all by itself.
I want to carefully take the project I am currently working on and put it into its own repository so I can safely leverage some of the branching capabilities.
I'm hesitant to begin until I have a better understanding of what's going on. I'd like to know how much is handled within Xcode and what I have to do at the command line.
#manojids comment to learn a source control system (like git) outside of a specific editors integration is a good point. Try to understand the source control system. The integration is a convenience, not a crutch.
Outside of that advice, apple has some docs outlining specifics of how XCode works with git. Here's the link:
http://developer.apple.com/library/mac/#documentation/ToolsLanguages/Conceptual/Xcode4UserGuide/SCM/SCM.html
A good online resource is the pro git book available here:
http://git-scm.com/book
If you want to learn and understand Git and its concepts in detail then this book would be best for you here is the link.
Or you can have a drill on it practically if you follow this tutorial.
I hope you will get help.
Is there a decent Subversion client available for XCode? I am so tempted to write my own as of this morning after having a conflict on an update. I've done merges manually editing the ">>> mine" and "<<< theirs" markers but there has GOT to be a better way in this day and age. Does anyone know of an easy way to resolve conflicts graphically? It seems like SCM conflicts and svn history queries are my two most missed features in all of the Mac SVN clients I've seen so far. I use Versions and sometimes the built in XCode SCM support. I've also looked briefly at Cornerstones web site. (Is Cornerstone any better?) Does anyone have any ideas?
I'd suggest using git-svn with GitX for most things. The GitX commit interface is so nice it's really hard to go back to anything else.
For conflicts I use Emacs, which offers really nice, fully editable, color-coded 3-way merge.
You also might check out the WWDC 2010 videos/slides (free at Apple's site if you're a registered developer) regarding SCM support in the upcoming version of Xcode.
As a GUI, SmartSVN offers a basic conflict editor (though I find the the application very slow to refresh on a large source tree). Often I find myself going back to Emacs which has support for subversion via Psvn.el, and that has a very capable 3 way diff with ancestor revisions, custom region skipping and other goodies.