-
Notifications
You must be signed in to change notification settings - Fork 280
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
Split GTRepository API #297
Conversation
…dir` version. Because I don't want to handle the pain of relativizing the passed URL.
I know there's still a test in here, but I'm not sure what it's testing since we're ARC now…
Fixes a bug where a locally-cloned remote would get a `file:` URL as it's origin URL, making the push machinery shrivel in fear.
You use the concrete subclass to restrict the object type you're expecting. Good bye, `GTObjectType` ;-).
Conflicts: Classes/GTBranch.m
Conflicts: Classes/GTReference.m Classes/GTRepository.m
Conflicts: Classes/GTRepository.m ObjectiveGitTests/GTRepositorySpec.m ObjectiveGitTests/GTTagSpec.m
Holy sweeping change Batman! This seems great but I don't really have time to dig through all of this at the mo. |
I'm fairly 👎 on the I love the idea of breaking up |
If you prefer, I can rebase against current master (that'll remove the test->spec that are showing up here), and submit separate PR for each of those splits. @joshaber I do agree about how |
We prefer merging instead of rebasing for published branches, because then the conflict resolution is apparent, and no history is changed or lost.
👍
It's pretty bad in Core Data too. I don't particularly like that framework as inspiration for API design.
|
OK, I'll publish PRs for some of those then. +1 on the CoreData design. I just thought of "split" as "move stuff over to some other classes", while you see it as categories. Categories it will be then (I'll have to rewrite some of those PRs though). |
Stop that. It's silly. |
As was hinted in #224, this moves some parts of the API away from GTRepository. It's based on #292. This only leaves repository "properties" and high-level API in
GTRepository
.This changes the following :
-lookup...
methods toGTObject
, based on the called class.GTBranch
andGTTag
.I'm not sure if the others are worthy of separate PRs or not...