Added Chinchilla Puns

[einzruff]

I added several Chinchilla puns. Practicing making a pull request to send my changes upstream.

[nishakm]

@einzruff Do you want me to give you a practice task?

[einzruff]

@nishakm Sure, what were you thinking?

[nishakm]

@einzruff how about trying to squash your commits into one commit? This would mean doing some git rebase. Have you set up git to use your text editor of choice?

[einzruff]

Ok. Yes, I'm using Vim. I'm looking up git rebase and trying to understand it. Looking online I see there are different opinions/methods for the best way to accomplish rebasing, but the general process is: (with my branch being einzruff/puns)

1. Checkout your master branch, nishakm/puns.
2. Do 'git rebase master' to take all of my commits and replay them on your commit.
   • It gets diffs of mine vs yours, resets the current branch to your master branch, and applies the changes to it. The advantage is a cleaner history instead of it showing all of my multiple commits in the history.
3. I then do something like, 'checkout master', 'git merge einzruff/puns', 'git commit -m "squashed commits"', 'git push origin master'?

I see there is an -i interactive flag for to interactively choose which commits to rebase. 'git rebase -i HEAD~3' passes my last 3 commits to squash.

[nishakm]

@einzruff you've got the general idea - git rebase allows you to apply the changes you've made to your working branch onto the branch that you have specified one at a time. The pro is that when you submit your PR, there are no merges in your branch i.e. a clean history. The con is that for each commit you have on your working branch, you will have to resolve conflicts if the commits do not apply cleanly, which can be a pain if you have a lot of commits.

Since your method of updating your fork's master is to merge the upstream's master, you will have merge commits when you submit your PR (I am assuming your commit 3c55efe fix chinchilla puns conflicts was such a commit?). The easiest way to get rid of the merge commits is to squash all of your commits into one, which to git is using the command git rebase -i. The HEAD~3 part tells git that you are rebasing the commit at HEAD and the 2 previous commits in a way that you will choose later.

So what you would do is this:

$ git checkout master (if you are not already on your fork's master branch)
$ git rebase -i HEAD~3

This will open up your text editor (in your case, vim) and there you will choose the option to squash all 3 of the commits into one (I forget what letter you will have to choose, but the text editor will tell you I think). After you choose 'squash', you will have a chance to edit the commit message so you can make a summary message.

Once you do this though you will have to force update your remote branch as you have now rewritten your git history.

git push -f origin master

Try this out and let me know if you have any issues with it. Thanks for keeping it up!

[einzruff]

I believe I resolved the conflicts and squashed the commits.

[nishakm]

Hmm...interesting. Your PR to me shows that there are now 8 commits instead of the original 3. If you had squashed the commits you would see only one commit in your PR. Do you think you can post your command history here?

[einzruff]

(I'm not sure why GitHub markdown comments interpret HEAD~ as strikethrough, changed to ` so it doesn't show everything as formatted strikethrough.)

I might know what happened. I typed git rebase -i HEAD`3 and it listed those 8 commits. The only one I changed was the last commit listed (mine), I changed it to 'squash'. The other 7 commits were listed as 'pick'. I then did a commit, 'rebase onto e964c64'. Heres the command history: git init git clone https://github.com/einzruff/puns.git cd puns git checkout master git rebase -i HEAD~3 git rebase --edit-todo git rebase --continue git add . git push -f origin master (I think this didn't work, because it told me I had to merge, so I did a commit) git commit -m "rebase onto e964c64" git push -f origin master

[nishakm]

A few things:

• you don't have to git init before git cloning. git clone creates a directory and runs git init in that directory
• From the logs it looks to me like you did a merge from origin/master into master rather than upstream/master into master and that seems to have finagled your git history a bit
• The edit-todo flag is something I am not familiar with but it looks useful for doing a git rebase -i on the same branch. Incidentally, git rebase -i is difficult on a branch with a lot of merge commits as the merge commit brings in a lot of other commits as you have seen here.

I can merge this and you can try to update your fork by doing git fetch upstream to update your upstream remote and then git merge upstream/master and then start over with trying to squash 3 commits (remember not to include a merge commit when squashing)

Alternatively, you can start from scratch by doing git reset --hard 3886d4e which is resetting your branch to the last commit that is tracking the upstream master and then git push -f origin master to rewrite your remote branch.

Let me know what you would like to do.