| | <<<Back 1 day (to 2015/08/20) | 20150821 |
| fredross-perry | henrys: robin_watts: new android version at http://ghostscript.com/~fred/gsproof-dev.apk this one puts color swatches in the separations menu. | 00:46.46 |
| chrisl | kens: ping | 07:40.46 |
| kens | pong chrisl | 07:40.53 |
| chrisl | Bug 696161 - I'm not sure falling back to using "pis" is the right thing to do..... I think we should just throw an error] | 07:41.35 |
| | I'm not sure that pis and pgs are sure to be from the same parent structure | 07:42.21 |
| kens | I'm happy with that too. The only reason I suggest thsi is that the pis is often a pgs in disguise (and we can tell) and the pis and pgs are the same for a show state, and it will work for the case of pdfwrite. | 07:42.27 |
| chrisl | So, it is guaranteed that pis == pgs? | 07:43.13 |
| kens | We can no longer actually get here by the route Ray discovered anyway, since I now throw a fatal error if you tru to set Grphics or TextAlphaBits with teh vector devices. | 07:43.18 |
| | chrisl for pdfwrite it pretty much is, I *suspect* it is for other cases too but I can't be certain. | 07:43.48 |
| | I *thnk* that only the vector devices can end up here with anythign other than a show_state anyway. | 07:44.35 |
| chrisl | I guess I misunderstood those entries..... I thought pgs was the graphics state *before* rendering the glyph, and pis was the imager state *during* rendering of the glyphs | 07:45.02 |
| kens | I have no real idea. From the pdfwrite persepctive the only graphics state it has is the gstate, not the imager state | 07:45.40 |
| | Naturally that's the one before rendering the glyph | 07:46.06 |
| chrisl | Right, so it sets the pis pointer to the same address as pgs, then? | 07:46.32 |
| | Er, if it had a pgs pointer, that is..... | 07:46.58 |
| kens | pdfwrite doesn't set a show enumerator, its sets a text enumerator. The text enumerator doesn't have a pgs, just a pis | 07:47.07 |
| Robin_Watts | AIUI, a pis is a subset of a pgs (or the other way around) | 07:47.17 |
| kens | yeah what you just saqid :) | 07:47.17 |
| | Robin_Watts : a pis is smaller than a pgs | 07:47.32 |
| Robin_Watts | kens: That's what I said :) | 07:47.45 |
| kens | I'm not certain its techncally a subset, I haven't checked | 07:47.48 |
| | There are fields in a pgs that aren't in a pis, I'm not certain all the fields in a pis are in a pgs | 07:48.13 |
| chrisl | This seems like a good time to say: why-oh-why-oh-why do we have a text enumerator *and* and show enumerator....... same question for graphics state and imager state :-( | 07:48.29 |
| kens | Beats me. One could say the same about a imager_state and a graphcis_state | 07:48.48 |
| Robin_Watts | I thought that there was a macro that defined the set of fields in a pis, and that was used for the prefix of the fields in a pgs, so it's a strict subset. | 07:49.00 |
| | The flag just says whether it's Ok to upcast or not. | 07:49.15 |
| kens | Robin_Watts : it could be, I wa sayign I haven't checked and am not certain | 07:49.15 |
| chrisl | Yeh, imager state is a strict subset of graphics state - the extra entries for graphics state "hang off the end" of the imager state | 07:49.39 |
| kens | I am certain you can't treat a pis as a pgs unless it says you can | 07:49.44 |
| chrisl | kens: in which case, I'm okay with that patch | 07:50.01 |
| kens | chrisl you want me to commit it ? Its your area...... | 07:50.28 |
| | I may already have discarded the code locally (oops) | 07:50.52 |
| | I'm perfectly happy with just throwing an error, crashing is bad though | 07:51.23 |
| chrisl | Oh, I was assuming you'd have it stashed somewhere - I can do it, if you don't | 07:51.26 |
| kens | I forgot to stash it | 07:51.36 |
| chrisl | OKay, I'll grab it from the bug, and commit it | 07:51.50 |
| kens | I was workign on 3 things at once and only stashed one | 07:51.50 |
| | Thanks chrisl | 07:52.34 |
| chrisl | kens: on another note: the PCL params thing..... | 07:53.03 |
| kens | You have a bright idea ? | 07:53.11 |
| | That is why I cc'ed tech :-) | 07:53.23 |
| chrisl | Well, first a question: do you know why the params are sent to the device before it's opened? | 07:53.40 |
| kens | Not really, thats the way the PCL interpreter works. In fairness that happens in PostScript too | 07:54.02 |
| | I thnk its probably because the device is itself a parameter, so we set the device during parameter processing. I guess we could set and open the device at the same time. But of course, we need to have the OutputFile before we open the device, so..... | 07:55.31 |
| | Kind of a tnagled knot of interdependencies | 07:55.45 |
| chrisl | OKay, so my thought was that, since we already have a param list passed into pl_main_process_options() to be populated for use later on.... why not pass two param lists - pre-open-params, and post-open-params. Then your new stuff gets added to the "post-open-params" and applied after the device is opened. | 07:56.08 |
| | Then, obviously, the two param lists get passed into pl_main_universe_select(), as well | 07:56.42 |
| kens | That's essentially the same as what I was suggesting. I was going to have the parameter returned from parameter processing, like the inptu filename. Admittedly having a post-open list would be much more flexible. | 07:57.31 |
| chrisl | The param list is already returned from the parameter processing..... | 07:58.13 |
| kens | Yes, we'd need 2. I was agreeing that it would be more flexible tohave a second list returned rather than keep increasing the numerb of special cases returned. | 07:58.50 |
| chrisl | Alternatively, just send the same param list to the device twice - once before opening, and once after..... but that's rather icky | 07:59.36 |
| kens | I'm not certain we can do the pdfmarks as a siongle call to putdeviceparams though | 07:59.44 |
| | Its done as 4 separate sequential calls right now, I don't thnk they can be chained together | 08:00.05 |
| | Because the way pdfwrite works is to identify pdfmark operations by looking at the first key in the list | 08:00.31 |
| | If its pdfmark then it hands the whole list to pdfmark processing | 08:00.52 |
| | I'd have to somehow alter that so that unprocessed keys were handed back and reprocessed | 08:01.11 |
| chrisl | So, what happens if you do a get_params and then a put_params? The return from get_params will contain the entire pdfmark state..... | 08:01.25 |
| kens | No, because pdfmarks are 'special' they don;t get returned by get_params | 08:01.48 |
| chrisl | Ugh :-( | 08:01.56 |
| kens | Yep, its icky all right | 08:02.03 |
| | It *should* have been done as an operator. | 08:02.14 |
| Robin_Watts | kens: If you stash things, even if you later discard them, you can get them back for a month at least. | 08:04.37 |
| | git is good like that. | 08:04.54 |
| kens | Robin_Watts : I didn't stash them, that's the basic problem | 08:05.07 |
| chrisl | Well, those were my thoughts - clearly subtleties in there I wasn't aware of :-( | 08:05.08 |
| kens | chrisl yeah sorry, its hard to put everything in an email and have it make sense (without getting into tl;dr) | 08:05.35 |
| | I'm afraid I've been boxed in by prior decisions :-( | 08:05.59 |
| | The best I could do was cut it down to one 'special' case, but it just felt ugly whcih is why I ran it past Henry | 08:06.31 |
| | Robin_Watts : I shoudl have stashed the code of course, I was just a bit harried at the time | 08:07.08 |
| chrisl | Yeh, I just hadn't realised you had to split the pdfmark calls into four param lists | 08:07.49 |
| Robin_Watts | kens: No worries. I understand completely. | 08:08.06 |
| kens | Nor did I, initially. I had hoped I could do it in one pass, but its not possible. You have to define an object, then later use that object in another pdfmark call. | 08:08.25 |
| | Robin_Watts : at least I remembered to paste the code into the bug report :-) | 08:08.52 |
| | BTW how is your kitchen ? | 08:09.15 |
| | OK so back to transparency and ExtGStates :-( I think I need a coffee now....... | 08:10.41 |
| chrisl | kens: Although I slightly take issue with your wording of that bug report - "invalid assumption" seems unfair when the function (and two of it's parent functions) really do have show enum parameters!! | 08:11.04 |
| kens | Yeah but something must have cast it at some point | 08:20.10 |
| | I'm not sure its ever safge to assume that an enumerator is a show enumerator, and there are other places in the code where we explcitly use that ugly hack to check | 08:20.54 |
| | As you rightly say, the text/show enumerator and imager/graphcs state pairs are a nightmare and I cna't understand why anyone did that. | 08:21.57 |
| | I'd also say that the ugly hack shows ths has been a problem before, and instead of fixing it by either doing away with the dichotomy, or at the very least adding a flag to the two enumerators so you could reliably tell, the ugly hack was a very bad thng to do | 08:24.08 |
| kens | is very tempted to add such a flag right now...... | 08:25.03 |
| chrisl | I'd rather merge structures together, and remove the pointless separation.... | 08:27.30 |
| kens | Yeah but that would be harder, though admittedly not much harder. | 08:27.50 |
| Robin_Watts | kens: Kitchen is all out. | 08:29.26 |
| | Ceiling down. | 08:29.39 |
| kens | Lots of mess :-( | 08:29.45 |
| Robin_Watts | Electric boards moved to new position. | 08:29.46 |
| | New electrics all cabled. | 08:30.03 |
| | Plasterers are redoing ceiling now. | 08:30.13 |
| kens | (EPS file used setrgbcolor) == flush | 08:30.23 |
| | system_setrgbcolor | 08:30.23 |
| | }bind def/system_setrgbcolor /setrgbcolor load def | 08:30.23 |
| Robin_Watts | monday decoration, tuesday/wed floor. | 08:30.29 |
| | Then the kitchen itself can start to be done. | 08:30.41 |
| kens | Well it all sounds like good progress | 08:31.49 |
| Robin_Watts | kens: Yeah, just chaos here. | 08:37.17 |
| kens | Its a job we'll probably have to embark on in a year or two :-( | 08:37.42 |
| | Anyone got Bugzilla admin credentials ? | 10:45.07 |
| Robin_Watts | henrys, and marcos I think are the only ones with full creds. | 10:46.47 |
| kens | I'll send them an email then, thanks | 10:47.00 |
| Robin_Watts | I have 'Users' ability, but that's all. | 10:47.12 |
| kens | Just hope this idiot doens't polute hte database too much in the meantime | 10:47.18 |
| loic | Hello | 16:21.45 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 16:21.45 |
| loic | Do you think it is possible to add an svg object into a onepage pdf with gs? | 16:22.17 |
| Robin_Watts | loic: no. | 16:28.08 |
| | Not without hackery, certainly. | 16:28.20 |
| | mvrhel_laptop: So, fred has sent me a file (Bug690206.pdf). | 16:32.52 |
| | It has at least 14 colorants in it. | 16:33.07 |
| | The name for the 12th one comes out in the .gprf file as: "PANTONE Hexachrome Green CXXXXXX" | 16:33.52 |
| | where 'X' is byte 0xcd | 16:33.59 |
| | The 13th is called "Copy Limit" | 16:34.14 |
| | and the 14th is called "Die" | 16:34.23 |
| | oh, wait, no. the 14th is called "Die<02><70><e9><ef><01>" | 16:35.29 |
| | The GProof device is specced to use utf-8, but I didn't quite get around to that :) | 16:35.50 |
| fredross-perry | ;-) | 16:39.49 |
| Robin_Watts | The 0xCd's look like buffer overrun to me. | 16:41.26 |
| | So I'll start by digging in gs. | 16:41.43 |
| mvrhel_laptop | yes | 16:43.59 |
| | I should have the separation controls working today in gsview I hope | 16:44.35 |
| | I should actually just get the default icc work flow working to get that tested | 16:45.16 |
| | actually I will do that | 16:45.20 |
| | since we really should be doing the default icc flow in the android device at least | 16:45.53 |
| Robin_Watts | mvrhel_laptop: Yeah, that sounds important for the demo. | 16:46.08 |
| mvrhel_laptop | so once I check this out there may be one minor change to the gs call in mupdf | 16:46.18 |
| | the plan is for me to be on vacation next week so I would like to get his as wrapped up as I can | 16:46.51 |
| Robin_Watts | Sure. If there is anything I can do to help, please say. I'll be working at least part of tomorrow. | 16:47.24 |
| mvrhel_laptop | ok thanks. I will bring my laptop with me. we are just going to be at the oregon coast. | 16:48.33 |
| Robin_Watts | marcos has just been there. | 16:50.26 |
| mvrhel_laptop | I saw that. I think this https://www.youtube.com/watch?v=iwoaTXDeQH0 is going to be the highlight of it | 16:51.01 |
| Robin_Watts | Nice. Wear goggles. | 16:52.20 |
| | Is it telling that I had to try really hard not to type "googles" ? | 16:52.31 |
| mvrhel_laptop | yes. good point | 16:52.32 |
| | :) | 16:52.40 |
| fredross-perry | my guess is overrun, and that there are actually only 12 separations. | 16:53.26 |
| Robin_Watts | fredross-perry: Die and Copy Limit are both listed in the PDF file. | 16:54.07 |
| fredross-perry | Another question. I assume that in a separation printing process, all the listed colors are printed separately, in a particular order. WHen we render for display, are we mixing the colors in such a way as to get a close approximation of what it looks like on paper? | 16:56.17 |
| Robin_Watts | fredross-perry: The point of a color correct rendering scheme is that we get a very accurate match. | 16:57.55 |
| mvrhel_laptop | fredross-perry: you don't want to ask questions like that | 16:58.04 |
| Robin_Watts | gs uses proper color management to do the best it can using color profiles for the output devices. | 16:58.29 |
| | BUT it's a massively complex area that no one except mvrhel_laptop understands. | 16:58.56 |
| mvrhel_laptop | well I would have to say that if you have an icc profile for the actual printer with all those inks, then you will get reasonable results | 16:59.28 |
| Robin_Watts | This is why we are using gs to render the bitmaps and just displaying those within mupdf. | 16:59.29 |
| fredross-perry | I see | 16:59.39 |
| mvrhel_laptop | if you don't have an icc profile, there can be mixing hints etc in the pdf file that tell us how the inks interact as well as their opacity. we currently don't make use of that information but we may want to down the road | 17:00.27 |
| | also there are issues with overprinting that I don't think mupdf handles does it Robin_Watts? | 17:02.17 |
| Robin_Watts | mvrhel_laptop: yeah, and we don't get some transparency stuff right. | 17:02.41 |
| | (though IIRC there is at least one case still broken in gs) | 17:02.53 |
| | and MuPDF doesn't follow the exact pixel filling rules that gs does. | 17:03.15 |
| mvrhel_laptop | I think both mupdf and gs do the transparency stuff ok now. I don't know though if mupdf handles overprinting correctly though | 17:03.55 |
| Robin_Watts | Ok. I have a fix for the overrun. | 17:04.37 |
| mvrhel_laptop | with 14 inks, the use of an icc profile really is not that practical. of course if someone is really overlaying 14 inks they are likely going to have a mess | 17:04.56 |
| | thanks Robin_Watts | 17:05.13 |
| fredross-perry | send me a .so file please | 17:05.16 |
| mvrhel_laptop | I see that Graph Expo in 2016 is in Orlando not Chicago. I wonder if we will have our staff meeting there next year | 17:06.27 |
| Robin_Watts | mvrhel_laptop: Want to review this: http://git.ghostscript.com/?p=user/robin/ghostpdl.git;a=commitdiff;h=849891b1577e3caab4c73f0bfa5c27a7308e1ffc | 17:07.12 |
| mvrhel_laptop | oh gosh thanks Robin_Watts | 17:10.42 |
| | looks good | 17:10.45 |
| Robin_Watts | mvrhel_laptop: No worries. Thanks. | 17:11.27 |
| | Ok, that's pushed. | 17:11.32 |
| | Will build a new so for fred. | 17:11.42 |
| | oh, damn. I was going to check the ABGR thing. | 17:22.46 |
| | Aha. | 17:48.45 |
| | fredross-perry: I've figured out the color thing. | 17:48.57 |
| | We specify the colors as being RGBA. | 17:49.06 |
| | i.e. first byte R, second byte G, third byte B, fourth byte A. | 17:49.28 |
| fredross-perry | yes, I saw that. Itâs OK to leave it that way as long as we know. | 17:49.59 |
| Robin_Watts | When they get loaded in little endian stylee, we get R | (G<<8) | (B << 16) | (A<<24) | 17:50.08 |
| | Android on the other hand, uses BGRA | 17:50.30 |
| | (or ARGB, packed in big endian style) | 17:50.57 |
| fredross-perry | maybe the Separation structure could have them broken out? | 17:50.59 |
| Robin_Watts | So that's why you have to permute. | 17:51.14 |
| fredross-perry | then the client can just assemble them hoever it wants | 17:51.16 |
| | * however * | 17:51.24 |
| Robin_Watts | I *could* split them out into ints in a java structure, but that's way more work :) | 17:51.44 |
| | There is an argument that says that the JNI functions should be returning the colors in android stylee. | 17:52.18 |
| fredross-perry | or do some sort of #if ENDIAN-BLAH thing in mupdf.c | 17:52.32 |
| Robin_Watts | fredross-perry: I think the code in mupdf.c is endian safe. | 17:52.49 |
| fredross-perry | ok | 17:53.00 |
| Robin_Watts | I'll prepare a commit that returns the values as android standard (BGRA) rather than RGBA. | 17:53.33 |
| | cos that seems neatest. | 17:53.42 |
| | Thanks for spotting that. | 17:53.51 |
| | fredross-perry: It would really help in sharing code, if you could commit stuff to your private repo rather than having android.zip's. | 17:55.29 |
| fredross-perry | yes I am ging to do that today. | 17:55.43 |
| Robin_Watts | fab. | 17:55.46 |
| | git is very good at letting you alter old commits, so you can massage them into shape before being cast in stone. | 17:56.17 |
| mvrhel_laptop | ok. the icc flow is giving garbage out, so I have some work to do there | 18:06.19 |
| | :( | 18:06.24 |
| | its so bad, it should not be too hard to figure out | 18:06.42 |
| Robin_Watts | Ok, so 2 commits on robin/master (mupdf). | 18:14.13 |
| | The first of those fixes the Android JNI functions for multipage files. | 18:14.26 |
| | I'm guessing fred already took that on? | 18:14.33 |
| | The second permutes the color bytes. | 18:14.42 |
| | If people will review those I'll push 'em. | 18:14.53 |
| | (if people have reviewed already, and I missed it, I apologise) | 18:15.05 |
| fredross-perry | Robin_Watts: compile errors in your latest commit: | 18:37.15 |
| | jni/../../../source/gprf/gprf-doc.c:13:18: fatal error: iapi.h: No such file or directory | 18:37.36 |
| | #include "iapi.h" | 18:37.36 |
| | ^ | 18:37.38 |
| | compilation terminated. | 18:37.38 |
| mvrhel_laptop | hmm I thought we had an ifdef for that | 18:38.04 |
| fredross-perry | also a warning about arg 4 here: name = fz_get_separation_on_page(ctx, glo->pages[i].page, sep, &rgba[0], &cmyk); | 18:40.14 |
| | you do have an ifdef, but itâs defined for __android__ | 18:42.12 |
| | resumably androidâs not using iapi, âcause itâs got libgs.so? | 18:54.23 |
| mvrhel_laptop | good lord no wonder the icc stuff is broken. | 18:59.50 |
| | I screwed that up | 19:00.11 |
| fredross-perry | Robin_Watts: checked in my android stuff at ~fred/repos/mupdf.git | 19:08.24 |
| | sorry no I didnât. git hell. | 19:19.57 |
| mvrhel_laptop | need to take a lunch break... | 19:51.41 |
| tor8 | Robin_Watts: don't forget we have a fz_device_bgr colorspace | 19:52.42 |
| | oh, wait, it's ARGB? oh, that's crappy | 19:53.03 |
| fredross-perry | OK, now thatâs better. ~fred/repos/mupdf.git. I re-did the update on a branch, and then merged it up to my master. The interesting changes are in 580fdde64334aa44a03f2fc24d110a1103730535 | 20:36.22 |
| sebras | fredross-perry: why are several of the commits (e.g. f65fd94) both on fred/master and on fred/proofing2 (here demoted a53d6ae)? | 20:41.57 |
| | fredross-perry: the commits appear to be identical. ;) | 20:42.05 |
| fredross-perry | ehhh⦠not sure. | 20:42.13 |
| sebras | fredross-perry: git mishap? :) | 20:42.39 |
| fredross-perry | I f-ed up the firt time around, dropped back and then made a branch. Ten merged the branch back to master. | 20:43.41 |
| sebras | fredross-perry: you appear to have a few of my changes on the proofing2 branch too, e.g. 00ae14b. this was recently merged to origin/master as 6070743 | 20:43.42 |
| fredross-perry | I admit that git seems more like magic to me than it should. What I wanted was just to adopt my branch as the new master. Can that be done? | 20:44.33 |
| sebras | fredross-perry: ah, ok. yeah it took me while to get used to git too. | 20:45.09 |
| fredross-perry | Can I do that though? Seems like if you reach a dead end or screw something up on your master, you just want to tear it down and start again. | 20:46.02 |
| sebras | fredross-perry: if I have a local branch on my computer that I _know_ is superior to the one on the server in every way (i.e. it has exactly all commits that I want and nothing superfluous) I usually use git push -f sebras newmaster:master to say that I want to update the master branch of the sebras remote to point to the same commit as my local newmaster branch. | 20:46.51 |
| | fredross-perry: git push normally prevents you from simply replacing the commit that your branch points to. | 20:47.34 |
| | fredross-perry: but with git push --force you are allowed to do that. | 20:47.46 |
| fredross-perry | yes, but that does not remove the bad history I suppose. | 20:48.40 |
| sebras | fredross-perry: though check that your branch newmaster actually has all the relevant commits because when you use push --force the server will effectively lose the commits from the branch. | 20:48.42 |
| | fredross-perry: it does lose any history that you want. you can basically move the fred/master branch to point to any commit you want. | 20:49.13 |
| | fredross-perry: this is why it is important that you know what you are doing when using it so that you don't lose history that you might want to keep. | 20:49.42 |
| fredross-perry | in my case I knew which history I did and didnât want. | 20:50.25 |
| | So, the tip of proofing2 is really what I want. So how do I get my master to point there? | 20:50.56 |
| sebras | fredross-perry: first run git remote -v | 20:52.05 |
| | fredross-perry: this lists all your remotes | 20:52.11 |
| fredross-perry | I have two, me and robin | 20:52.28 |
| sebras | fredross-perry: ok. | 20:52.55 |
| | fredross-perry: then do git push -f fred proofing2:master | 20:53.11 |
| fredross-perry | can I just git push -f origin proofing2:master | 20:53.12 |
| sebras | fredross-perry: yes. | 20:53.18 |
| fredross-perry | ahhh. trying that | 20:53.19 |
| sebras | fredross-perry: in my repository I have origin pointing to the golden repository over at git://git.ghostscript.com/mupdf.git, sebras pointing to git://git.ghostscript.com/user/sebras/mupdf.git and e.g. robin pointing to git://git.ghostscript.com/user/robin/mupdf.git | 20:54.01 |
| | fredross-perry: that way I can see where the golden repository is as well as any of you guys and what you are up to. | 20:54.17 |
| fredross-perry | thanks for your help. | 20:55.34 |
| sebras | fredross-perry: have you done the git push -f yet? | 20:55.52 |
| fredross-perry | I did, and it still looks a bit odd. But master and proofing2 look the same | 20:56.31 |
| sebras | fredross-perry: on your local machine proofing2 points to what commit? 3b613ee? | 20:56.59 |
| fredross-perry | yes it does. Iâd prefer really that it points to 580fdde | 20:57.46 |
| sebras | fredross-perry: right. | 20:58.03 |
| | fredross-perry: then you first checkout proofing2, like so: git checkout proofing2 | 20:58.14 |
| fredross-perry | ok | 20:58.31 |
| sebras | fredross-perry: then you ask git to have proofing2 point to that commit id by doing: git reset --hard 580fdde | 20:58.38 |
| fredross-perry | ok | 20:58.54 |
| sebras | fredross-perry: then you check using gitk or whatever that it looks alright | 20:58.56 |
| fredross-perry | yep | 20:59.10 |
| sebras | fredross-perry: then you update the server by doing: git push -f origin proofing2:master | 20:59.13 |
| fredross-perry | "denying non-fast-forward refs/heads/master (you should pull first)" | 20:59.41 |
| sebras | fredross-perry: hm... that's strange. I don't get that when I do the same thing. maybe your git is configured differently? | 21:00.25 |
| fredross-perry | I donât know | 21:00.40 |
| sebras | fredross-perry: oh, maybe you have denyNonFastForwards set to true in .git/config | 21:01.45 |
| fredross-perry | local, or server? | 21:01.55 |
| sebras | fredross-perry: on the server. | 21:02.12 |
| fredross-perry | better. sort of. | 21:05.11 |
| sebras | fredross-perry: ok..? | 21:05.36 |
| | fredross-perry: is anything missing? | 21:05.44 |
| | fredross-perry: if I diff your old master (since I have it locally) with your new one then there are no changes, so I guess you didn't lose anything..? | 21:07.48 |
| | fredross-perry: also I guess you unded up in this situation because you did git pull, right..? | 21:08.42 |
| | ended. | 21:08.47 |
| fredross-perry | I did pull. but... | 21:09.22 |
| | so, I think I am getting something⦠I seem to have a branch called âmasterâ, and a tag called âorigin/masterâ, that are not the same. | 21:10.49 |
| | If I were to do a frash clone right now, which do I get? | 21:11.07 |
| sebras | fredross-perry: you will get a branch master pointing to commit 580fdde. | 21:11.41 |
| | fredross-perry: where does master and origin/master point to respectively? | 21:12.00 |
| | fredross-perry: we can probably fix your repository, and in doing so you'll probably understand more about git and not end up in a pickle next time. :) | 21:12.29 |
| fredross-perry | master = 3b613ee, origin/master= 580fdde | 21:12.45 |
| sebras | fredross-perry: instead of taking the easy way out and re-cloning. | 21:12.50 |
| | fredross-perry: alright, then what as happened is that your local repository now knows that origin's master branch points to 580fdde, which is what we want. | 21:13.36 |
| | fredross-perry: now you need to update the master branch to point to 580fdde as well. | 21:13.48 |
| | fredross-perry: one way of doing that is to checkout master: git checkout master | 21:13.56 |
| | fredross-perry: then do the same git reset --hard 580fdde | 21:14.06 |
| fredross-perry | yes | 21:14.18 |
| sebras | fredross-perry: just becase you update the master branch on the server doesn't mean that you want to throw away the commits that your local master branch points to, so git doesn't do this automatically for you. | 21:14.54 |
| fredross-perry | right | 21:15.08 |
| sebras | fredross-perry: if you run git branch -vv you can see what branches on each remote is tracked by what branches. | 21:16.24 |
| | fredross-perry: in your case master ought to trach origin/master which will then be shown in brackets (and perhaps in blue) | 21:16.48 |
| fredross-perry | yes both | 21:17.03 |
| sebras | fredross-perry: ok, cool, so when you do git pull this is the remote branch where it will advance to. | 21:17.31 |
| | fredross-perry: generally I dislike git pull because I often end up in a pickle. | 21:18.00 |
| fredross-perry | but itâs pretty often the thing to, with ârebase, to get code from others | 21:18.36 |
| sebras | fredross-perry: I prefer to first doing a git fetch --all and then for the relevant branches checking them out and doing git pull --ff-only. | 21:18.53 |
| | fredross-perry: or I do git fetch --all and then do git rebase on my local branch on top of origin/master | 21:19.15 |
| fredross-perry | thanks for you help. Iâve got to run now. | 21:19.32 |
| sebras | where origin then refers to the golden repository over at git://git.ghostscript.com/mupdf.git | 21:19.38 |
| | fredross-perry: np. happy to help out! :) | 21:19.47 |
| fredross-perry | cheers | 21:19.51 |
| sebras | tor8: (for the logs) do you mind adding -ldl to GLFW_LIBS? | 21:47.06 |
| | tor8: also if I search for a word that is on the first page of a pdf, I see the search hits, but if I then press 'N' it fails. | 21:48.58 |
| | tor8: uncaught exception: cycle in page tree | 21:49.12 |
| | tor8: wrt to input methods I can report that while I can enter and see a-z I can enter but not see chinese characters. | 21:50.20 |
| | tor8: maybe the font rendering you were talking about is not hooked up yet. | 21:50.32 |
| | tor8: maybe a temporary message in the status line when a search fails to be found..? | 21:51.28 |
| Robin_Watts | We've really got to remove the email hook from fred's repos :) | 22:52.36 |
| | Forward 1 day (to 2015/08/22)>>> | |
IRC Logs