Suggestion to add as update-able submodule vs clon

[groue]

Hi @devinrhode2 ! I'm sorry, but I won't accept this pull request as it is.

Maybe the "how to" section does need a rewrite. But I want it short, and I want it to target lazy noobs as well as first-class hackers. Noobs should get the minimal required information, and hackers should be informed and certainly not nannied.

In this perspective, git submodule fails both , and git submodule + defunkt/hub even more :-)

[groue]

BTW, I did not know about defunkt/hub. Thanks, Devin!

[devinrhode2]

git submodules are pretty simple. I noticed you have 6.0 out and want people to update. How? git submodules answers that.

FYI I like your little philosophy on documentation.

[groue]

@devinrhode2 Sure I'd like people to update. Yet, I have no illusion. Basically, GRMustache provides a Mustache engine that you can hack in, and iterations have a single purpose : lift the spec limitations, one after the other, relentlessly. Only a few people really need an update :-)

Now, on submodules. I really think they are a power-user feature of git. Of course you can manage your submodules with a few simple recipes. However as soon as your repo's state gets of the rails (and shit happens), a precise understanding of submodules is necessary in order to fix the situation. And I do not want anybody to open an issue saying "You told me to use submodules. Now clean up my shit."

Plus: GRMustache has its own submodules. Did you, Devin, download them? If so, there is no harm. If you did not, it's perfectly fine as well. Unless you want to embed the raw GRMustache sources in your project, because in this case you need to download the JRSwizzle submodule. The two others, JSONKit and Mustache/spec, are only used by the test suites. Would I talk about submodules, these informations should enter the README in order to prevent the questions people would eventually ask ("I want to upgrade to GRMustache 6.1: should I run git submodule update --recursive or git submodule update?" - "Why does GRMustache need JSONKit?" - etc.)

Look at this issue : https://github.com/groue/GRMustache/issues/16. Two guys copied the single "GRMustache.h" header file in their project, leaving the rest of the distribution header files in some other unreachable directory. Of course Xcode would not find the hidden headers, and would not compile. How am I supposed to fix this situation? The real resolution is having those guys learn about "headers include paths". And I was nice enough to do that in the issue comments, instead of directly sending them to http://whathaveyoutried.com/. Should I update the README and write "Import GRMustache.h and make sure you keep its sibling headers in the same directory"? What's the point? Lazy noobs would overlook it anyway, and hit another wall eventually. And those extra words would be noise for the decent programmers. The README is not a course on how to use your tools, git and Xcode.

Look at this tweet: https://twitter.com/asmallteapot/status/259001799791501313 : "Are there any good GRMustache alternatives that don’t want you to include it in your project as a static library?" That guy failed to see that he could compile the GRMustache sources himself. How am I supposed to fix this situation?

No. I just want to make explicit the uncommon and easy options: static library and CocoaPod. I can't afford after sales service for anything else.

Actually, following this trend of thought, I should remove the mention of "git clone" :-)

[devinrhode2]

Man I really like the way you think!

-Devin http://zerply.com/DevinRhode2 http://zerply.com/devinrhode2

On Thu, Nov 1, 2012 at 2:09 AM, Gwendal Roué notifications@github.comwrote:

@devinrhode2 https://github.com/devinrhode2 Sure I'd like people to update. Yet, I have no illusion. Basically, GRMustache provides a Mustache engine that you can hack in, and iterations have a single purpose : lift the spec limitations, one after the other, relentlessly. Only a few people really need an update :-)

Now, on submodules. I really think they are a power-user feature of git. Of course you can manage your submodules with a few simple recipes. However as soon as your repo's state gets of the rails (and shit happens), a precise understanding of submodules is necessary in order to fix the situation. And I do not want anybody to open an issue saying "You told me to use submodules. Now clean up my shit."

Plus: GRMustache has its own submodules. Did you, Devin, download them? If so, there is no harm. If you did not, it's perfectly fine as well. Unless you want to embed the raw GRMustache sources in your project, because in this case you need to download the JRSwizzle submodule. The two others, JSONKit and Mustache/spec, are only used by the test suites. Would I talk about submodules, these informations should enter the README in order to prevent the questions people would eventually ask ("I want to upgrade to GRMustache 6.1: should I run git submodule update --recursive or git submodule update?" - "Why does GRMustache need JSONKit?" - etc.)

Look at this issue : groue/GRMustache#16https://github.com/groue/GRMustache/issues/16. Two guys copied the single "GRMustache.h" header file in their project, leaving the rest of the distribution header files in some other unreachable directory. Of course Xcode would not find the hidden headers, and would not compile. How am I supposed to fix this situation? The real resolution is having those guys learn about "headers include paths". And I was nice enough to do that in the issue comments, instead of directly sending them to http://whathaveyoutried.com/. Should I update the README and write "Import GRMustache.h and make sure you keep its sibling headers in the same directory"? What's the point? Lazy noobs would overlook it anyway, and hit another wall eventually. And those extra words would be noise for the decent programmers. The README is not a course on how to use your tools, git and Xcode.

Look at this tweet: https://twitter.com/asmallteapot/status/259001799791501313 : "Are there any good GRMustache alternatives that don’t want you to include it in your project as a static library?" That guy failed to see that he could compile the GRMustache sources himself. How am I supposed to fix this situation?

No. I just want to make explicit the uncommon and easy options: static library and CocoaPod. I can't afford after sales service for anything else.

Actually, following this trend of thought, I should remove the mention of "git clone" :-)

— Reply to this email directly or view it on GitHubhttps://github.com/groue/GRMustache/pull/29#issuecomment-9974369.