support keepHistory (or --keep-history) flag

[jedwards1211]

if given, pollinate won't delete the .git directory

fix #35

[coveralls]

Coverage increased (+0.4%) to 78.025% when pulling 78ed0331618f50d6eb37403c568cdd7876b08207 on feature/keep-history into 1fa2745537363b2b0d5c99b7cea880abfa683119 on develop.

[howardroark]

Woohoo! I'll try this out locally soon.

[jedwards1211]

I'm setting up my es2015-library-skeleton project to use pollinate now, check it out!

[howardroark]

Awesome! Well I'm happy you are finding this useful. It's great to have more feedback/ideas.

[coveralls]

Coverage increased (+0.3%) to 77.955% when pulling 7ec2b86bc1c6cd60df36fbbb4740147d0e2e400a on feature/keep-history into 1fa2745537363b2b0d5c99b7cea880abfa683119 on develop.

[coveralls]

Coverage increased (+0.3%) to 77.955% when pulling 7ec2b86bc1c6cd60df36fbbb4740147d0e2e400a on feature/keep-history into 1fa2745537363b2b0d5c99b7cea880abfa683119 on develop.

[jedwards1211]

I completely forgot to document this in the README, I'll make another PR for that

[jedwards1211]

@howardroark also, I didn't realize until now, this doesn't actually make it possible for me to pull in any and all changes from the project skeleton, because I would be pulling in changes to the template files, rather than the results of pollinate transformation. D'oh!

I'll have to think for a bit about how to deal with this. What I'm thinking is a pollinate pull command that pulls changes from the skeleton into a new branch, does the usual transform, then merges back into the current branch.

[jedwards1211]

@howardroark for more background on this: I've sometimes made improvements to my project skeletons that I want to easily pull in to all of my projects that are using them. For instance, I've added various helpful npm scripts, semantic-release, switched from pre-commit to husky, etc.

[howardroark]

@jedwards1211 Yeah... I was thinking you would just be using this to run diffs and maybe sync assets.

My view is that you benefit in new projects as your base evolves from learnings in existing ones. I think a certain amount of refactoring is always required in getting new things to work in existing projects...

[jedwards1211]

Okay, I restructured my skeleton projects in such a way that I can at least pull in package.json updates that don't involve template variables. Instead of just having pollinate parse package.json directly or parsing a PROJECT-package.json and then moving it into package.json's place, I put only template stuff in PROJECT-package.json:

{
  "name": "{{ name }}",
  "version": "0.0.0-development",
  "description": "{{ description }}",
  "repository": {
    "type": "git",
    "url": "https://github.com/{{ organization }}/{{ name }}.git"
  },
  "author": "{{ author }}",
  "bugs": {
    "url": "https://github.com/{{ organization }}/{{ name }}/issues"
  },
  "homepage": "https://github.com/{{ organization }}/{{ name }}#readme"
}

And then I merge it with this script (run from `complete):

#!/usr/bin/env node

var merge = require('lodash.merge')
var fs = require('fs')
var merged = merge(require('./package.json'), require('./PROJECT-package.json'))
fs.writeFileSync('./package.json', JSON.stringify(merged, null, 2), 'utf8')

That way the skeleton project can have a valid package.json that I can update, but its name, description, etc. get overwritten by the parsed fields.

So yeah, I think this will prove useful to me!

[howardroark]

I kinda see two things going on here...

1. Add a merge after parse that takes and an array of json files to merge on top of each other
2. Move discard to after move (so that the .git removal and check can go there)

merge: [
  ["package.json", "PROJECT-package.json"]
]

Then you don't need that script. Plus you can also then discard PROJECT-pacakge.json. The git upstream won't care if you are just merging down updates and that commit is in the same repo.

[jedwards1211]

@howardroark That would be cool! I wasn't sure if you would consider it worthy of being a specific feature in pollinate. My only concern is whether people would want to merge other types of files (YAML, XML, etc), though it could operate based upon the extension.

[howardroark]

I'd say start with JSON and and if someone wants to add other object file formats... not a big deal to support. I think it's nice to have example configs that don't have all sort of template tags!