[11:48:03] scott_gonzalez: wrt referencing 'src/PointerEvent' vs. '../pointerevents', I had tried the latter yesterday, but it throws "TypeError: scope is undefined" [11:49:26] In which file? [11:49:53] Oh, it's probably failing because it isn't designed for AMD. [11:50:13] The ES6 change should actually fix that. [11:51:00] You shouldn't actually need to reference the files at all. [11:51:19] Unless this is not using the existing test runner. [11:52:28] I guess intern.js doesn't go through https://github.com/jquery/PEP/blob/master/test/runner.html at all, right? [11:54:48] So I guess you should be referencing pointerevents.dev. [11:55:03] And you have to run grunt before running tests. [11:55:15] Which you'll need to do after the ES6 change too. [12:11:18] correct, it is not using runner.html [12:13:39] i believe it can pull that in, via .get(require.toUrl('./SomeTest.html')), but I didn't go that route. I'll give that a try, in lieu of the ES6 changes. [13:03:51] i pushed some changes to the 'use-intern-for-testing' branch to address the formatting and src references. 'with' is still there, and need to resolve against the ES6 changes. [13:06:09] jperrault: do you know how to rebase changes against master? [13:06:35] i've read about it, but never done it. [13:07:17] and I don't think Scott's ES6 changes have been merged yet. [13:09:10] i just notice that the PR has a bunch of commits from master [13:09:33] looks like your branch is based against an older version of master and then you just merged master in at some point [13:09:54] if you run `git rebase master` it should just end up being the changes you made without any of the extra commits [13:10:11] ususally do a 'git pull upstream master' before making changes, stashing if necessary, and merging on m side. [13:10:43] Not sure about others but i know i prefer to avoid merge commits and rebase [13:11:21] yeah merge commits are basically forbidden on all the projects i lead :) [13:11:28] im fairly sure thats scott_gonzalez preference as well [13:11:45] the merged commits introduce an interleaved history so it is impossible to know at what point something actually landed [13:11:48] so far I've been lucky, and haven't had to merge anything...so it probably ends up being the same thing as a rebase. but it sounds like that won't be the case here. [13:11:55] snover: yeah same here and on jQuery foundation stuff in general actually [13:12:24] snover: but this project does not have to follow that if people don't want to. [13:12:37] ( but i REALLY hope they do lol ) [13:12:40] my changes are relatively superficial, and on a small number of files. looking at the ES6 PR, a rebase wouldn't be a big deal for me. [13:12:54] well when this feature is landed even if the PR is not rebased i would hope the person doing the commit would pull, rebase, and fixup [13:13:15] Yeah, I had commented on that in the PR. [13:13:32] https://github.com/jquery/PEP/pull/158#issuecomment-72568031 [13:14:29] It does look like `git rebase origin/master` will likely fix it. [13:15:19] The master branch on your fork is 30 commits behind jquery master. [13:15:37] But it doesn't have any additional commits, so that's good. [13:16:06] I should just trash it. The fork was created from the pointerevents repo before it became pep. [13:16:25] although the pointer is right, perhaps something is wrong. [13:16:34] You should be able to: [13:16:37] git checkout master [13:16:44] git reset --hard origin master [13:16:47] git pull [13:16:59] Assuming origin is pointing to jquery/PEP [13:22:44] hmmm. doesn't like the reset. fatal: Cannot do hard reset with paths. [13:22:56] sorry [13:23:00] git reset --hard origin/master [13:23:00] :-) [13:24:23] scott_gonzalez: just so you know, i am the only one that is allowed to tell people the wrong thing :) [13:25:12] it’s kind of my thing. [13:25:16] snover: I'll try to control myself in the future ;-) [13:26:05] thanks, i appreciate it 😘 [13:26:23] sudo rm -rf * [13:27:08] Reminds me of when I first started using git. [13:28:10] i have a love hate...or is it love/hate...relationship with it. mostly hate. [13:28:15] the learning cliffs of git are breathtaking [13:30:48] so, what do I with my existing use-intern-for-testing branch now that I've rebased? [13:31:32] once you properly master rebasing git is easy [13:31:43] until your super comfortable with that i think it can be pretty roigh [13:31:52] rough [13:32:16] I always make a copy of what I'm about to destroy, that softens the blow. [13:33:54] jperrault: [13:34:02] git checkout use-intern-for-testing branch [13:34:04] git rebase master [13:34:31] That will rebase your intern branch on top of your master branch. [13:34:50] In other words, it takes the unique commits from the intern branch and replays the diffs on top of the HEAD of master. [13:35:00] ok, that seemed right. but I can never wrap my head around what is local, and what isn't. my only comfort is that I'm not a committer, so I can't really screw things up. [13:35:57] I could go over some git stuff with you on a call sometime if you want. [13:36:30] Git is fairly complex, but if it's explained right, the common/important stuff is pretty easy to understand. [13:36:33] the git is strong with scott_gonzalez [13:37:06] Once you've got your branch updated, you'll need to use the -f flag to push. [13:37:06] :-) I've got the basics, but now that the chance of stepping on toes exists, that would be helpful. [13:37:11] Because you've rewritten history. [13:37:17] The -f is for failure ;-) [13:37:45] snover: The smartass remarks are reserved for you too, aren't they? [13:38:11] The -f is actually for force pushing. [13:38:26] Git tries to prevent you from rewriting history in a remote. [13:38:54] -f on master === everyone hates you lol [13:38:56] scott_gonzalez: no, i have no exclusivity over those :) [13:39:32] No smartass remarks and no wrong information. How boring. [13:40:18] i think scott_gonzalez would shrivel up and die if you denied him smart ass remarks [13:40:21] I normally use: git push -u origin meaningful-name-of-branch. So add a f flag to that. [13:40:37] yeah [13:40:52] and never push to master. even your own :-) [13:40:55] The -u is only needed the first time. It sets up which remote branch to have your local branch track against. [13:41:00] k [13:44:36] The rebase on my branch worked up until: CONFLICT (content): Merge conflict in src/touch.js [13:44:46] I don't recall touching that with any of my changes. [13:44:56] hmm.. [13:45:13] evidence to the contrary... [13:47:00] Now I'm really confused about what happened to create this merge. [13:47:12] So, another thing you can try if you can't figure out what's going on with that conflict. [13:47:18] Just replay the changes manually. [13:47:21] git checkout master [13:47:35] git checkout -b intern2 # create a new branch to work in [13:47:54] git cherry-pick 56b93e3 # replay the diff of the first commit onto your new branch [13:48:36] If that works, you should be able to `git cherry-pick 1639218` to replay the diff of your second commit. [13:52:58] i think you just broke my brain. this isn't like trying to resolve ui with mobile where understanding what happened is critical. It may be easier for me to just delete my branch and put the changes back in place. there really aren't that many of them. [13:53:59] plus it is time to make the donuts around here. [13:54:15] jperrault: resolving ui / mobile is my speciality ! [13:54:42] arschmitz: I'm aware. and not jealous. that title is all yours. [13:54:47] lol [13:55:46] i need to step away. i'll take care of this later. thanks for all the help, I appreciate it!