00:05:08 <Eksell> Unstable branch on CRAWL.XTAHUA.COM updated to: 0.23-a0-577-g2b1de94 (34)
01:28:09 <Gretell> Unstable branch on crawl.develz.org updated to: 0.23-a0-577-g2b1de94 (34)
01:58:53 <Gretell> Windows builds of master branch on crawl.develz.org updated to: 0.23-a0-577-g2b1de94
02:59:55 <Gretell> Monster database of master branch on crawl.develz.org updated to: 0.23-a0-577-g2b1de94
06:26:48 <Cheibriados> New branch created: pull/922 (1 commit) 13https://github.com/crawl/crawl/pull/922
06:26:48 <Cheibriados> 03bjobae02 07https://github.com/crawl/crawl/pull/922 * 0.23-a0-578-gd20f901: Refinement of Amulet of the Acrobat 10(12 minutes ago, 7 files, 12+ 22-) 13https://github.com/crawl/crawl/commit/d20f90118d3d
08:31:34 <advil> I'm not sure about that PR, does it really make things clearer?
09:18:13 <switch__> i don't think so
12:08:26 <Henzell> Unstable branch on crawl.akrasiac.org updated to: 0.23-a0-577-g2b1de94 (34)
13:04:23 <floraline> what's the proper way to pull updates from a branch after it was force-pushed?
13:05:04 <gammafunk> floraline: I think just git pull --force
13:05:26 <gammafunk> hrm, maybe not
13:05:41 <gammafunk> oh, yes
13:05:42 <floraline> i tried git fetch && git reset --hard
13:05:46 <gammafunk> git pull --force
13:06:07 <floraline> ok, i'll try that one next time thanks. i ended up just deleting the branch and checking it out again
13:06:20 <gammafunk> floraline: well, to be clear, after that reset what did you do?
13:06:37 <gammafunk> not sure if you realize this, but git fetch only fetches refs from the remote repo
13:06:47 <gammafunk> it does modify your current branch with a merge
13:06:53 <gammafunk> hence the git reset doesn't make much sense here
13:06:58 <floraline> i tried git pull and it tried to merge
13:07:00 <gammafunk> git fetch has not modified your branch in the first place
13:07:23 <gammafunk> yes, but it sounds like you don't quite understand what git fetch is doing
13:07:31 <gammafunk> git fetch is merely retrieving info about refs from the remote
13:07:36 <gammafunk> it does not modify your local repo
13:07:51 <gammafunk> what git pull does is basically `git fetch && git merge`
13:08:12 <gammafunk> so it sounds like you had a problem because you expected fetch to updating the branch in your repo
13:08:16 <gammafunk> but that's not what git fetch does
13:08:35 <gammafunk> that's what git merge would do (or git pull, which calls git merge after the fetch)
13:08:44 <gammafunk> hence you should have tried something like
13:09:02 <gammafunk> git fetch && git reset --hard origin/<branch>
13:09:15 <gammafunk> fetch to get the current state of all refs in origin
13:09:27 <gammafunk> git reset to set the head of your branch to the ref of origin/branch
13:09:34 <floraline> that's exactly what i ran
13:09:42 <floraline> except not origin it was the remote with the experimental
13:09:52 <gammafunk> oh, you omitted that in your command
13:10:26 <gammafunk> if you had done that, it should have modified your branch to point to the updated one
13:10:34 <floraline> i ran this: git reset new-nemelex --hard
13:10:48 <floraline> and it said HEAD is now at some old commit which does not exist anymore in the remote branch
13:10:54 <gammafunk> yeah, does the order of that matter?
13:11:02 <gammafunk> ah, you just said new-nemelex
13:11:04 <gammafunk> that's your problem
13:11:12 <gammafunk> that's going to refer to your local branch probably?
13:11:21 <floraline> yes i guess so
13:11:25 <floraline> it's tracked though
13:11:30 <gammafunk> I think git reset --hard origin/new-nemelex would have been what you want
13:11:53 <gammafunk> yeah but "new-nemelex" is going to refer to the branch in your repo by default, which points to the old, current ref
13:12:04 <gammafunk> at least that's my guess
13:12:09 <floraline> oh i see
13:12:39 <floraline> so it should have been git reset --hard origin/rnrnemelex
13:12:39 <floraline> maybe
13:12:45 <gammafunk> I believe that would work after the fetch, yeah
13:12:51 <gammafunk> or git pull --force
13:13:58 <gammafunk> maybe pull is not actually what you want here
13:14:19 <floraline> i don't want to do any merge, there are no local changes that need to be kept
13:14:24 <gammafunk> right
13:14:54 <gammafunk> I'm not sure how a force pull would behave after a rebase, so I guess modifying your reset command is the way to go
13:15:03 <gammafunk> if there's a better way I'd be curious to hear it
13:18:14 <floraline> well solving it like a neanderthal by deleting and recreating the branch worked great
13:19:11 <floraline> i would like to change my build script to deal with force pushes gracefully in the future
13:19:31 <ebering> there's mroe work to be done to recover local changes after an upstream rebase but if you want to track it reset --hard origin/rnrnemelex is the correct solution
13:19:40 <ebering> it's what alexjurkiewicz has set up on cpo I believe
13:19:53 <ebering> (sorry I rebased without giving you the heads up, I thought you'd set it up the same way)
13:20:24 <floraline> ok, it sounds like my reset was just a little off. i'll make sure to try it that way next time
13:20:45 <floraline> i'm just using a mostly out of the box dgl config which does not seem to account for conflicts
13:21:59 <floraline> it's good that i found this out now anyway
13:27:44 <Kelbell> Experimental (new-nemelex) branch on crawl.kelbi.org updated to: 0.23-a0-583-g002a5eb884
13:29:09 <floraline> ebering: i'm seeing a fatal error in new-nemelex, is it just me?
13:30:26 <floraline> ebering: /crawl-master/crawl-new-nemelex/data/dat/des/portals/lab.des:69: bad spec:
13:30:30 <floraline> 'dngn_portal_labyrinth' in 'dngn_portal_labyrinth'
13:34:14 <ebering> floraline: yes, I can't replicate locally
13:35:03 <ebering> floraline: the reset --hard didn't pick up the rm lab.des in the history
13:39:30 <floraline> that file was removed from the repo but dgl install script did not remove it from the install directory
13:39:44 <ebering> ahh
13:41:06 <|amethyst> ah
13:41:27 <|amethyst> that isn't a problem for trunk, because each revision gets a separate install dat directory
13:41:48 <|amethyst> but since experimental branches use the stable scripts, that's not handled properly
13:42:22 <floraline> i see
13:42:22 <|amethyst> (in stable, such things should not happen, because you really shouldn't remove/change enums in a stable branch)
13:42:29 <floraline> right
13:42:38 <floraline> well i just went in and removed the file. that will probably screw up anyone's ongoing game
13:43:06 <|amethyst> hm, probably not?
13:43:21 <|amethyst> since if they're currently playing, the stuff is already loaded into memory
13:43:42 <floraline> oh ok. that works out great then
13:43:51 <|amethyst> and if not, their save is force-transferred to the new version (since there isn't an old version available)
13:44:17 <|amethyst> wouldn't even call it a transfer exactly
13:44:18 <floraline> right, that's what i was gonna ask. their old save is just loaded up like a new save, right?
13:45:03 <ebering> yes
13:45:14 <ebering> I didn't make an attempt at save compat over the rebase
13:45:17 <ebering> it should be ok but
13:45:30 <ebering> if an experimental game gets rendered unplayable well it's experimental
13:45:37 <ebering> (there is save compat relative to trunk)
13:45:50 <floraline> yep people should understand that about experimental branches so hopefully no one would be too upset at losing a save
13:47:27 -!- amalloy_ is now known as amalloy
14:49:30 <ebering> floraline: dispersal traps added a new tile, I'm guessing the dgl stable installer doesn't re-generate the tile sheets
14:50:57 <|amethyst> IIRC it does, but users have to force-reload because the browser caches them
14:51:25 <|amethyst> trunk versions avoid this by including a hash of the git revision in the URL
14:54:42 <|amethyst> (it's possible that's been fixed; and even possible, but less likely, that I fixed it myself but forgot about it)
15:21:31 <Kelbell> Stable (0.18) branch on crawl.kelbi.org updated to: 0.18.1-50-g88ac8fda59
15:23:48 <ebering> minmay: re your clua question
15:24:38 <ebering> I'm not sure what you want to do
15:25:17 <ebering> but the targeter checks in with lua hooks ch_target_monster(x, y) and friends documented here http://doc.dcss.io/modules/Hooks.html
15:34:38 <gammafunk> woah
15:34:58 <gammafunk> stable 0.18 updated on cko
15:35:23 <gammafunk> maybe floraline is adding some older versions
15:50:45 <Cheibriados> 03ebering02 07https://github.com/crawl/crawl/pull/916 * 0.23-a0-584-g767f53f7: fixup! Remove decks as items 10(14 minutes ago, 1 file, 10+ 0-) 13https://github.com/crawl/crawl/commit/767f53f78d81
15:50:45 <Cheibriados> 03ebering02 07https://github.com/crawl/crawl/pull/916 * 0.23-a0-585-g79503af: fixup! New Nemelex Stack five 10(5 minutes ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/79503afcdb40
17:18:17 <Kelbell> Experimental (new-nemelex) branch on crawl.kelbi.org updated to: 0.23-a0-585-g79503afcdb
17:32:30 <floraline> ebering: you're saying that could be an issue or it's a problem somewhere right now?
17:52:22 <ebering> floraline: I was saying thaat I thought it could be an issue and was happening right now
17:52:33 <ebering> but neil pointed out that it shouldn't be
17:52:43 <ebering> and the person who was experiencing it found the force-reload fixed it
17:52:49 <floraline> oh i see
20:30:14 -!- amalloy is now known as amalloy_
21:26:44 -!- neunon_ is now known as neunon
22:28:09 -!- ProzacElf_ is now known as ProzacElf
22:48:43 -!- isha is now known as werekitten