@dcsan you can merge it after updating the wiki generation codes.
After PR is merged, npm install will be required to be run at the time of deployment.

i see #163 as well as this PR. are they going to conflict with each other?

@dcsan no. I merged the #163 to this already before. So I guess, no conflicts.

You can either merge the #163 and modify the update codes and later merge this PR.
OR
You can merge this alone.

But you said earlier that the update code in nap/bin/ directory needs some changes. So better to merge #163 and think about merging this PR later.

@dcsan
#163 is only for updating the .gitignore files.
No deletion of repo files. Just modifications of .gitignore files.

#165 merges #163 and deletes some of the auto-generated or unwanted repo files which were ignored in .gitignore file in #163.

You can add my remote repo and checkout the abhisekp:add-gitignore branch. Then run the following command to see which files are ignored.

git ls-files --ignored --exclude-standard | less

or run the following command to see which files are ignored other than the node_modules and data/wiki/ directories.

git ls-files --ignored --exclude-standard | egrep --invert-match 'node_modules|data/wiki/' | less

i'm sorry but what does this risk and changing my whole deployment setup actually benefit?
is to remove the node_modules from the repo, is there anything else?

@dcsan well, that's the whole thing. Removing node_modules and data/wiki directory. 👍
Nothing more. But this should've been like this from the start of the project itself.
This is not a risky thing though. You can merge the changes in the repo and no need to deploy now.
You can deploy later after some real work done.

I believe this merge won't break things. If anything happens, you can git blame. 😃

i cant ignore the data/wiki
i can remove submodules but not that.

also the update command may pull into there.

did you test it out from a clean repo and try those commands?

i see not much benefit and it could waste hours debugging, so ...

@dcsan yes. the update command auto generates the data/wiki directory contents. So why keep it in the repo and increase the repo size?
I've not removed the data/wiki/ directory. It's there with .gitkeep file in it to keep the directory in place. 😃

@dcsan the data/wiki/ directory is deleted. Lemme add the .gitkeep to data/wiki and see if the .gitignore files are ignoring it.

The demo bot fails. 👎 with update command.

there are 30 comments and two PRs here

and the actual benefit to the project is questionable - changing a .gitignore?

i think you should review this process.

1. attack issues that are meaningful and will have a positive benefit on the project.

2. try and test everything locally before writing lots of comments.

What is the process by which the wiki files are created?

https://github.com/dcsan/gitterbot/blob/master/nap/bin/wiki-update.sh

bin/wiki-update.sh adds them to the main repo from the git submodule, but i usually run that locally before a deploy.

when anyone does an update command on the production server it also checks out the files there "hot" from the sub repo. has the potential for git conflicts then on the next deploy so

https://github.com/dcsan/gitterbot/blob/master/nap/bin/deploy.sh

aims to wipe all that out before deploying.

bit complicated but the best way to keep things in sync.

@dcsan what about using git submodule command to update submodule and then only copy new files to data/wiki/ directory?

I tested it successfully locally. But there is a problem. Whenever the submodule is updated, the main repo tracks it. The submodule can't be .gitignored normally.

ok so there's a problem, right? submodules are a PITA to deal with, but the only option here where we need to track two repos. given you're on windows, anything that works for you may or may not work for me, so ... again not sure what the benefit of opening this can of worms is? esp since you point out it doesn't work.

@dcsan For the record, I test both on my local windows machine and C9 ubuntu.

Why not completely unlink the wiki repo from this repo entirely?

What I'm thinking is that as part of the deploy process you could instead clone the wiki repo into the wiki folder and/or do a 'pull' into the wiki folder.

I find it a little odd that we're basically importing/updating this repo with the contents of the other repo. It means we have duplicated content between the repos.

Instead, lets treat the FCC wiki as the "master" copy, and just pull clones to where we need them, in exactly the same way that we use npm install and bower install to pull down those dependancies. The node_modules and bower_components folder should be part of this repo either for the same reason - they're not "mastered" here, they're just included.

It does mean one more step for an install, and it does mean that the initial deploy will need to have an npm install/bower install as well, but unless you're updating package versions all the time, that's not a big deal either.

@SaintPeter
Making the data/wiki/ a repo directory would create problems if we're pulling from multiple wiki sources.

But it can be made a GIT_WORKING_TREE and checked out to by multiple repos.

@dcsan that other PR #163 is non-destructive. It just adds to .gitignore list. You can merge that freely without any danger.
It's already merged into this one.

If you want, you can close it or merge and close #163 .

@dcsan

Tested OK 👌 👍 Joining 400+ Rooms

Other things not tested

Joined 400+ Chat Rooms. Demo
Time Taken ~ 10 mins

P.S. Test it yourself. (sometimes got Permission Denied Error)

While deploying,

1. run npm install
2. run git submodule update --init --remote --checkout --recursive
   • (needs update to bin/wiki-pull.sh)
3. run nodemon under nap/ directory

Important: Required Update to bin/wiki-pull.sh for update command to work.