07:56 <luis> drmeister: I've squashed your pull request. How's your git-fu? Let me know if you have trouble with it. (Please don't push a merge commit. :-)

15:42 <drmeister> My git-fu is weak.

15:43 <drmeister> I have a few patterns (push, pull, checkout) that I follow but I am not comfortable outside of that.

15:44 <drmeister> So where are we right now?

15:44 <drmeister> What does "squashed your pull request" mean?

15:44 <drmeister> luis: Ping

15:49 <ck_> drmeister: squashing commits means 'merging' multiple commits into a single one. Your pull request was merged.

15:49 <drmeister> I see - thank you.

15:51 <ck_> for more context: squashing is an operation during a rebase, where you can reorder commits, drop individual ones, change the commit messages and so on. The idea is to have the history in a more clean state, a linear one, without commits like "merge branch xzy from abc" that have multiple parents

15:58 <luis> drmeister: but because you've submitted your pull request from your master branch you'll need to update it a bit differently than you're probably used to. git pull --rebase should do the trick.

15:59 <luis> drmeister: that will try to apply your commits on top of the new slime master, and it'll notice that they're redundant

16:01 <drmeister> I was going to nuke my local copy and clone fresh from your original - is that ok?

16:02 <drmeister> I see - I also have a fork that I'd need to nuke - it's different from yours.

16:04 <drmeister> This is where git makes me very, very nervous. I can't tell you how many times I've screwed things up and spent hours-days cleaning up.

16:05 <drmeister> I'm going to wipe out my fork and the local clone that I used to make these changes. I don't have the mental bandwidth to deal with git at the moment.

16:06 <luis> drmeister: I understand that. Nuking is of course fine.

16:08 <luis> git's got a very steep learning curve. I've helped many, many coworkers migrate to git. I've seen all sorts of chaos and confusion.