Skip to content
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

Closed
wants to merge 65 commits into from
Closed

Split GTRepository API #297

wants to merge 65 commits into from

Conversation

tiennou
Copy link
Contributor

@tiennou tiennou commented Nov 12, 2013

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 :

I'm not sure if the others are worthy of separate PRs or not...

…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.
@dannygreg
Copy link
Contributor

Holy sweeping change Batman! This seems great but I don't really have time to dig through all of this at the mo.

@joshaber
Copy link
Member

I'm fairly 👎 on the inRepository: pattern. It doesn't feel idiomatic to me.

I love the idea of breaking up GTRepository a bit more. That said, some of these changes mean these objects will change in place. I'd rather not give up immutability in those cases.

@jspahrsummers jspahrsummers mentioned this pull request Nov 12, 2013
@tiennou
Copy link
Contributor Author

tiennou commented Jan 15, 2014

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 inRepository: feels too, but I was mostly following the CoreData insert*blah*:inManagedObjectContext: idiom, because I don't another way of splitting GTRepository (but I'm open to suggestions, as always).

@jspahrsummers
Copy link
Contributor

I can rebase against current master

We prefer merging instead of rebasing for published branches, because then the conflict resolution is apparent, and no history is changed or lost.

submit separate PR for each of those splits

👍

I was mostly following the CoreData insert*blah*:inManagedObjectContext: idiom

It's pretty bad in Core Data too. I don't particularly like that framework as inspiration for API design. :trollface:

GTRepository could be broken down into functional categories—like a category for branching, a category for refs, etc. Then the methods are still "on" GTRepository, but we don't have one .h/.m pair that's thousands of lines long.

@tiennou
Copy link
Contributor Author

tiennou commented Jan 17, 2014

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).

@tiennou
Copy link
Contributor Author

tiennou commented Sep 12, 2014

Stop that. It's silly.

@tiennou tiennou closed this Sep 12, 2014
@tiennou tiennou deleted the split-gtrepo branch August 15, 2016 14:41
@tiennou tiennou mentioned this pull request Aug 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants