add option to not delete commit history

[jedwards1211]

I typically keep a ref to the skeleton repo around, because I'm constantly improving my own skeletons, and I often pull the improvements into projects based off of them.

[howardroark]

Hey! Can you maybe give me a little extra info about the use case? Is the idea that you would like to keep a remote called "skeleton"?

[jedwards1211]

Exactly, then if I improve the skeleton I do git pull skeleton master or sometimes even a different branch. I do wish there were a way to avoid having all the prior commits from the skeleton repo in the new project though. Not sure if there's a way to start with one squashed commit and have merges from the skeleton still work.

[howardroark]

So right now there is a complete property in the schema which will run what ever is supplied as a shell command as the last step. In theory you could run git init and then add a remote at that point. In theory that should be able to enable this. Something like...

{
    "complete": "cd {{name}} && git init && git remote add skeleton https://github.com/howardroark/webapp.git"
}

... Haven't tested this... just off the top of my head.

[jedwards1211]

I want to look into this again.

So does the complete command run in the new project directory or its parent? In your README you do git init without cd {{name}} first.

[jedwards1211]

Okay, I tried git init && git remote add skeleton ..., but it doesn't work when I try to pull from skeleton:

git pull skeleton master
From github.com:jedwards1211/es2015-library-skeleton
 * branch            master     -> FETCH_HEAD
fatal: refusing to merge unrelated histories

I tried using force (-f) too, but it still refused. So I guess we would have to add an option to pollinate to not delete the .git directory.

[howardroark]

Yeah, my suggestion didn't take into account that you can't really "diff" two unique git histories anyway. I think in order for this to work you would just want to add some flag property to the base schema that avoid deleting the .git dir, maybe gitHistory:true. You could add an option to the ~/.pollen file on your system... https://github.com/howardroark/pollinate/blob/develop/lib/extend.js#L46

(If that is not an option bin.js could maybe look for a flag and set the "state" property there somehow)

[jedwards1211]

or how about keepHistory? I'd like to make it work as a command line option too.

[jedwards1211]

Also, I noticed that pollinate howardroark/webapp currently fetches from the github API instead of doing git clone. Would it be okay with you if keepHistory flag forces it to git clone?

[howardroark]

keepHistory is good :)

Yeah... The GitHub part just downloads a tarball of only the files. Which is nice for speed and doesn't require the binary.

I'd say start with adding the option to the git fetch stream then later see if it makes sense for another flag to be set which redirects username/project to git fetch somehow. I think that option may be useful on it's own anyway. Mainly cause the API method does have rate limit restrictions.

[jedwards1211]

@howardroark okay. But keepHistory can't do its job if it gets the tarball from GitHub can it? If we don't make it force git clone then we should warn if it won't take effect because we're downloading straight from GitHub.

[jedwards1211]

hmmm, looks like cli-argparse doesn't support args like --keep-history that aren't followed by something I'll have to tweak the cli-argparse config

[jedwards1211]

nevermind that last comment, I speak too soon