| | <<<Back 1 day (to 2015/01/13) | 20150114 |
| mvrhel_laptop | ray: did you get everything straight with git? | 00:21.48 |
| | fredross-perry: got your emails. thanks | 00:21.54 |
| fredross-perry | mvrhel_laptop: groovy | 00:22.14 |
| yaochunlin | Hi, I have a zebra GT-800 printer, when I use gs9.15 to print pdf to it with mswinpr2 device, the default pagesize is not the pagesize configed in printer. `currentdevice /PageSize gsgetdeviceprop ==` print [306.088684 842.009827] | 08:07.10 |
| | The page size I config in printer is A6 size [297 420], I use another tools get the devMode of the printer, the PaperSize = 256 PaperWidth =1050 PaperLength = 1480 which seems correct according to the msdn. | 08:10.30 |
| | PaperSize = 256 is user defined papersize, width and length is A6 size in 1/10 mm. I just can't figure out how ghostscript got [306.088684 842.009827]. | 08:12.28 |
| chrisl | Possibly the page dimensions of the PDF? | 08:14.03 |
| yaochunlin | So I test without PDF, now the command is simple as gswin32c.exe -sDEVICE=mswinpr2 -sOutputFile="%printer%ZDesigner GT800 (EPL)" | 08:15.35 |
| | In interactive mode with command `currentdevice /PageSize gsgetdeviceprop ==` | 08:16.10 |
| chrisl | yaochunlin: sorry, I don't know what to suggest - looking at the code, it does read the values from the driver.... did you set the default in the driver or on the printer? | 09:02.53 |
| kens | The mswinpr2 device only uses the printer's dfefault media, nothing else. Its not controllable from PostScript either | 09:03.45 |
| yaochunlin | I have set the default page size in the printer, If the mswinpr2 read the default paper size correctly it will work. I don't have a debug environment on windows for ghostscript. | 09:06.19 |
| kens | I don't have the printer you're using, but its the default media size, as defined in the printer properties that gets used. Or so was the case last time I tried it. You could try using gsprint instead (part of GSView) which uses a slightly different technique to get the media size. | 09:08.20 |
| yaochunlin | It not require a real printer to reproduce this problem. Just the zebra GT-800 driver to FILE port. | 09:08.21 |
| kens | And how should I look at hte output to see what media is being used ? | 09:08.41 |
| yaochunlin | The output is EPL2, first line is encoding like I8,A,001, follow two empty line, and a Q comman If a6 size is used it will be Q1183,024 | 09:11.36 |
| chrisl | yaochunlin: what's the resolution of the printer? | 09:11.56 |
| kens | I'm sorry but I'm in the middle of preparing a patch for a customer at the moment, and I don't have time to try this right now. | 09:12.15 |
| | Oh damn, 9.05 predates the creation of the 'devices' subdirecotry, no wonder I can't find my device :-( | 09:12.50 |
| chrisl | I thought 9.05 would be out of support by now..... | 09:13.49 |
| kens | 8th February :-(( | 09:13.59 |
| yaochunlin | The error output is Q2374,024, Specify -sPAPERSIZE=a6 will workaround the problem. GT-800's resolution is 203, | 09:15.33 |
| chrisl | Well, you'd really have to specify -sPAPERSIZE=a6 for it to work properly, anyway, so.... | 09:16.34 |
| kens | Yes indeed, and probably -dFitPage or something | 09:16.52 |
| | Probably also needs -dFIXEDMEDIA ? I'm not certain how hte mswinpr2 device does media matching | 09:17.32 |
| yaochunlin | Yes I have to read default page size from win32api and set the PAPERSIZE=<result> now. | 09:17.46 |
| chrisl | I'm just reading the comments in the code..... it says: "This driver uses the printer default size and resolution and ignores page size and resolution set using -gWIDTHxHEIGHT and -rXxY. You must still set the correct PageSize to get the correct clipping path." | 09:18.36 |
| kens | Well that seems reasonably clear. | 09:20.13 |
| | Ah. Well the code for this customer is not back portable to 9.05 as it uses spec_ops, which would *also* have to be back ported. Too much effort it seems to me, the customer needs to update. | 09:21.11 |
| chrisl | Didn't 9.05 do that kind of thing by looking at the device name? | 09:21.59 |
| kens | I believe it did, yes, and I don't fancy trying to rewrite the patch against an old version of the interpreter to use that approach | 09:22.25 |
| | They need to upgrade | 09:22.40 |
| chrisl | I guess Marcos only tried the pdfwrite end of things, then? | 09:23.53 |
| kens | I don't know, I got the impression he only tried the PCL patch and that puzzles me as it won't compile as it is (the pdfwrite code does, but it needs the PCL change too to work) | 09:24.34 |
| chrisl | Well, if he'd tried the pcl patch, I'd assume he'd hit the missing spec_op problem, too..... | 09:25.10 |
| kens | I'd have thought so yes. | 09:25.31 |
| | It won't compile for me because dev_param_req_t is undefined | 09:25.49 |
| | I'm trying to figure out if I cna work around that. | 09:26.00 |
| chrisl | Like I say, you have access to the device, so you could check the name.... | 09:26.32 |
| kens | I could, but its a change to the way the code works, I'm not happy about doing it that way, and besides, the customer should just upgrade and ahve done with it (especially since they claim to be using 9.05.02 !) | 09:27.17 |
| | I don't mind doing a reasonable patch, but rewriting the code for an earlier version of Ghostscript starts to feel like masochism. | 09:27.52 |
| | and of course, I cannot tets that, not at all | 09:28.00 |
| chrisl | You can test it on the cluster | 09:28.23 |
| kens | I'm certain there will be differences | 09:28.39 |
| chrisl | Yeh, but you checkout 9.05, clusterpush that, then apply your changes, and clusterpush that, and check the "differences from previous" report | 09:29.17 |
| kens | Damnit I cna't find a dev_param_req_t defined anywhere | 09:29.26 |
| chrisl | kens: base/gxdevsop.h | 09:29.59 |
| kens | In 9.05 ? | 09:30.07 |
| chrisl | Oh, no.... | 09:30.17 |
| kens | Exactly | 09:30.21 |
| | Its not defined in 9.05 | 09:30.42 |
| chrisl | Well, you only added it last year, so..... | 09:31.06 |
| kens | Like I said, I think there's a limit to what's reasonable. | 09:31.27 |
| | And this has crossed it. | 09:31.35 |
| chrisl | I would agree - we generally don't backport features, and a fix that relies on a new feature is rather tough luck..... | 09:32.28 |
| kens | Its only the usual nonsense of 'if we only apply a patch we don't have to retest it' anyway. So tough, they want the feature, they need to test it. | 09:37.24 |
| | Hmm, gdevxps.c won't compile for me, because Michael is defining variables at other than initial declaration. | 10:16.18 |
| | I thought that was supposed to be fixed last night | 10:16.30 |
| chrisl | Ray had the same problem | 10:17.43 |
| kens | Well I did a fresh update, and gdevxps.c is definitely incorrect. It won't compile as it is. | 10:18.08 |
| chrisl | Looking at the cluster report, it would seem it wasn't fixed... several: "warning: ISO C90 forbids mixed declarations and code" | 10:18.32 |
| kens | Yeah, that's the problem I'm seeing (MSVC doesn't say so exactly, but its the same thing) | 10:18.55 |
| | I cna fix it of course, but its kind of tedious. | 10:19.08 |
| chrisl | I wonder if we can make that a gcc error instead of a warning | 10:19.40 |
| kens | It would be handy, it would stop these slipping through | 10:19.59 |
| | Loads of 'different const qualifiers' warnings too | 10:20.54 |
| chrisl | And unused variables.... | 10:21.19 |
| kens | I don't get warnings for those, but it certainly seems like this code needs a good going-over | 10:21.39 |
| chrisl | And worryingly a "warning: control reaches end of non-void function" | 10:21.56 |
| kens | Really ? I don't think I get one of those.... | 10:22.11 |
| chrisl | I'm looking at the cluster report | 10:22.26 |
| kens | huh, gximdecode.c won't compile either | 10:22.34 |
| chrisl | "./devices/vector/gdevxps.c:789:1: warning: control reaches end of non-void function [-Wreturn-type]" | 10:22.35 |
| kens | its correct | 10:22.49 |
| | THe function has no return value on success | 10:22.59 |
| chrisl | gximdecode.c also has "warning: ISO C90 forbids mixed declarations and code" | 10:23.04 |
| kens | I'll fix that too | 10:23.05 |
| | Grrrrr | 10:23.14 |
| | THat's even more annoying, he's declaring const floats to variables given values during the body of the function. Bye bye const | 10:24.23 |
| | Looks like 2 of the variables aren't used either. Sloppy coding | 10:25.09 |
| | Oh no actually they are | 10:25.32 |
| | and he's assigning values to const pointers.... | 10:25.47 |
| | OK this now builds for me. | 10:25.56 |
| | OK I@m going to commit these changes unless you object ? I don't like having a broken build | 10:27.26 |
| chrisl | I don't have any objections | 10:27.48 |
| kens | All I've done is move the declartations ot the function top, and add a return 0 for the missing return value (success case) | 10:28.12 |
| | Bum, out of time. | 10:28.40 |
| | I'll sort it when I get back | 10:28.47 |
| henrys | is still irked by git bisect going down work branches. In any really young active project bisect would be useless. | 16:10.02 |
| kens | it doesn't go down branches, unless you import all the commits from a branch individually. Unless I misunderstnad your point | 16:10.55 |
| sebras | kens: what about if something is merged? | 16:11.12 |
| kens | No idea, we don't do merges (that's the rtule, we break it sometimes) | 16:11.36 |
| sebras | kens: I like that rule. | 16:11.46 |
| | kens: my employer hates it. we merge all the time. :-P | 16:12.04 |
| kens | I think that sounds like chaos :-D | 16:12.19 |
| Robin_Watts | http://stackoverflow.com/questions/20240526/how-to-git-bisect-only-on-one-branchs-commits | 16:12.22 |
| sebras | kens: no kidding! in the repo I work on the most there are 1100 branches. | 16:13.09 |
| kens | boggles | 16:13.20 |
| Robin_Watts | kens: If I'm following this correctly, henry would like the ability to merge development branches into master, leaving (potentially broken) commits on the branch. | 16:13.22 |
| henrys | Robin_Watts: yeah I saw that. and it's easy to write a script to do the bisect I just can't believe bisect doesn't have a simple flag. weird to me. | 16:13.25 |
| sebras | kens: luckily git logg is only ever shows me the top of the tree. | 16:13.27 |
| Robin_Watts | If git bisect was capable of only looking at 'first parents' then it would skip the broken stuff. | 16:13.49 |
| kens | Robin_Watts : but surely that means manual intervention in order to discard (or saquash) the broken commits | 16:14.06 |
| henrys | if you are not using branches git doesn't have a lot to offer. Branches is what git is all about. | 16:14.23 |
| sebras | Robin_Watts: you would have the same problem with git bisect if you have broken commits in the midde of your only branch... | 16:14.45 |
| kens | I seem to remember bisect getting upset about merges | 16:14.53 |
| Robin_Watts | kens: No, the convention would be that only the stuff that gets merged onto master gets tested/needs to work. | 16:15.01 |
| sebras | Robin_Watts: a git bisect skip that bisects to a different commit would be useful though. | 16:15.19 |
| kens | sebras we have broken commits on master, there was one committed last night | 16:15.20 |
| Robin_Watts | kens: Only because it currently tries to walk down both the branches that go into a merge. | 16:15.31 |
| chrisl | sebras: bisect already does that.... | 16:15.40 |
| kens | Robin_Watts : I'm not sure how that differs from just squashing it all up and committing to master | 16:15.46 |
| Robin_Watts | If it only walked the first parent (i.e. the branch you were merging to), then it'd be fine. | 16:15.49 |
| sebras | chrisl: does it? how? | 16:15.51 |
| Robin_Watts | kens: It keeps the development history. | 16:16.02 |
| henrys | sebras : the use case is I want to create a branch off the tree that breaks functionality for a while that is not uncommon in development. | 16:16.12 |
| kens | But we have that on the branch anyway | 16:16.13 |
| Robin_Watts | kens: Unless the branch is merged in, then the branch is lost. | 16:16.41 |
| chrisl | sebras: skip can be told what to skip | 16:16.55 |
| kens | But we don;t do merges, so... no problem ? | 16:16.57 |
| Robin_Watts | smacks head on desk. | 16:17.08 |
| chrisl | I really don't see the problem with the way things are..... | 16:17.38 |
| kens | Me neither | 16:17.44 |
| sebras | chrisl: so if git bisect skip exists, then why couldn't that be used? | 16:17.47 |
| kens | Admittedly I'ma simple minded Git user | 16:17.53 |
| sebras | chrisl: suboptimally of course, but still. | 16:17.54 |
| Robin_Watts | Currently we don't do merges, hence we have no problem with bisect. The downside of our current approach is that we lose development history due to branches never being merged in (just being squashed and committed). | 16:17.57 |
| kens | That's only true if we edelte the branch | 16:18.15 |
| sebras | Robin_Watts: or rebased..? | 16:18.19 |
| chrisl | sebras: it's just a pain..... especially when it turns out the thing you're trying to trace happened *in* a broken commit | 16:18.29 |
| henrys | kens: I wanted mvrhel_laptop's commit yesterday to be a merge of many commits so I could understand how he arrived at his final commit. Look at his commit you have no way of figuring out the thinking process that got him to the end and therefore can't do a good review. | 16:18.57 |
| Robin_Watts | henrys: He could have published a branch on his repo for you to review. | 16:19.22 |
| kens | SO use the branch history | 16:19.23 |
| chrisl | Robin_Watts, henrys: we are also supposed to keep non-trivial branches so the history doesn't get lost | 16:19.35 |
| | That's what we agreed when we hammered out the policy after switching to git | 16:20.05 |
| Robin_Watts | chrisl: I think more specifically we are *allowed* to keep non-trivial branches. | 16:20.09 |
| | It's a developer discretion thing. | 16:20.18 |
| chrisl | My recollection is that we are supposed to.... | 16:20.37 |
| Robin_Watts | but if you're going to do that it's good form to ensure that it mostly builds most of the time :) | 16:20.39 |
| henrys | chrisl: If we keep it is subject bo bisect and that kiind of change always breaks the tree and one commit. | 16:20.44 |
| | s/and/at | 16:20.54 |
| kens | If we keep the branch its not subject to bisect | 16:20.58 |
| sebras | chrisl: if what you traced happened in a broken commit you have no chance of bisecting to it. and if you follow robin's suggestion it you will only know that it happened on the development branch. | 16:21.04 |
| kens | If we're going to discuss this (again) I'd prefer to do it round a table and with something we can scribble on | 16:21.50 |
| chrisl | henrys: you can keep your branch in any state you want, only what goes on master *must* work for every commit | 16:22.06 |
| sebras | chrisl: what does work mean? compile? | 16:22.44 |
| henrys | kens, chrisl : thats not true if yoiu create a branch off master and merge it in bisect is going down the branch. | 16:22.52 |
| sebras | chrisl: I guess that would be sufficient for git bisect. | 16:23.01 |
| kens | We're back to merging again | 16:23.06 |
| henrys | see the stackoverflow url Robin_Watts gave | 16:23.06 |
| sebras | chrisl: if you run some test-script. | 16:23.08 |
| chrisl | henrys: we *don't* merge | 16:23.16 |
| sebras | kens: 1100 branches anyone..? ;) | 16:23.26 |
| chrisl | sebras: build and run | 16:23.27 |
| rayjj | kens: did you figure out why we are getting bad gdevxps gximdecode.c from git ??? | 16:24.31 |
| rayjj | didn't see it in the logs | 16:24.42 |
| kens | Yeah because hte code is broken. | 16:24.43 |
| | I fixed some , Chris fixed some more | 16:24.51 |
| | Current code builds and runs for me | 16:24.59 |
| rayjj | are those fixes commited ? | 16:25.04 |
| kens | and fixes 147 regression errors | 16:25.06 |
| | Yes, see the gx-cvs mails | 16:25.18 |
| rayjj | I also "fixed" my local copy, but just enough to let me build | 16:25.35 |
| kens | Chris also changed the Linux build so the warnings are noww errors, just like VS | 16:25.40 |
| | There are still *many* warnings in the code and someone (Michael ?) really ought to look at those. I only fixed it enough to build and run | 16:26.20 |
| henrys | chrisl: I would like to have a merge policy for complicated changes that should be multiple commits. Some of those commits might break the tree, but those commit should not be found by bisect because breaking the tree was intended. Do you see what I'm saying? | 16:27.47 |
| chrisl | henrys: yes, but we can't do that, so..... | 16:28.22 |
| kens | So you want a magic merge, or magic bisect, that doesn't find broken commits ? I don't see how that can work unless you guarantee not to commit broken commits | 16:28.32 |
| rayjj | kens: chrisl: Can one (or both) of you comment on the Orientation "fix" in my repo. Particularly the log message (the code change is trivial): http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commitdiff;h=bc7170f48100da7718707e6623c4ee640c188029 | 16:28.38 |
| Robin_Watts | henrys: And the problem with that is that such a thing would break bisect. | 16:28.39 |
| kens | rayjj this part of the log is not true: | 16:29.25 |
| | "Orientation is no longer ignored (except for pdfwrite where it must be to support pdfmark location)" | 16:29.25 |
| | You can enable pdfmarks for devices other than pdfwrite | 16:29.34 |
| Robin_Watts | There is a way the goals for this could be achieved using current git. | 16:29.50 |
| rayjj | kens: what other devices support pdfmarks ?? | 16:30.15 |
| kens | You might say "Orientation is no longer ignored, unless pdfmark operation is enabled (eg for the pdfwrite device)" | 16:30.16 |
| | rayjj at the moment, none, but that's not really the point. We have a control which can turn it on | 16:30.36 |
| Robin_Watts | I go off and do a whole bunch of development on 'foo-dev-branch'. | 16:30.37 |
| rayjj | kens: your wording is fine. I' just trying to understand about pdfmark | 16:30.52 |
| Robin_Watts | When I've finished, I push that branch to robin/foo-dev-branch. | 16:30.54 |
| henrys | kens: l don't know what you mean by magic. Some work on a branch is rough work and shouldn't be tested, anything on master to include the mergepoint of the branch is tested. Why is that magic ? | 16:30.55 |
| Robin_Watts | henrys: because currently you cannot tell git not to bisect through it. | 16:31.18 |
| kens | Because of the way merges work, as I understand it (which is nto well) | 16:31.28 |
| | But Robin seems to agree with me..... | 16:31.44 |
| Robin_Watts | kens: The problem is not with merges, it's with bisect. | 16:31.45 |
| | All a merge commit is is a commit with multiple parents. | 16:32.01 |
| henrys | Robin_Watts: right and it just is very surprising to me that bisect is useful at all in a new active project. It probably isn't. | 16:32.18 |
| kens | OK but essentially that means every vommit in the branch is treated as if it were in the trunk | 16:32.20 |
| rayjj | can't we clean up our branch (rebase interactive) to squash some of the fixes encountered during development (that caused things to break) so that the steps are retained, just not all of the "oops" steps ? | 16:32.30 |
| kens | rayjj I have 41 commits, I have no idea which (if any) work on which interpreters and whic compilers and OS's | 16:32.53 |
| Robin_Watts | bisect is an equal opportunity operator. It doesn't 'prefer' any one parent over another. | 16:32.57 |
| kens | I don't plan to walk through them one by one to find out and then manually squash them | 16:33.12 |
| Robin_Watts | What henry is asking for is that bisect should have a mode whereby it only ever looks at the first parent of a merge. | 16:33.20 |
| rayjj | likes ken's typo "vommit" -- sometimes it's more like that | 16:33.42 |
| kens | Robin_Watts : yes, we're saying the ame thing in different ways. You have a better model in your head for how Git works than me, but it works out to mena the same thing | 16:33.50 |
| Robin_Watts | As I say, there is a way to do this with current git, but it'll take me 2 minutes to explain, and I'm not going to try if people are going to jump in half way through to drag the conversation off. | 16:34.05 |
| kens | would still rather do this in person | 16:34.20 |
| | rayjj other than nitpicking the device, your log message looks fine to me | 16:34.54 |
| rayjj | kens: that makes sense. I tend to run regressions as I do development, and fix any oops-es with commit --amend as I go, so each step on the branch is "atomic" | 16:34.59 |
| henrys | Robin_Watts: can we write our own bisect, put it in the code so I folks can break merges? | 16:35.18 |
| | s/I// | 16:35.25 |
| | not merges I mean branches | 16:35.34 |
| Robin_Watts | rayjj: And that's an admirable way to work. But for some refactors it's not possible. | 16:35.36 |
| rayjj | kens: but I recognize that in you case, the regression testing probably didn't help much | 16:35.42 |
| kens | I ccouldn't regression test much of my code when it was in intermediate stages | 16:36.00 |
| Robin_Watts | henrys: git is extensible. We could probably look at the git-bisect script and tweak it, yes. | 16:36.21 |
| | But we may not need to. There is a way to do what we all want with just a convention, I believe. | 16:36.47 |
| rayjj | Robin_Watts: yeah, I have to most trouble with disciplining myself to do the refactor first, then make changes (and I usually don't since the point of the refactor is to add something) | 16:36.49 |
| henrys | I'd argue that no substantial change can be made without breaking the tree for at least some commits. If you insist that commits are small and reviewable. | 16:37.24 |
| chrisl | I suspect we've wasted more time discussing this than we'd actually save by working differently........ | 16:37.39 |
| kens | Or just waitring for Robin's suggestion | 16:37.51 |
| henrys | I wanted to make sure it was okay with everybody that we have broken branches. If your project is late I'll write Miles a note excusing you ;-) | 16:39.21 |
| chrisl | Ugh, git does seem to have a publicly visible bug/feature request database..... | 16:41.06 |
| henrys | Robin_Watts: I can think of an easy way to write our own bisect, but you think it would be better to customize their script? | 16:43.21 |
| Robin_Watts | I do a batch of development on foo-dev-branch. | 16:43.31 |
| | This may include build breakages. | 16:43.33 |
| | When I finish, I publish foo-dev-branch to my personal repo for review. | 16:43.35 |
| | The branch can then be tweaked until the reviewer is happy and cluster tests pass on the final commit. | 16:43.37 |
| | Then I squash the entire branch down to a single commit, and include in the commit message: "This is a squashed version of foo-dev-branch". | 16:43.38 |
| | I then push the squashed commit to golden, along with foo-dev-branch. | 16:43.40 |
| | Thus the history of the development is preserved, and master is never broken. | 16:43.41 |
| | Bisects just work. | 16:43.43 |
| | Effectively we are avoiding having git-readable merges, and just having human-readable ones. | 16:43.44 |
| kens | That sounds pretty much like how I thought we were supposed to be doing things now | 16:44.16 |
| | (other than the 'master is never broken' part ;-) | 16:44.38 |
| henrys | Robin_Watts: and the problem is a year from now it's useless... | 16:44.44 |
| kens | Why ? | 16:45.05 |
| henrys | because he squashed the individual commits | 16:45.24 |
| Robin_Watts | kens: the key difference between what we are doing now and what I have suggested is that we don't publish the development branches to golden (or namecheck them in the squashed commit) | 16:45.30 |
| | henrys: NO. | 16:45.33 |
| kens | But the individual commits are still on the branch | 16:45.35 |
| rayjj | henrys: but the foo-dev branch is always there (un squashed) | 16:45.50 |
| Robin_Watts | The squashed commit is on the master, but the commit message for that says "and if you look at golden/foo-dev-branch, you can get the detailed history" | 16:46.20 |
| chrisl | Robin_Watts: I think your outline missed a step...... | 16:46.41 |
| Robin_Watts | Currently we never publish foo-dev-branch to golden, so the history is lost. | 16:46.47 |
| | chrisl: I don't think so...? | 16:47.27 |
| rayjj | Robin_Watts: what's the git command to push my branch to the origin ? | 16:47.29 |
| henrys | Robin_Watts: okay so bisect works because you didn't merge | 16:47.43 |
| Robin_Watts | rayjj: git push golden foo-dev-branch | 16:47.46 |
| | henrys: Yes. | 16:47.49 |
| chrisl | Robin_Watts: your outline has all the commits on foo-dev-branch being squashed | 16:47.51 |
| mvrhel_laptop | So a problem with the branch approach in what I did, is that I had a number of dead ends along the way that I think would be even more confusing henrys. I ended up writing a bit of code for example to squash all the images and icc proifiles in a single temp resource file that was later put into the zip archive. But after writing that realized I should just go ahead and create a temp file... | 16:47.58 |
| | ...for the image and when done push it in the archive. In the case of ICC profiles I go straight from mem to the archive (no temp file) | 16:48.00 |
| Robin_Watts | chrisl: Ah. I was unclear. | 16:48.12 |
| rayjj | Robin_Watts: I usually use: git push origin -- what is "golden" ? | 16:48.19 |
| kens | golden == origin/master ? | 16:48.30 |
| chrisl | Robin_Watts: so, I'd assume there was a "rebase foo-dev-branch onto master" in there somewhere | 16:48.38 |
| Robin_Watts | chrisl: No. give me a mo to clarify. | 16:48.54 |
| mvrhel_laptop | I suppose I could have managed it more carefully to make sure it was more reviewable, but the fact that 90% is in one file I don't feel it was too hard (especially with the commit message about what was done) to figure out what I was doing. | 16:48.57 |
| | Not to mention one can ask questions | 16:49.14 |
| henrys | mvrhel_laptop: this really isn't about your commit per se ... the point is we need a model where it is okay to break the tree. | 16:49.49 |
| rayjj | mvrhel_laptop: asking questions is ephemeral -- years later we have to rely on comments / log messages | 16:50.16 |
| Robin_Watts | rayjj: for me, origin = my personal repo. golden = the main repo on casper. | 16:50.27 |
| rayjj | Robin_Watts: I see. For me, "personal" is my personal repo and "origin" is the main repo on casper | 16:51.31 |
| Robin_Watts | OK, updated version: | 16:51.47 |
| | I do a batch of development on foo-dev-branch. | 16:51.50 |
| | This may include build breakages. | 16:51.52 |
| | When I finish, I publish foo-dev-branch to my personal repo for review. | 16:51.54 |
| | The branch can then be tweaked until the reviewer is happy and cluster tests pass on the final commit. | 16:51.56 |
| | Then I push the entire foo-dev-branch to golden (NOT on master, as a new branch). | 16:51.58 |
| | Then I squash the entire branch down to a single commit, and include in the commit message: "This is a squashed version of foo-dev-branch". | 16:51.59 |
| | I then push the squashed commit to golden. | 16:52.01 |
| henrys | Robin_Watts: could you copy paste what you wrote to a twiki entry for reference? | 16:52.02 |
| Robin_Watts | Thus the history of the development is preserved, and master is never broken. | 16:52.02 |
| | Bisects just work. | 16:52.04 |
| | Effectively we are avoiding having git-readable merges, and just having human-readable ones. | 16:52.05 |
| henrys | Robin_Watts: I would prefer merges and a sane bisect but this is a good compromise. | 16:52.35 |
| paulgardiner | Robin's suggestion seems good to me: it's identical to doing the merge but cutting the tie between branch and trunk at the top, so bisect cannot go down there | 16:52.43 |
| Robin_Watts | So golden/foo-dev-branch ends up having the entire history for later perusal. | 16:52.55 |
| | but the branch just has a single commit (as we would get now) with a pointer to where the full history can be obtained. | 16:53.36 |
| chrisl | Well, that's essentially how I thought we were supposed to work, so...... | 16:53.39 |
| kens | nods | 16:53.46 |
| Robin_Watts | chrisl: Currently we've never published the unsquashed branches to golden. | 16:54.03 |
| chrisl | But I'd have the branch with the entire history on golden | 16:54.04 |
| paulgardiner | The squashed commit is exactly the little link git would have used to joing branch and trunk were you to have performed the merge | 16:54.06 |
| Robin_Watts | paulgardiner: Yes. It's a merge commit with one parent removed. | 16:54.41 |
| chrisl | Robin_Watts: Right, so the only difference is that I rebase onto master, and then squash to a single commit on master | 16:54.59 |
| Robin_Watts | chrisl: no. | 16:55.28 |
| chrisl | Huh? | 16:55.36 |
| paulgardiner | Robin_Watts: precisely | 16:56.03 |
| chrisl | The branch, with history remains, and master gets only the one, squashed commit | 16:56.05 |
| Robin_Watts | chrisl: Yes. | 16:56.18 |
| henrys | chrisl, kens we want to see the individula commits that brought you to that final commit. If there is on rebased commit for the upcoming directory change it will not be understandable or reviewable. | 16:56.19 |
| kens | Master (or golden) also gets the branch | 16:56.23 |
| henrys | s/on/one | 16:56.30 |
| Robin_Watts | I agree with your summary, but not your description of how you got there :) | 16:56.38 |
| | kens: master is a branch, golden is a repo. | 16:56.55 |
| kens | Like I said poor terminology | 16:57.07 |
| Robin_Watts | I think you mean 'origin or golden also gets the branch'. and yes. | 16:57.10 |
| | I will write a twiki page and people can suggest clarifications etc to that. | 16:57.45 |
| kens | There's no rebase, you just push the branch over, then suqash adn commit the contents of the branch with a senseible log message | 16:57.50 |
| rayjj | IME, git commands are usually picky about precise terminology ;-) | 16:57.51 |
| chrisl | But I also think it's important this *only* be done for non-trivial cases - we don't want a branch explosion on golden..... | 16:58.41 |
| kens | rayjj mvrhel_laptop Miles is pestering me about dates so I'd like ot boo flights. Are we firm on dates for ski-ing ? | 16:58.46 |
| rayjj | Robin_Watts: can you include sample commands in your twiki ? | 16:58.48 |
| Robin_Watts | kens: You probably want to rebase the branch onto master to ensure that your branch is rooted at the same point that the squashed commit goes. | 16:59.09 |
| | rayjj: I will. | 16:59.14 |
| rayjj | chrisl: I agree. If my work on branch was only a single commit, no need to push the branch | 16:59.31 |
| | chrisl: but in that case I usually did commit --amend to my branch | 17:00.06 |
| chrisl | Whatever way we do it, we're relying on individual discretion | 17:01.55 |
| henrys | I'm probably being optimistic but I think this can really improve folks ability to grok the code. | 17:02.11 |
| kens | dounts it will help much with pdfwrite...... | 17:02.41 |
| chrisl | Or cause even more confusion.... | 17:02.41 |
| kens | The damage is already done :-( | 17:02.56 |
| kens | tries Ray and Michael again | 17:03.26 |
| | rayjj : mvrhel_laptop I need to book flights as Miles is pestering me about dfates. Are we firm about dates for ski-ing ? | 17:03.51 |
| | ... tumbleweeds.... | 17:04.33 |
| henrys | miles is going to ski with you kens ? nice. | 17:05.30 |
| kens | henrys, no Miles is hassling me for hotel dates at the airport | 17:05.44 |
| mvrhel_laptop | kens: yes | 17:06.18 |
| | sorry | 17:06.19 |
| | miles can't go but we are set to go | 17:06.32 |
| kens | Great, thanks Michael, I'll mail Miles and go ahead and book flights | 17:06.39 |
| mvrhel_laptop | so you and tor8 should arrive monday | 17:06.40 |
| kens | Yes, we'll land at about 15:20 Monday afternoon. | 17:06.56 |
| mvrhel_laptop | rayjj is working on finding us a place. I think he found something | 17:06.57 |
| | I have a van for us | 17:07.08 |
| kens | Sounds great :-) | 17:07.12 |
| henrys | mvrhel_laptop: so you are using a car. vail is probably the best choice without a car... | 17:07.15 |
| mvrhel_laptop | seats 15 if anyone else wants to go ;) | 17:07.16 |
| henrys | ? | 17:07.17 |
| | on nvm | 17:07.19 |
| | s/on/oh | 17:07.25 |
| kens | 15 ? O.O | 17:07.25 |
| mvrhel_laptop | it was cheaper than a minivan | 17:07.34 |
| kens | ROFL | 17:07.36 |
| | Well loads of luggage space, so I guess you are bringing your board ? | 17:07.51 |
| mvrhel_laptop | yes I have a brand new board. snow is so bad here, I have not used it yet. | 17:08.11 |
| kens | :-( | 17:08.18 |
| mvrhel_laptop | only my old board which is now my rock board.. | 17:08.22 |
| kens | We were lucky last week, had 90 cm on the top | 17:08.32 |
| mvrhel_laptop | nice | 17:08.37 |
| kens | Its half that again this week | 17:08.42 |
| | and dropping | 17:08.46 |
| | THe Alps are having a real warm spell | 17:08.56 |
| | So I'll catch up with Tor and go looking for a hotel at the airport for Monday night. In the meantime I'd better go talk to Stella who keeps shouting at me. Maybe the house is on fire or something. Night all | 17:10.06 |
| mvrhel_laptop | henrys: how is the snow there? | 17:11.44 |
| henrys | Robin_Watts: brilliant idea with git... never occurred to me to do that. | 17:11.55 |
| mvrhel_laptop | this is the worst season I have seen here | 17:11.56 |
| henrys | mvrhel_laptop: so far plenty of snow. | 17:12.19 |
| mvrhel_laptop | great | 17:12.22 |
| rayjj | mvrhel_laptop: sorry, I wasn't paying attention. | 17:15.31 |
| mvrhel_laptop | no problem. kens was just wanting to know if we were a-go on the skiing and I told him yes | 17:16.00 |
| rayjj | mvrhel_laptop: I have the info from the owner on the place we discussed. The two nights are ~$700 total, including cleaning fee and taxes (unless we trash the place and forfeit the $200 deposit) | 17:17.26 |
| mvrhel_laptop | sounds reasonable to me | 17:18.31 |
| | rayjj: looks like I can get a flight that arrives at 7:10pm or 8:56pm in denver. I may take the 7:10 since I have so many issues with united. It leaves one extra flight for them if the screw it up | 17:21.04 |
| rayjj | mvrhel_laptop: that sounds reasonable | 17:21.24 |
| | I didn't think about that w.r.t. my flight (American/Alaska) | 17:21.49 |
| | it's only $20 more for a slightly earlier fligh | 17:22.33 |
| | t | 17:22.37 |
| henrys | I don't know if it's gas prices or what but I got a round trip to chicago for $80 last week... I might start doing some travelling... | 17:24.33 |
| mvrhel_laptop | wow! | 17:29.30 |
| | I was wondering how long it would take for prices like that to start to come up | 17:29.49 |
| | with the fuel costs as some point the competition has to start | 17:30.08 |
| | rayjj: booked my flight. looks like the snowboard just counts as one checked bag (no extra). | 17:30.58 |
| rayjj | henrys: yeah, as I said, RT to Denver was $149 for the one that gets in at 12:41am and only $170 for earlier flights | 17:31.16 |
| | I haven't booked my flight yet. I might check SW as well, first | 17:32.00 |
| mvrhel_laptop | wow. I see a windsurfing board costs $150 each way now. years ago, I remember getting my board through for maybe $25 or so | 17:32.22 |
| | brb | 17:32.50 |
| rayjj | mvrhel_laptop: I wonder what skiis cost (they are pretty bulky, too). Not that I'm bringing mine | 17:33.03 |
| | I have to change locations (battery getting low). bbiab | 17:33.43 |
| | holy moly. My kids (sophomores) are getting flooded with messages from colleges around the world. I wonder what list they got on? | 17:37.23 |
| mvrhel_laptop | rayjj: skis count as just a regular bag also (on united) | 17:53.18 |
| | so if you get a free checked bag it is free | 17:53.29 |
| | rayjj: did you get your git straightened out? | 17:57.41 |
| rayjj | mvrhel_laptop: yeah, I updated with the fixes from ken and chris and all was well (still warnings about double->int loss of data and 'const' issues in those two files) but I'm OK to run | 18:06.37 |
| mvrhel_laptop | rayjj: yes I need to fix those. thanks for the reminder. | 18:06.57 |
| rayjj | mvrhel_laptop: my git was OK -- I just didn't realize that the code was still broken | 18:07.09 |
| mvrhel_laptop | I don't know why I received no warnings during the plain cluster push | 18:07.12 |
| | rayjj: I dont think it is broken | 18:07.21 |
| | just a few warnings | 18:07.25 |
| rayjj | mvrhel_laptop: I don't know how you got it to build on windows | 18:07.29 |
| mvrhel_laptop | it builds fine for em | 18:07.36 |
| | me | 18:07.38 |
| | I am using VS 2013 though | 18:07.46 |
| | maybe that is the diff | 18:07.50 |
| rayjj | mvrhel_laptop: it builds now, but not before the fixes: | 18:08.38 |
| | d18f698 Fix a missing return type for a function. | 18:08.40 |
| | d7bffde Fix 'warning: ISO C90 forbids mixed declarations and code' | 18:08.41 |
| mvrhel_laptop | it built fine with VS2013 | 18:09.04 |
| | even with the C99 stuff | 18:09.08 |
| rayjj | mvrhel_laptop: I use (mostly) VS 2008 | 18:09.19 |
| mvrhel_laptop | let me clean up the remaining warnings. did marcosw fix the cluster so it gives warnings during cluster pushes? | 18:09.54 |
| | I should have been suspicious when I had no warnings with those changes | 18:10.29 |
| | :( sorry to make work for everyone on that commit. | 18:11.00 |
| | kens and chrisl.... | 18:11.12 |
| | I see chrisl made a commit so that wont happen again | 18:11.51 |
| rayjj | mvrhel_laptop: hopefully | 18:12.29 |
| mvrhel_laptop | oh found a bad one in the warnings list. cluster pushing fix for warnings now. | 18:54.59 |
| Robin_Watts | finishes spewing, for now. | 18:59.16 |
| | http://twiki.ghostscript.com/do/view/Ghostscript/GitPolicies | 18:59.18 |
| mvrhel_laptop | I will read over this since I seem to have caused this firestorm... | 20:00.38 |
| | at least the warnings are now showing up for me during cluster pushes | 20:06.07 |
| | ok. all warnings fixed and pushed | 20:35.37 |
| henrys | mvrhel_laptop: it's a shame we can't all be using c99, MS has said it isn't important to them, seems silly not to move along with the standard. | 20:41.37 |
| mvrhel_laptop | henrys: yes I don't understand what their issue is | 20:43.09 |
| | I do believe they have made quite a bit of movement on it though in VS2013 | 20:47.45 |
| | Forward 1 day (to 2015/01/15)>>> | |
IRC Logs