[02:38:58] can someone explain how to rebase an old patch with long array syntax using phpcs? [02:40:38] e.g. legoktm? [02:40:48] hi [02:41:24] First, checkout master, run composer update, etc. so you have mw-codesniffer 0.6.0 installed [02:41:41] done [02:42:20] Then checkout old patch, run ./vendor/bin/phpcbf [paths your patch touched] (Normally you could use "composer fix [paths]" alias, but that was only introduced in a recent version of core) [02:42:42] Then git commit --amend your changes, and run git rebase [02:43:02] you may colour me skeptical but I will see what happens [02:44:41] how old is the patch? :P [02:45:23] september https://gerrit.wikimedia.org/r/#/c/236508/ [02:46:03] so it gives a whole lot of conflicts in the neighbourhood of changed array syntax [02:46:41] since I am cherry picking a diff which supposedly converts array syntax, it is looking for the context of that syntax change, but sometimes not finding it [02:47:34] 11 chunks [02:47:41] TimStarling: use a merge tool [02:47:47] like meld [02:48:08] unless both patches actually change the same lines, meld will be able to resolve the context by itself [02:48:28] (i rebased a couple of pre-short-array patches with it seamlessly) [02:50:48] you mean run meld on the result of running git rebase? that doesn't seem to do anything useful [02:51:03] maybe it depends on a recent version of meld or something [02:51:50] it just shows conflict markers as added text [02:52:37] TimStarling: `git config --global merge.tool meld`, then run it with `git mergetool` after `git rebase` (when you have files with conflicts) [02:53:06] ok... [02:53:49] then Changes -> Merge All in the menu, and save if all conflicts are resolved. repeat for each file. [02:53:55] (i have meld 1.8.3) [02:54:23] there is probably a way to automate this entirely, but i never had to rebase enough files to bother. :) [02:57:36] I don't think this is really helping [02:58:29] so what I want is a diff with short arrays on both sides [02:59:19] how about I jscbf the base and separately jscbf the patched version [02:59:45] then I can compare the resulting two versions and generate a patch from that [02:59:55] and then that will be more or less mergeable into master [03:08:36] * TimStarling is figuring out how to automate this [03:10:35] funny that nobody tried this until now [04:28:44] how do you get the commit message for a given commit? [04:33:36] git show sha1? [04:36:49] "git log -1 --format=%B" seems to do what I want [04:38:08] it shows the unwrapped commit message so you don't have to remove the indenting or anything [04:43:03] ok, so it appears to have actually worked [04:43:30] I seem to have a fully automated jscs rebase tool [04:44:55] https://gerrit.wikimedia.org/r/#/c/236508/4 [04:45:12] phpcs I should say [04:45:19] I actually keep making that typo on the command line as well [04:45:48] you see, I work for the parsoid folks for a few months and it infects my brain [04:50:12] * robla reads backlog to figure out how the parsoid folks infected Tim's brain [04:52:42] heh, I read a lot more than I needed to in order to figure that out :-) [04:53:35] but on the plus side, I now have some meld esoterica to stash somewhere and then forget [17:41:24] in fundraising extensions we have a lot of ad hoc url parsing and building, would prefer to follow core's lead if possible. i was wondering if there's a current standard lib or best practice? [17:44:48] cwd: wfParseUrl() ? [17:47:22] bd808: thanks...indeed there in our old mw too. dunno why it's not in use in our extensions. [17:51:44] either nobody found it (E_TOOMANYFUNCTIONS) or somebody thought they had "a better idea" [17:54:06] from the looks of it about 10 people thought they had a better idea at some point [17:56:26] bd808: lol @ E_TOOMANYFUNCTIONS [17:56:35] I actually thought that was a real one for a sec [18:01:48] bd808: It does exist, just not in php. [18:01:56] SC2 Client Galaxy error code e_tooManyFunctions [18:34:30] greg-g: Would you mind if we backport https://gerrit.wikimedia.org/r/#/c/276207/ quick so https://logstash.wikimedia.org/#dashboard/temp/AVNcob7pO3D718AOt5cM has useful backtraces? [18:35:42] anomie: sounds find [18:35:43] fine* [21:33:21] ori: do you have a bit of time to test/review a bit of mw-vagrant hackery? -- https://gerrit.wikimedia.org/r/#/c/276241/ [21:34:14] bd808: looking [21:34:44] thanks. trying to deal wiht not getting rid of some hhvm cruft that we should have ditched months ago [21:38:33] bd808: why not package { 'hhvm-fss': ensure => 'purged', before => Package['hhvm'] } ? [21:39:28] that wasn't working at one point in my testing [21:39:46] I can try again. [21:39:54] * bd808 looks for another broken vm to fix [21:40:35] testing this is a pain because the hard parts are all related to having a busted vm to fix [21:41:15] bd808: if you have tested your current patch, and it works, then let's go with that rather than risk something that looks prettier but doesn't work [21:41:33] I just found another vm to test on [21:41:49] The part that was busting it before may have been the conf ordering [21:46:47] ori: using page + purged seems to work. I'll update the patch. [21:46:57] sweet [21:49:56] ori: updated [21:59:55] RFC meeting starting now in #wikimedia-office [22:04:15] bd808, tgr: It looks like we only missed some really sneaky stuff for load.php MW_NO_SESSION. There's the HttpFunctions issue that I have a patch up for, the LanguageConverter issue I have a patch up for, a Flow issue that's in Phab, 'mainpage' in $wgForceUIMsgAsContentMsg that may really get annoying once Commons gets wmf.16 (Krinkle is working on this, but he's currently blocked on also wanting to replace $wgLang usage with RequestContext at [22:04:15] the same time and that's currently making Wikidata tests fail), and two log entries that something somewhere used $_SESSION. https://logstash.wikimedia.org/#dashboard/temp/AVNdYxZjO3D718AOwZ7s is a dashboard filtering out these known issues. I'm out for now. [22:05:24] anomie: o/ seems like a full day's work [22:08:26] Commons got wmf.16 an hour ago [22:08:42] does 'really annoying' mean lot of logs, or something worse? [22:13:00] a log event every time something in load.php calls Title::newMainPage() I suppose? [22:13:59] yeah log spam is the current problem I believe [22:15:08] I see, the RL startup module calls it for the wgMainPageTitle JS variable [22:17:04] the log spam isn't too horrible. ~100 events / 5m [22:17:43] but that is mostly common so I would guess it's going to spike like crazy with group2 tomorrow [22:17:53] *commons [22:40:44] some, possibly most of commons is due to wgForceUIMsgAsContentMsg and that does not affect group2