For #153 #154
For #153 #154
Conversation
| @@ -1 +1,3 @@ | |||
| vendor/ | |||
| composer.lock | |||
| composer.phar | |||
There was a problem hiding this comment.
Should we keep composer.lock out of here?
http://stackoverflow.com/questions/12896780/should-composer-lock-be-committed-to-version-control
There was a problem hiding this comment.
From personal experience, including the lock files always ends with some sort of confusion over why things won't update when people are testing changes.
I understand this is contrary to what stack overflow says.
It's bitten me before many many times, and I make it a habit not to. With the understanding that I need to know what I'm doing if deploying straight from the git repo on a production environment.
There was a problem hiding this comment.
On second thought, maybe I'm being too biased. Let's try it the 'correct' way. But if it turns out to be a serious PITA I'll issue a PR to get rid of them.
|
So we are going to have a ResourceService that is one index.php file? |
|
Nope. I just renamed everything so there's only ResourceService. It is split apart with providers. |
|
Oh okay, I get it now. |
|
Yeah, that PR is muddy b/c of how it views renaming and deletions. No worries. |
|
@daniel-dgi did you do a git |
|
plain ol' mv |
|
Ok, that makes sense then. |
|
@daniel-dgi this isn't the refactor stuff for #148, right? |
|
No, but it's something that needs to go because it's SUPER confusing to have an example and the real implementation side by side with similar names. Just a quick cleanup I did before I started the refactor. |
|
Cool. @whikloj, @DiegoPino how are y'all on this one now? Good to merge? |
|
@daniel-dgi gotta rebase now since I merged #152 |
|
@daniel-dgi, i don't want to be a pain, but could you re-do this using git mv? |
|
I'll just close and re-open, trying with git mv to see if it's any better. |
|
Superceded by #155 |
Removing old ResourceService example.