Looks pretty good! I've added some code review notes above. Can you also add unit tests for this?

I'm unsure about the enumerateStashes: call block format.

It's totally fine with me. That matches other patterns we have in the library.

I know I'm doing strange things with the const GTSignature.git_signature pointer.

Yeah, but I don't think it's your fault. I think git_stash_save should take a const signature.

CC @arrbee

@tiennou Is this ready for re-review? (Sorry, we only get notifications on comments, not commits.)

Yeah, sorry, review away. GitX auto-update system built something that doesn't run on 10.7 so the issue tracker is taking some heat ;-).

I'm still not sure the API's final. It's untested until I write some tests (heh ;-)), and I really would like to implement that first in GitX to have a better "feel". But if this suits you, feel free to merge ;-)

Ah, no, I'd like to wait on the tests. ⚡

Okay, I've started to write some tests and I'm stuck.

I added -[GTRepositoryTest testCanStash] and I'm not getting nil when I call -stashChanges... on the repo there — which I think it should, because the docs for git_stash_save say it returns GIT_ENOTFOUND if there's nothing to stash. Since I have no idea what's in that repo anyway I can't tell.

So I added -contents to GTTree (using the git_tree_walk so I can see what's inside a GTCommit) — is that also missing from the API ? I'm just wondering if Objective-Git can be used to manipulate git without even touching files...

All in all, I need a little help with testing. Is it preferable to build a test repo — I'm not sure how it works atm, apart that it unzips some files somewhere — or use only the API ?

All new tests should be in a Spec file, and use specta/expecta, since they're much more flexible and powerful than SenTestingKit.

Since I have no idea what's in that repo anyway I can't tell.

All of those repositories are in ObjectiveGitTests/fixtures/fixtures.zip.

is that also missing from the API ?

Hmm, it wouldn't surprise me. You could also test it by making sure the changes are gone from the WD after stashing, then reappear after popping the stash.

Is it preferable to build a test repo — I'm not sure how it works atm, apart that it unzips some files somewhere — or use only the API ?

Fixtures are generally kind of a pain in the ass, so I'd avoid adding a new one unless you really need it.

If you do want to add one:

1. Unzip fixtures.zip.
2. Add a new repository folder.
3. Run find . -name '.DS_Store' -exec rm -f {} \; from within the fixtures folder, to make sure that any stray .DS_Store files are cleaned out. _(This may not be necessary, but it was at some point in the past. We should eventually fix up the tests so they just ignore .DS_Store.)
4. Select all the repository folders and create an archive from them. Don't create a zip out of a parent folder, or else the archive won't have the structure that the tests expect.
5. Write a detailed commit message explaining the changes that were made, since the diff will be useless.

Yeah… like I said, a pain in the ass. :\

@alanjrogers @dannygreg @joshaber Can one of you guys review this while I'm gone?

Now I'm getting excited :-)

Sorry, I'm splitting pull requests :-S. I'm merging in #208 for the new -contents API (plus bonus stuff) because the (only) test I added needed access to the insides of GTTree so there's some cruft because it's based on master.

Also, I'm building my local TODO list, so would there be interest in :

• converting all tests to specta/expecta ?
• API support for manipulating repositories in code ? This would allow repositories to be manipulated for quick things instead of having a hard dependency on fixtures (like, eg. more advanced stash tests). Right now I see that can be done using git_treebuilder_insert but the comment says it's your responsibility to put the correct git object in the odb first, which I'm not sure how to do (yet).

Multiple pull requests is fantastic. It makes it much easier to review. 👍

converting all tests to specta/expecta ?

That would be ✨ but not required. Our philosophy has been to just do tests going forward in specta and convert old tests as needed. Probably best as its own pull request.

API support for manipulating repositories in code ?

Again that would be ✨

So many ✨

Superseded by #265.