-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement ApplyPatchToIndex Class #50
Conversation
@bartkamphorst if you think we should implement this functionality ourselves for now, I'll work on adding tests for this. |
Added specs. If travis passes, should be ready to merge! |
Test suite on Travis succeeded, but coveralls complains: `Coveralls encountered an exception: NoMethodError |
Where are you seeing this coveralls exception? |
In Travis (e.g., #329.1): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my 'Single comments'. 🤔
Fixed by updating coveralls in the Gemfile |
🎆 |
This started as an experiment to see how difficult it would be to implement a version of JGit's
ApplyCommand
that applies a patch to a tree in the repository, rather than to the working directory. See here for a description of the functionality that is currently missing.The new
Plumbing::ApplyPatchToIndex
class is a ruby implementation of this JGit class, or at least of its main logic:ApplyPatchToIndex#build_map
method executes the JGitApplyCommand.call
logicApplyPatchToIndex#apply
method executes the JGitApplyCommand.apply
logicIn writing these methods I just followed the Java code step by step and attempted to translate it to some sane Ruby. It turned out the actual patch application logic was relatively simple: much of the code in the JGit class concerns initializing, copying, and looping over arrays, which we can vastly simplify thanks to JRuby. And another large part of the JGit class concerns making the changes on the file system, which we're not interested in.
I was amazed to find out that the code seems to actually work. :) Try running this test script:
This will produce a treemap corresponding to a revert of the last commit of your target repo. You could theoretically then commit this to the repository by calling
builder.commit
. Neat, if I do say so myself. :)This at least gives us some basis for judging whether we want to implement this code in RJGit, or whether it is too hackish and we need to submit a patch to JGit. @bartkamphorst: I would understand if you still prefer the second option, but wanted to give this a go at least.
Note: the only logic that I haven't implemented yet, because I don't understand it well enough, is this bit concerning newlines.