| 00:01:22 | Viperfang | hidden folder :P |
| 00:03:13 | | Join ReimuHakurei [0] (~reimu@208.119.81.194) |
| 00:06:11 | freddyb | I didn't hide it! |
| 00:06:20 | | Quit ReimuHakurei (Remote host closed the connection) |
| 00:07:22 | | Quit FlynDice (Remote host closed the connection) |
| 00:22:01 | | Quit ender` (Quit: The trouble with quotes found on the Internet is that they often turn out to be unreliable. -- William Shakespeare) |
| 00:22:33 | Biont | I just don't get why my keeps breaking. What's wrong with it? http://pastebin.com/PESgciq9 |
| 00:23:49 | | Quit [Saint] (Ping timeout: 252 seconds) |
| 00:24:04 | Biont | Anyone who reads this: I'm trying to make my old theme work again that I once build for my D2. There's lots of stuff I need to catch up on, but I don't get what could be wrong with the specific part described in the link |
| 00:27:03 | | Quit pamaury (Remote host closed the connection) |
| 00:27:19 | | Quit freddyb (Quit: Leaving) |
| 00:29:53 | | Quit liar (Remote host closed the connection) |
| 00:32:32 | | Join Scromple [0] (~Simon@115-64-195-104.static.tpgi.com.au) |
| 00:40:36 | | Join [Saint] [0] (~st.lasciv@203.184.50.187) |
| 00:41:03 | | Quit ChickeNES (Quit: Computer has gone to sleep.) |
| 00:41:53 | | Join ved2 [0] (~ved@2001:41d0:1:5914::2) |
| 00:41:58 | | Part ved |
| 00:50:01 | | Quit Strife89 (Quit: Vamoose!) |
| 00:50:08 | | Join ChickeNES [0] (~ChickeNES@rouxbicon.rh.uchicago.edu) |
| 00:50:31 | Biont | and for the help I already got in here) |
| 00:50:46 | Biont | damnit, it ate my msg again |
| 00:51:44 | Biont | I said I made a forum post with my problem. thanks in advance for the help there |
| 01:00 |
| 01:01:02 | | Nick ved2 is now known as ved (~ved@2001:41d0:1:5914::2) |
| 01:06:06 | | Quit ChickeNES (Quit: Computer has gone to sleep.) |
| 01:09:53 | | Join ChickeNES [0] (~ChickeNES@rouxbicon.rh.uchicago.edu) |
| 01:21:15 | | Quit Biont (Quit: CGI:IRC) |
| 01:22:36 | *** | Saving seen data "./dancer.seen" |
| 01:43:35 | | Quit [Saint] (Ping timeout: 260 seconds) |
| 01:56:33 | | Join [Saint] [0] (~st.lasciv@203.184.50.187) |
| 01:56:59 | | Join tjb0607 [0] (~quassel@208-100-128-206.bendbroadband.com) |
| 01:58:50 | JdGordon | bertik: well, its not like i wasnt trying to get more testers... which was ignored |
| 01:59:12 | JdGordon | [Saint]: Zagor: you could fake the volume popup in the lists with skinned lists if you really wanted it |
| 01:59:35 | JdGordon | but generally it wouldnt work ecause we dont have proper viewport layering |
| 02:00 |
| 02:00:41 | JdGordon | and regarding auto-skin-resizing.... I wanted to have a script which would resize our source cabbie skins to the specifc size from maybe 4 or 5 source copies instead of 20 |
| 02:00:55 | JdGordon | it cant really be done on target for a number of reasons |
| 02:01:34 | JdGordon | and the script ideas was basically rejected because the output would probably be too crap and need fixing manually anyway |
| 02:08:53 | | Join marc [0] (~chatzilla@94-193-248-10.zone7.bethere.co.uk) |
| 02:09:00 | | Nick marc is now known as marc2003 (~chatzilla@94-193-248-10.zone7.bethere.co.uk) |
| 02:09:17 | | Quit [Saint] (Ping timeout: 244 seconds) |
| 02:11:45 | marc2003 | hi guys, i have 2 amsv2 devices and they were both affected by the problems introduced with r30589. there was a task on flyspray but that has now been closed as fixed. |
| 02:12:35 | marc2003 | my problem is that only 1 of my players now works. i have a clip+ which is working again but i also have a clip v2 which is exhibiting the old problem. should a new task be made or should someone here re-open the old one?? |
| 02:13:39 | marc2003 | the task was FS #12292 |
| 02:13:40 | fs-bluebot | http://www.rockbox.org/tracker/task/12292 Sansa Clip+: Cannot boot since r30589 with real target (bugs, closed) |
| 02:20:29 | | Join funman [0] (~fun@209-197-170-153.cpe.distributel.net) |
| 02:20:56 | | Quit funman (Changing host) |
| 02:20:56 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 02:46:02 | | Join Keripo [0] (~Keripo@eng227.wireless-resnet.upenn.edu) |
| 02:52:24 | | Part marc2003 |
| 02:54:51 | | Quit ChickeNES (Quit: Computer has gone to sleep.) |
| 03:00 |
| 03:02:51 | CIA-14 | New commit by jdgordon (r30614): fix FS #12295 |
| 03:04:42 | CIA-14 | r30614 build result: All green |
| 03:09:40 | | Quit bluefoxx (Ping timeout: 255 seconds) |
| 03:14:44 | | Join ChickeNES [0] (~ChickeNES@rouxbicon.rh.uchicago.edu) |
| 03:15:46 | | Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) |
| 03:22:37 | *** | Saving seen data "./dancer.seen" |
| 03:23:03 | | Join [Saint] [0] (~st.lasciv@203.184.50.187) |
| 04:00 |
| 04:02:12 | | Quit tmzt (Ping timeout: 240 seconds) |
| 04:04:26 | | Join tmzt [0] (~tmzt@adsl-69-208-14-69.dsl.akrnoh.ameritech.net) |
| 04:19:21 | | Join tmzt_ [0] (~tmzt@adsl-69-208-11-149.dsl.akrnoh.ameritech.net) |
| 04:23:00 | | Quit tmzt (Ping timeout: 260 seconds) |
| 04:37:24 | | Quit amiconn (Disconnected by services) |
| 04:37:25 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 04:37:25 | | Quit pixelma (Disconnected by services) |
| 04:37:27 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 04:37:29 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 04:37:47 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 04:42:17 | | Quit [7] (Disconnected by services) |
| 04:42:26 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 05:00 |
| 05:07:27 | | Join Topy [0] (~Topy44@f049178186.adsl.alicedsl.de) |
| 05:11:11 | | Quit T44 (Ping timeout: 248 seconds) |
| 05:11:41 | | Join ReimuHakurei [0] (~reimu@wireless.sit-co.net) |
| 05:22:38 | *** | Saving seen data "./dancer.seen" |
| 05:25:43 | | Quit mc2739 (Quit: leaving) |
| 05:42:11 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 05:42:51 | | Quit ChickeNES (Quit: Computer has gone to sleep.) |
| 05:46:03 | | Quit Horscht (Quit: Verlassend) |
| 05:50:10 | | Quit simonlnu (Remote host closed the connection) |
| 05:53:34 | | Join Rob2222 [0] (~Miranda@p4FFF0F7F.dip.t-dialin.net) |
| 05:57:12 | | Quit Rob2223 (Ping timeout: 252 seconds) |
| 05:57:35 | | Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au) |
| 06:00 |
| 06:02:37 | | Join Jak_o_Shadows1 [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au) |
| 06:03:24 | | Quit Jak_o_Shadows (Ping timeout: 240 seconds) |
| 06:04:52 | | Join simonlnu [0] (a1uEnLmhma@unaffiliated/simonrvn) |
| 06:28:00 | | Quit ReimuHakurei (Ping timeout: 255 seconds) |
| 06:30:51 | | Join ReimuHakurei [0] (~reimu@wireless.sit-co.net) |
| 06:47:09 | | Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) |
| 06:52:25 | | Join freddyb [0] (~freddybbb@216.8.239.112.etczone.com) |
| 06:53:05 | | Quit freddyb (Client Quit) |
| 06:58:15 | | Join ChickeNES [0] (~ChickeNES@rouxbicon.rh.uchicago.edu) |
| 07:00 |
| 07:04:17 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
| 07:10:44 | | Quit mshathlonxp () |
| 07:12:53 | | Quit funman (Quit: leaving) |
| 07:16:03 | | Join T44 [0] (~Topy44@f049034078.adsl.alicedsl.de) |
| 07:18:39 | | Quit Topy (Ping timeout: 248 seconds) |
| 07:22:40 | *** | Saving seen data "./dancer.seen" |
| 07:43:51 | | Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) |
| 07:48:40 | | Quit tjb0607 (Read error: Connection reset by peer) |
| 07:49:27 | | Quit wodz (Ping timeout: 255 seconds) |
| 07:49:45 | | Join tjb0607 [0] (~quassel@208-100-128-206.bendbroadband.com) |
| 07:50:25 | | Quit tjb0607 (Read error: Connection reset by peer) |
| 07:51:01 | | Join tjb0607 [0] (~quassel@208-100-128-206.bendbroadband.com) |
| 07:59:58 | | Quit tjb0607 (Read error: Connection reset by peer) |
| 08:00 |
| 08:00:41 | | Quit ChickeNES (Quit: Computer has gone to sleep.) |
| 08:01:21 | | Join tjb0607 [0] (~quassel@208-100-128-206.bendbroadband.com) |
| 08:01:57 | | Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au) |
| 08:03:30 | | Quit Jak_o_Shadows1 (Ping timeout: 245 seconds) |
| 08:08:37 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
| 08:09:59 | | Quit powell14ski_ (Quit: powell14ski_) |
| 08:10:01 | kugelp | JdGordon: you had enough testers (my fs inbox wad full with messagesfrom that task) and they found many bugs. but in the end you got impatient... |
| 08:18:44 | | Quit blind (Ping timeout: 252 seconds) |
| 08:26:44 | | Join ender` [0] (~ender@foo.eternallybored.org) |
| 08:28:00 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
| 08:28:07 | | Join evilnick [0] (~evilnick@5e007ec9.bb.sky.com) |
| 08:28:07 | | Quit evilnick (Changing host) |
| 08:28:07 | | Join evilnick [0] (~evilnick@rockbox/staff/evilnick) |
| 08:31:49 | | Join blind [0] (~blind@c-71-235-61-84.hsd1.ct.comcast.net) |
| 08:35:13 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
| 08:35:15 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
| 08:36:26 | | Join B4gder [241] (~daniel@rockbox/developer/bagder) |
| 08:39:23 | | Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) |
| 08:40:08 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
| 08:41:42 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 08:41:42 | | Quit bertrik (Changing host) |
| 08:41:42 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 08:51:22 | | Quit [Saint] (Ping timeout: 276 seconds) |
| 08:59:52 | kugel | JdGordon: if you're offline for a few days, then I too think the font commit should be reverted for now |
| 09:00 |
| 09:01:27 | JdGordon | 1) every bug reported was fixed pre commit... 2) fix it yourself.. im so fucking close to just revoking my commit acces... you ersonally am the reason i have absolutly no fun here anymore |
| 09:02:13 | kugel | bertrik has still data aborts |
| 09:02:26 | JdGordon | did bertrik test while i was asking? no... |
| 09:02:28 | kugel | the boot up crashes/freezes are apparently still not fixed |
| 09:02:37 | | Join Jak_o_Shadows1 [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au) |
| 09:02:48 | kugel | you didn't really wait a long time. |
| 09:04:08 | kugel | you should have, considering how many bugs were reported pre-commit. it was quite likely that more are to come |
| 09:05:11 | | Quit Jak_o_Shadows (Ping timeout: 255 seconds) |
| 09:06:21 | kugel | anyway, I disagree we should have a possibly-not-even-booting rockbox any longer |
| 09:13:43 | | Join webguest63 [0] (~4d6c62b0@www.haxx.se) |
| 09:14:00 | JdGordon | actually stuff it... |
| 09:14:27 | JdGordon | my input is no longer deemed worthy of conciseration anynmore (and hasnt been for a while). the projects direction has been hijacked |
| 09:14:35 | JdGordon | im out... Zagor please disable my svn account |
| 09:14:56 | kugel | that's not true |
| 09:15:00 | JdGordon | this font issue is not the reason |
| 09:15:13 | JdGordon | good by |
| 09:15:23 | kugel | :\ |
| 09:15:28 | JdGordon | I'll no longer be contriuting, feel free to cherry pick from my github account |
| 09:16:21 | JdGordon | though the fact that its even suggested i should justify commits to code im the sole contirbuter is a pretty big final straw |
| 09:17:46 | kugel | being the sole contributor to one area doesn't make you immune to criticism |
| 09:18:03 | JdGordon | like i said, its not that issue |
| 09:18:39 | JdGordon | whoever moderates the commiters ml, please let that email through (it aparently doesnt like being bcced) |
| 09:19:17 | JdGordon | in the unlikely event of some serious project restructing happens i might come back, but i think most people woudltn care anyway |
| 09:19:26 | JdGordon | and now, afk for 3 days |
| 09:19:35 | bertrik | JdGordon, I'm not taking responsibility if you break something |
| 09:19:48 | | Nick JdGordon is now known as jd|afk_til_sat (~jonno@rockbox/developer/JdGordon) |
| 09:20:24 | kugel | I'm sorry if it looked like your contribution is worthless. That wasn't my intention. They're very valuable |
| 09:22:43 | *** | Saving seen data "./dancer.seen" |
| 09:22:53 | | Quit Scromple (Quit: Leaving) |
| 09:23:41 | | Join nick-p [0] (~nick@82-69-105-120.dsl.in-addr.zen.co.uk) |
| 09:28:47 | | Quit bertrik (Ping timeout: 248 seconds) |
| 09:29:21 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 09:36:13 | | Join God_Eater [0] (93722cd1@rockbox/staff/GodEater) |
| 09:55:51 | | Quit webguest63 (Quit: CGI:IRC (EOF)) |
| 09:57:12 | | Quit wodz (Remote host closed the connection) |
| 10:00 |
| 10:02:48 | | Join swilde [0] (~wilde@aktaia.intevation.org) |
| 10:03:11 | | Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au) |
| 10:04:36 | | Quit Jak_o_Shadows1 (Ping timeout: 240 seconds) |
| 10:15:38 | | Quit Llorean (Ping timeout: 260 seconds) |
| 10:17:59 | | Join jordan` [0] (~gromit@posteauge.rsr.lip6.fr) |
| 10:18:46 | | Join Llorean [0] (~DarkkOne@99-68-45-56.lightspeed.hstntx.sbcglobal.net) |
| 10:24:25 | | Join pamaury [0] (81680b01@gateway/web/freenode/ip.129.104.11.1) |
| 10:37:35 | | Quit GeekShadow (Ping timeout: 248 seconds) |
| 10:38:45 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 10:39:45 | | Join Jak_o_Shadows1 [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au) |
| 10:40:39 | | Quit Jak_o_Shadows (Ping timeout: 260 seconds) |
| 10:41:51 | | Quit kadoban (Ping timeout: 248 seconds) |
| 10:42:07 | | Join dfkt|n [0] (dfktn@chello062178002170.1.11.univie.teleweb.at) |
| 10:42:07 | | Quit dfkt|n (Changing host) |
| 10:42:08 | | Join dfkt|n [0] (dfktn@unaffiliated/dfkt) |
| 10:49:26 | | Quit dfkt|n () |
| 10:50:50 | | Quit Keripo (Read error: Connection reset by peer) |
| 10:53:33 | | Part nick-p ("Leaving") |
| 10:54:22 | wodz | Jd withdrawal is rather said event :/ |
| 11:00 |
| 11:03:50 | | Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au) |
| 11:05:35 | | Quit Jak_o_Shadows1 (Ping timeout: 244 seconds) |
| 11:09:20 | | Join GeekShadow [0] (~antoine@54.166.21.93.rev.sfr.net) |
| 11:10:14 | | Quit mystica555 (Read error: Connection reset by peer) |
| 11:10:15 | | Quit mystica555_ (Read error: Connection reset by peer) |
| 11:11:34 | | Quit Jak_o_Shadows (Remote host closed the connection) |
| 11:16:58 | | Quit GeekShadow (Ping timeout: 276 seconds) |
| 11:17:37 | | Quit Llorean (Changing host) |
| 11:17:37 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
| 11:18:22 | | Join GeekShadow [0] (~antoine@77.166.21.93.rev.sfr.net) |
| 11:19:16 | | Join mystica555_ [0] (~mike@71-211-199-174.hlrn.qwest.net) |
| 11:22:22 | | Quit T44 (Ping timeout: 248 seconds) |
| 11:22:47 | *** | Saving seen data "./dancer.seen" |
| 11:26:51 | | Join mystica555 [0] (~Mike@71-211-199-174.hlrn.qwest.net) |
| 11:38:23 | | Quit fs-bluebot (Ping timeout: 260 seconds) |
| 11:38:44 | | Quit bluebrother^ (Ping timeout: 260 seconds) |
| 11:39:37 | | Join fs-bluebot [0] (~fs-bluebo@g226070254.adsl.alicedsl.de) |
| 11:40:02 | | Join bluebrother [0] (~dom@g226070254.adsl.alicedsl.de) |
| 11:40:41 | | Quit bluebrother (Changing host) |
| 11:40:41 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 11:47:24 | | Quit Bagder (Ping timeout: 240 seconds) |
| 11:54:44 | | Join webguest99 [0] (~4d6c62b0@www.haxx.se) |
| 11:57:03 | | Join n1s [0] (~quassel@rockbox/developer/n1s) |
| 12:00 |
| 12:00:22 | | Join user829385 [0] (~aoeu@112.166.15.141) |
| 12:00:55 | | Part user829385 |
| 12:30:48 | | Join Jerom [0] (~jerome@2a02:8420:215:f000:f66d:4ff:fe45:790f) |
| 12:42:29 | | Quit wodz (Quit: Leaving) |
| 12:43:41 | | Quit Jerom (Quit: Leaving.) |
| 12:46:33 | | Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au) |
| 12:48:06 | | Quit Jak_o_Shadows (Remote host closed the connection) |
| 13:00 |
| 13:20:19 | | Quit mamarley (Remote host closed the connection) |
| 13:22:49 | *** | Saving seen data "./dancer.seen" |
| 13:31:31 | | Part Zagor |
| 13:32:11 | | Part LinusN |
| 13:36:51 | God_Eater | should we clean up the "official" gerrit now, and bin most of the sandbox stuff that's there now? |
| 13:37:08 | God_Eater | or is it simply a 1-2-1 copy of what was on the VPS? |
| 13:37:16 | God_Eater | and not really reflective of current svn? |
| 13:48:53 | | Join matze` [0] (~pflaume@p5498A67E.dip.t-dialin.net) |
| 13:55:59 | | Join XavierGr [0] (~xavier@rockbox/staff/XavierGr) |
| 14:00 |
| 14:01:49 | | Join bluefoxx_ [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) |
| 14:04:01 | Torne | God_Eater: it's a copy of what's on the VPS |
| 14:04:15 | Torne | God_Eater: The sandbox repo is as-is and we can clean it up at our leisure or leave it, either way |
| 14:04:24 | Torne | i am still manually replicating the real rockbox repos |
| 14:04:43 | Torne | hoping to get that happening automatically soon |
| 14:04:46 | | Quit bluefoxx (Ping timeout: 255 seconds) |
| 14:04:49 | God_Eater | ah ok |
| 14:04:51 | God_Eater | cool |
| 14:05:05 | Torne | i wasn't going to delete the sandbox yet because people may not have tried, and also i think we need to play with policies a bit more |
| 14:05:21 | God_Eater | that makes sense |
| 14:05:30 | Torne | i've changed my mind about waht i think is a good policy |
| 14:05:32 | Torne | i thinik. |
| 14:05:43 | Torne | i think i've decided i don't like the current policy *or* the way everyone wanted |
| 14:05:52 | Torne | i'm leaning toward a third option :p |
| 14:05:53 | kugel | Torne: I thought you finished the conversion? |
| 14:05:57 | God_Eater | which is? :) |
| 14:06:02 | Torne | kugel: hrm? |
| 14:06:13 | Torne | the conversion doesn't finish until we stop making more changes to svn :) |
| 14:06:24 | Torne | it's up to date as of, er, last night |
| 14:06:31 | Torne | but new changes keep happening! :) |
| 14:06:42 | Torne | God_Eater: non-fastforward merges |
| 14:07:00 | kugel | didn't you say you need to convert only once, and can then rebase after that? |
| 14:07:06 | Torne | kugel: what? |
| 14:07:37 | Torne | not sure what rebasing has to do with anything |
| 14:07:51 | kugel | like, git svn rebase |
| 14:07:53 | ukleinek | kugel: if svn is converted up to say r10000 and you commit r10001 git doesn't know about r10001 |
| 14:08:06 | Torne | Oh. git svn rebase is irrelevant |
| 14:08:11 | Torne | that only applies to repositories with local branches |
| 14:08:19 | Torne | there is nothing to rebase in my intermediate repo |
| 14:08:39 | Torne | i just fetch from svn then push directly to gerritwith a refspec that remaps various names |
| 14:08:55 | ukleinek | kugel: the patch that svn knows as r10001 just needs to be applied to what git has for r10000 |
| 14:09:13 | Torne | kugel: this is what i mean by conversion |
| 14:09:19 | Torne | since this is just a continuation of the same process.. |
| 14:09:25 | Torne | that's how i went from r1, nothing has changed |
| 14:09:31 | Torne | it just happens in smaller increments now :) |
| 14:10:06 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 14:10:47 | Torne | God_Eater: i need to set up some examples or maybe just draw some example graphs to show the different policy choices that i'm considering |
| 14:11:18 | God_Eater | graphs sounds like a good plan |
| 14:11:20 | Torne | God_Eater: it's kinda complex because there's two semi-independant things to consider: what to encourage (or require) committers to do when pushing to master directly, and what Gerrit should do when *it* submits changes |
| 14:11:28 | God_Eater | they were effective at DevCon I thought |
| 14:11:29 | Torne | Ideally we want both of those to behave similarly :) |
| 14:11:48 | God_Eater | absolutely |
| 14:11:48 | Torne | gerrit has four ways to apply changes, all of which have upsides and downsides depending on your expectations/preferences |
| 14:12:07 | Torne | in terms of enforcing what committers directly push, though, there's only two choices: allow merges or don't |
| 14:12:14 | Torne | anything beyond that has to be enforced by convention |
| 14:12:45 | kugel | I thought we established to allow merges after enabling a setting |
| 14:13:08 | Torne | kugel: that's not really a solution to "what should we encourage people to do", though |
| 14:13:16 | Torne | that still allows people to just do whatever |
| 14:13:32 | Torne | allowing merges (always or with some setting) leaves you with various options |
| 14:13:44 | Torne | and the "default" behaviour of git when you do that is, er, |
| 14:13:50 | Torne | not something i'm particularly fond of |
| 14:14:00 | Torne | because it produces needlessly complicated history |
| 14:14:19 | Torne | but i'v ebeen experimenting with various things and I think I'm much happier with non-fastforward merges |
| 14:14:55 | Torne | which produces, technically, *more* history, but it's in theory simpler :) |
| 14:15:11 | Torne | and you can choose to only look at the part of it that's linear without loss of information |
| 14:15:24 | kugel | you don't like fast-forward merges? |
| 14:15:35 | Torne | i don't like fastforwarding to submit to trunk, no |
| 14:15:46 | Torne | it breaks the ability to see a linear history of changes |
| 14:16:03 | Torne | and, in gerrit's case, breaks the ability to mark commits with who reviewed/approved them |
| 14:16:04 | kugel | are those the ones which don't have the extraneous "merge bla" commit? |
| 14:16:12 | Torne | Yes |
| 14:16:43 | kugel | can one force a merge commit? |
| 14:16:50 | Torne | *You* can |
| 14:16:52 | Torne | I don't think the server can |
| 14:16:57 | Torne | git merge −−no-ff |
| 14:17:11 | Torne | well, it possibly can, i'm not sure. |
| 14:17:33 | Torne | the advantage of forcing the merge commit is that if you start from HEAD and just follow the first parent of each commit.. |
| 14:17:41 | Torne | you see exacfly one (merge) commit for each submitted change |
| 14:18:02 | Torne | you never see anyone's intermediate development states unless you go look for it |
| 14:18:27 | kugel | this needs graphs or examples :) |
| 14:18:42 | Torne | http://blog.prelode.com/2011/04/history-cleanliness-in-git/ <- this explains somewhat |
| 14:19:36 | Torne | well, ignore his explanation mostly |
| 14:19:40 | Torne | i don't agree with his opinions |
| 14:19:44 | Torne | but his *diagrams* are useful :) |
| 14:19:54 | Torne | the thing i object to is the history shown in the first diagram |
| 14:20:03 | Torne | because that's basically incomprehensible |
| 14:20:14 | Torne | to someone who just cares about what's been committed. |
| 14:20:29 | Torne | the thing i am proposing here is the diagram for option 2, only merges on master |
| 14:21:09 | Torne | a number of projects work that way, including git itself |
| 14:21:48 | | Nick soap is now known as soap_ (~soap@rockbox/staff/soap) |
| 14:23:14 | Torne | for developers the only thing you have to do is "always merge from master using merge −−no-ff" |
| 14:23:28 | Torne | er, to/from master |
| 14:23:35 | kugel | only merge to master sounds ok. what does it prevent? That I merge from someone who merged from a third? |
| 14:23:36 | Torne | er, just to :) |
| 14:23:54 | Torne | No, you cna still do that kind of thing |
| 14:23:58 | Torne | It doesn't *prevent* anything |
| 14:24:11 | Torne | You can do exactly the same sequence of calls to "git merge" either way |
| 14:24:21 | Torne | it just happens that by default some of those calls may not generate a new commit |
| 14:24:25 | * | ukleinek thinks git.git doesn't have a "only merge on master" policy |
| 14:24:46 | Torne | pretty sure it does |
| 14:25:09 | Torne | Oh, hm |
| 14:25:11 | Torne | maybe not :/ |
| 14:25:12 | ukleinek | Torne: maybe it looks like it in practice |
| 14:25:34 | Torne | someone elsewhere claimed it did, sorry |
| 14:25:38 | Torne | Anyway, yeah |
| 14:25:48 | Torne | The basic point is... most of the time you will generate a merge commit |
| 14:25:57 | kugel | I don't think merges are going to be a problem either way unless we switch to the torvalds workflow |
| 14:25:59 | Torne | regardless. |
| 14:26:08 | kugel | most of the time we'll push like svn commit |
| 14:26:13 | Torne | because *most* of the time you won't be up to date when you come to submit |
| 14:26:25 | Torne | kugel: this isn't about doing/not doing merges |
| 14:26:42 | Torne | in any case where you would've had to have *done* a merge, in the sense of actually checking it did the right thing, it's always going to be a merge anyway |
| 14:26:48 | ukleinek | if you don't like merges, there is always git log −−no-merges :-) |
| 14:27:01 | Torne | kugel: this is about what happens when you *don't* have to merge |
| 14:27:07 | Torne | because your development branch happens to be up to date |
| 14:27:30 | kugel | then we can push straight away no? |
| 14:27:43 | Torne | kugel: That's what I'm trying to *prevent* |
| 14:27:48 | Torne | because tha makes an incomprehensible hisotry |
| 14:27:56 | | Join LinusN [0] (~linus@giant.haxx.se) |
| 14:28:10 | ukleinek | git works like so: http://repo.or.cz/w/alt-git.git/blob/HEAD:/Documentation/howto/maintain-git.txt |
| 14:28:13 | Torne | kugel: if you do that you end up with graphs that look like the first one shown |
| 14:29:01 | ukleinek | Torne: what is your problem with the first graph? |
| 14:29:17 | kugel | it looks better to me than the big second one |
| 14:29:29 | kugel | but I see the difference is that master only contains merge commits |
| 14:30:01 | Torne | ukleinek: the problem is that there is no line you can follow which has all the changes in order |
| 14:30:34 | kugel | who's interested in the actual lines? :) |
| 14:30:43 | Lalufu | well, if you're doing parallel development in multiple trees the concept of "changes in order" becomes somewhat moot. |
| 14:30:59 | Torne | kugel: anyone who ever has to work out whether a given change is in a given user-reported version or not |
| 14:31:34 | Torne | Lalufu: no it doesn;'t |
| 14:31:40 | Lalufu | git branch −−contains |
| 14:31:51 | Torne | Lalufu: that only answers the question in one direction |
| 14:31:57 | Torne | that's really not useful |
| 14:32:11 | Torne | Lalufu: Submitted changes are still in a perfectly linear sequence |
| 14:32:25 | Torne | Every time someone moves master, that's one or more new submitted changes |
| 14:32:32 | Torne | The buildbots build new builds based on that |
| 14:32:38 | Torne | Everything is perfectly linear and oredered |
| 14:32:51 | Torne | The actual *commits* that make up those logical changes to the code are more complicated |
| 14:33:28 | Torne | but from the point of view of "people watching master", which includes the bots and everyone who uses the builds produced by the bots, there is a perfectly obvious chronological order there |
| 14:33:46 | ukleinek | Torne: test -z $(git rev-list −−max-count=1 $userreportedversion..$givenchange) |
| 14:34:02 | Torne | The problem with that first graph is that the obvious chronological order of what is in what build is *not visible* in the log |
| 14:34:12 | Torne | You can't see the real order |
| 14:34:39 | Torne | The chronological order of the *commits* is first, second, third, fourth, fifth, etc |
| 14:34:51 | Torne | but the order of those changes entering the build is as shown in the other graphs, which is totally different |
| 14:34:53 | ukleinek | Torne: git log −−first-parent works if you have a single integrator (as Linus T. is for Linux) |
| 14:35:11 | Torne | ukleinek: Yes, indeed |
| 14:35:13 | Torne | We don't |
| 14:35:15 | Torne | So, it won't |
| 14:35:40 | Torne | Using git merge −−no-ff makes git log −−first-parent work *anyway* |
| 14:35:42 | Torne | That's the entire point |
| 14:35:55 | Torne | The log shown in "only merges on master" which is the short one is, exactly, git log −−first-parent |
| 14:36:03 | ukleinek | Torne: but only if you merge in the new changes and not upstream |
| 14:36:28 | ukleinek | the latter seems to be the more obvious thing to do with rockbox' development model. |
| 14:36:33 | Torne | er, what? |
| 14:36:35 | Torne | no it doesn't |
| 14:36:41 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
| 14:37:00 | ukleinek | I want to push, oh, master moved, git pull origin master, git push |
| 14:37:37 | Torne | also, you are refererring to a development model that we *haven't written yet* :) |
| 14:37:47 | Torne | since currently *nobody submits using git* since you can't |
| 14:38:06 | Torne | so what you mean is "what you would do in the absence of other instructions is not this" |
| 14:38:10 | Torne | which is besides the point |
| 14:38:15 | Torne | since what i'm proposing here is that we, yaknow |
| 14:38:23 | Torne | write instructions to ensure the outcome we want |
| 14:39:13 | Lalufu | Torne: I just replayed the first picture on http://blog.prelode.com/2011/04/history-cleanliness-in-git/ |
| 14:39:38 | Lalufu | http://pastebin.com/iGm6pJzZ |
| 14:39:52 | Lalufu | that's "git log" on master after the last merge. |
| 14:39:59 | Lalufu | what's the problem with that? |
| 14:40:35 | Torne | Lalufu: THe problem is that's *not the order that they got applied to the tree in* |
| 14:40:50 | Torne | so it's bloody misleading |
| 14:41:05 | ukleinek | Torne: what is wrong? |
| 14:41:18 | Torne | ukleinek: ok, so imagine this is our tree, and we have our buildbots as they are now |
| 14:41:26 | Torne | such that every time someone pushes to master, they kick off a new build and publish it |
| 14:41:33 | Torne | right? |
| 14:42:09 | Torne | someone downloads the build from 49dc336 and installs it on their player |
| 14:42:18 | Torne | they use it and they find a bug |
| 14:42:42 | Lalufu | so you expect to see "initial, first, second, fifth, eighth, third, fourth, sixth, ninth, seventh"? |
| 14:42:45 | Torne | that bug is fixed by c25ed26 |
| 14:42:58 | Torne | Now, c25ed26 is displayed in the log *before* 49dc336 |
| 14:43:04 | Torne | but the bugfix is not in their build. |
| 14:43:10 | Torne | I struggle to see how this is good :) |
| 14:43:15 | Torne | Lalufu: yes |
| 14:43:23 | kugel | huh? |
| 14:43:34 | Torne | i expect to see changes in the order that they would be received by *another* user who is pulling from the central master branch frequently |
| 14:43:36 | kugel | how can c2.. be displayed before 49..? |
| 14:43:46 | Lalufu | Now I have to admin that I do not know what git actually does when I do a merge. |
| 14:43:47 | kugel | they're ordered by date of commit, no? |
| 14:43:51 | Torne | kugel: yes |
| 14:43:57 | Torne | date of commit, not date of being merged to master |
| 14:44:08 | Lalufu | Are you sure that the commits from the branch are applied on top of the current state of master? |
| 14:44:09 | Torne | kugel: so if you develop something now and commit it |
| 14:44:16 | Torne | and then don't submit it to master for a year |
| 14:44:21 | Torne | it will show up in the log a year ago |
| 14:44:27 | kugel | yes |
| 14:44:38 | kugel | that doesn't answer my quiestion |
| 14:45:03 | Torne | Er, by "before" i mean earlier in the log |
| 14:45:12 | Torne | the log is in reverse time order so it's later in the actual output |
| 14:45:15 | Torne | if that's what you mean |
| 14:45:27 | kugel | yes |
| 14:45:52 | kugel | the fix (c2..) after the buggy build (49...) |
| 14:46:04 | kugel | that's alright isn't it? |
| 14:46:07 | Torne | kugel: No |
| 14:46:09 | Torne | Look at the log.. |
| 14:46:23 | Torne | the one Lalufu made, or the one in faux's blog post, they both show the same thing |
| 14:46:31 | Torne | Oh |
| 14:46:39 | Torne | Except lalufu made his own commits so the hashes are differnet :) |
| 14:46:46 | Torne | but you can see that the order is the same as in faux's log display |
| 14:47:02 | Torne | since they are named first/second/third/etc to be the order they display :) |
| 14:47:28 | Torne | Oh, gah |
| 14:47:36 | Torne | and of course they're *also* different commits in the different pictures. |
| 14:47:39 | Torne | Okay, sorry |
| 14:47:45 | Torne | the way i have explained this is inadvertently really unhelpful :) |
| 14:48:33 | Lalufu | in my example "first, second"... is the order I created the commits in |
| 14:48:39 | Torne | Lalufu: yes, the same for his |
| 14:48:45 | Lalufu | OK. |
| 14:49:01 | Torne | so the actual order they are available in builds is first, second, fifth, eigth, third, fourth, sixth, ninth, seventh. |
| 14:49:15 | Torne | though builds would not exist for all of those as some are merged simultaneously |
| 14:50:03 | * | ukleinek reads backlog |
| 14:50:20 | Torne | you would have builds containing (first), (second), (fifth), (eighth), (third, fourth, sixth), (ninth), (seventh) |
| 14:50:23 | ukleinek | Torne: I'm sure that out of order log can happen in the first image too |
| 14:50:33 | Torne | ..huh? |
| 14:50:38 | Torne | The first image *is* the one with the out of order log |
| 14:51:01 | ukleinek | if seventh was commited before sixth |
| 14:51:25 | Torne | The entire point I am making is that the log is out of order here |
| 14:51:30 | Torne | The first image there is showing that it's out of order |
| 14:51:34 | Torne | as does Lalufu's log |
| 14:51:36 | Torne | which is the same thing |
| 14:51:50 | Torne | just without being −−oneline and whatever option makes it draw the nice branch asciiart |
| 14:52:21 | Torne | i froget :) |
| 14:53:41 | ukleinek | ah, let me check the 'only merges on master image' |
| 14:53:44 | | Join webguest85 [0] (~3b9c9e87@www.haxx.se) |
| 14:53:45 | ukleinek | git log −−graph btw |
| 14:54:04 | kugel | Torne: I still don't understand how your scenario is possible |
| 14:54:11 | ukleinek | Torne: still applies there |
| 14:54:16 | Torne | ukleinek: no it doesn't |
| 14:54:23 | ukleinek | Torne: if seventh was commited before sixth |
| 14:54:37 | Torne | that makes no difference |
| 14:54:44 | Torne | you get the exact same thing when you look at the first parents |
| 14:54:58 | Torne | kugel: it's not just possible, it's basically guaranteed :) |
| 14:55:05 | ukleinek | Torne: ?? |
| 14:55:47 | Torne | ukleinek: if your master branch contains only merges-to-master and you look at the log of the first parents of those merges then you never *see* the timestamps of the actual commits |
| 14:55:56 | Torne | therefore changing the timestamps of the actual commits cannot possibly change the order displayed |
| 14:57:02 | Torne | kugel: the scenario is right there on that page, i can't see how you can fail to see it's possible |
| 14:58:48 | kugel | I ooked at the pastie when you explained it |
| 14:59:21 | Torne | lalufu's log? |
| 14:59:35 | kugel | yes |
| 14:59:45 | kugel | I don't see these commits on the page eitehr |
| 14:59:47 | Torne | assuming he did it right and it matches what's in the blog post then yes, that's out of order |
| 15:00 |
| 15:00:04 | Torne | it's in chronological order of commit, which is bascially guaranteed to be wrong in a DVCS |
| 15:00:12 | Torne | well, wrong is a loaded term |
| 15:00:21 | kugel | it's not how changes went into master |
| 15:00:24 | Torne | Is basically guaranteed not to be the order in which those changes appeared to someone else watching the master branch |
| 15:00:27 | Torne | Yeah. |
| 15:00:39 | kugel | but it still shoudnt show a fix before a buggy state |
| 15:00:51 | Torne | then you misunderstand how git works entirely |
| 15:00:55 | Torne | because it trivially can do that |
| 15:01:03 | kugel | Torne: can you please tell me what commits you mean? |
| 15:01:37 | Torne | OK, so using the commit messages instead because yes, sorry, the commit hashes i referred to earlier were from one of the images and thus not useful |
| 15:01:41 | kugel | I don't see c2.. or 49.. in either log |
| 15:01:51 | Torne | Right, the commits i'm referring to are from the merges-on-master image |
| 15:01:55 | ukleinek | Torne: but with −−first-parent you don't see the commits at all, only the merges |
| 15:01:58 | Torne | because that's place it's easiest to pull examples for |
| 15:02:04 | Torne | ukleinek: Yes. That's the point. |
| 15:02:15 | Torne | kugel: so let's assume the bug existed from the start |
| 15:02:21 | Torne | kugel: the bug gets fixed by "third on devel" |
| 15:02:37 | Torne | a user downloads a build which is compiled from "eighth on maser" |
| 15:02:46 | Torne | This build does not include the fix. |
| 15:03:28 | * | kugel doesn't see "third on devel" |
| 15:03:35 | ukleinek | kugel: thrid |
| 15:03:39 | ukleinek | third |
| 15:03:44 | Torne | kugel: what are you looking at exactly then? |
| 15:03:46 | Torne | because i see it |
| 15:03:47 | Lalufu | kugel: line 55 in my paste |
| 15:03:47 | | Quit webguest85 (Quit: CGI:IRC (EOF)) |
| 15:03:51 | kugel | http://blog.prelode.com/2011/04/history-cleanliness-in-git/ |
| 15:03:54 | Torne | kugel: ARGH |
| 15:04:01 | Torne | yuou just said you were looking at Lalufu's pastebin |
| 15:04:05 | Torne | so i explained it by reference to that |
| 15:04:16 | kugel | I switched to the images when you said your commits are there |
| 15:04:22 | Torne | he has not copied the names of the commimts exactly |
| 15:04:29 | Torne | The number is the only part that matters |
| 15:04:36 | Torne | 1/2/3/45/6/7/8/9. right? |
| 15:04:37 | | Quit antil33t (Remote host closed the connection) |
| 15:04:51 | Torne | because that way i can stop misspelling eighth |
| 15:04:53 | Torne | :) |
| 15:04:58 | kugel | ok, back to Lalufu's log |
| 15:05:00 | kugel | . |
| 15:05:03 | | Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz) |
| 15:05:04 | Torne | Look at either, doesn't matter. |
| 15:05:21 | kugel | it does matter to understand what you're saying, apparently :) |
| 15:05:21 | Torne | Bug exists from start. Commit 3 fixes it. Build based on commit 8 does not include fix. |
| 15:05:29 | ukleinek | 8 includes 3 |
| 15:05:30 | Torne | It doesn't if I just say the numbers. |
| 15:05:32 | Torne | No it doesn't |
| 15:05:49 | ukleinek | it comes into master when 5 is merged |
| 15:06:00 | kugel | if it doesnt include the fix it doesn't show it in the log |
| 15:06:01 | Torne | No it doesn't |
| 15:06:07 | Lalufu | I see what he means. |
| 15:06:18 | Torne | kugel: it does show it in the log *if you look at the log at a point after the point where the fix *was* merged* |
| 15:06:21 | Lalufu | if we are at 8, before the merge, and do a build, the fix is not in it. |
| 15:06:30 | Torne | if you look at the log for HEAD, after all these commmits are madde |
| 15:06:31 | Lalufu | after the merge it _looks_ as if the fix was in before 8 |
| 15:06:39 | Torne | Yes! Exactly :) |
| 15:06:46 | kugel | okay |
| 15:06:50 | kugel | I understand now |
| 15:06:50 | ukleinek | Torne: 8 includes 3 |
| 15:06:54 | Torne | ukleinek: You are still wrong |
| 15:07:11 | Torne | ukleinek: The fact that you are able to get this wrong is a point in my favour: if the log wasn't so confusing you won't make this mistake |
| 15:07:17 | Torne | :) |
| 15:07:43 | Torne | The log for 8 will look like: 8, 5, 2, 1, initial |
| 15:07:47 | Torne | because that's all that's included in it |
| 15:07:52 | ukleinek | Torne: I look at the blog, 8's parent is merge5, merge5's 2nd parent is 5, 5's parent is 4, 4's parent is 3 |
| 15:08:00 | Torne | 5 is NOT A MERGE |
| 15:08:07 | Torne | 5 is a plain commit to the master branch |
| 15:08:16 | Lalufu | Torne: but if you do a "git log af2789595a3c6516d2a55677e3a3aff49baaa8f5" (which is the commit of 8) you see that 3 is not in |
| 15:08:32 | Torne | Lalufu: sure, i'm not saying it's impossible to figure out the answer, there are lots of ways to work it out |
| 15:08:33 | Lalufu | you have to look at the log of the build, not some log after that |
| 15:08:37 | Torne | I am complaining about the fact that you have to actually think about it |
| 15:08:44 | Torne | rather than it being entirely obvious and linear as they are now with svn |
| 15:09:03 | Lalufu | That was kind of the point of my remark earlier. |
| 15:09:03 | ukleinek | Torne: yeah, git log −−first-parent 8 doesn't show 3, but the change that 3 did is included in 8 |
| 15:09:20 | Torne | ukleinek: No it isn't |
| 15:09:20 | Lalufu | both forms have their merit, I do not see one as being more "right" than the other |
| 15:09:25 | Torne | ukleinek: Seriously, you are *still* wrong |
| 15:09:35 | Torne | ukleinek: Everyone else agrees :) |
| 15:09:36 | Lalufu | ukleinek: really, it is not. |
| 15:09:49 | Lalufu | the branch that contains 3 is merged _after_ 8 |
| 15:09:53 | Torne | and again, the fact that you are still wrong here means that I am right and this *is* confusing :) |
| 15:10:04 | Lalufu | so a build from master directly after 8 is committed does not contain 3 |
| 15:10:51 | Torne | Lalufu: no, i don't think they both have their merits |
| 15:11:15 | Torne | From the point of view of someone trying to *read history* and work out what has happened (ignoring the actual developer effort) the ideal situation is a flat history |
| 15:11:35 | Lalufu | and what do you want that history to show? |
| 15:11:39 | Torne | because that's subject to no ambiguity or misinterpretation |
| 15:11:42 | Lalufu | the state of the tree at every commit? |
| 15:11:46 | Torne | But, an actual flat history is a huge pain for *developers* |
| 15:11:49 | Lalufu | or the order in which the commits were applied? |
| 15:11:54 | Torne | because it requires that you rebase all changes before committing, and forbid merging |
| 15:11:55 | ukleinek | the fact that you all get it wrong proves the confusion even more :-) |
| 15:12:05 | Lalufu | I'm not sure that's the same thing for GIT. |
| 15:12:35 | ukleinek | Lalufu: 3 comes in in 3bf6e08 |
| 15:12:37 | Torne | So, I'm proposing something that lets you have the illusion of a flat history when you want to look at it in those terms, but does not require developers to rewrite their history while developing |
| 15:12:44 | ukleinek | (in the blog image) |
| 15:12:52 | Torne | The process of submitting is *different* in this system |
| 15:12:56 | Torne | but it's not any extra work |
| 15:13:24 | Torne | unlike rebasing which can be a nightmare :) |
| 15:13:24 | ukleinek | 3bf6e08 merges in 5 which contains 3 |
| 15:14:20 | Torne | ukleinek: haha |
| 15:14:34 | Torne | Okay, ukleinek is confused because faux's images don't acctually reflect the same history :) |
| 15:14:38 | Torne | I hadn't checked |
| 15:15:12 | Torne | ukleinek: we are referring to the original, ugly sequence of commits in his first image, which is the same as what Lalufu's pastebin contains |
| 15:15:28 | Torne | Unfortunately yes, when recreating that history using different merging strategies he has gotten it wrong |
| 15:15:34 | Torne | and hasn't actually shown the same thing :( |
| 15:15:39 | Torne | I have never looked that closely before :) |
| 15:16:08 | Lalufu | Torne: so you want "git log −−topo-order"? |
| 15:16:24 | Torne | Lalufu: That's closer, but still not ideal |
| 15:16:30 | ukleinek | Torne: maybe it's just the first parent isn't always left?! /me checks |
| 15:16:46 | Torne | ukleinek: the first parent is not always the same *brnach*, in general |
| 15:16:48 | Torne | is why. |
| 15:17:01 | Torne | the first parent is only always the same branch if you enforce that you only merge to master :) |
| 15:17:20 | * | ukleinek rereads backlog while looking at the first blog image |
| 15:17:22 | Torne | without imposing restrictions on how people work there is no consistency between orders of parents |
| 15:17:27 | Torne | so −−first-parent is meaningless |
| 15:18:17 | | Quit wodz (Quit: Leaving) |
| 15:18:43 | Torne | Lalufu: −−topo-order is in the right order, but still filled with lots of noise |
| 15:18:50 | Lalufu | like the merge-commits? |
| 15:18:55 | ukleinek | yeah, so we can agree that 8 doesn't include 3 though it might have a later commit date |
| 15:19:03 | Torne | Lalufu: it includes uninteresting intermediate states of development |
| 15:19:12 | Torne | Lalufu: well, this example is too simple to show the noise. |
| 15:19:19 | Torne | in this example there is not any |
| 15:19:25 | | Quit TBCOOL (Quit: maintenance.) |
| 15:19:30 | Torne | All the merges in this example *are* significant, not noise |
| 15:19:37 | Torne | beause in this example they all represent places where master changed |
| 15:19:40 | Torne | and thus you can't ignore them |
| 15:19:49 | Lalufu | in this case the merge commits are emtpy |
| 15:19:52 | ukleinek | Torne: that works as long as users pick only commits from the branch everything is merged in |
| 15:19:53 | Torne | yes |
| 15:20:02 | Torne | However, in real development, every merge you do *from* master *to* your development branch is noise |
| 15:20:12 | Lalufu | why? |
| 15:20:13 | Torne | You need to do that, in order to catch yourself up |
| 15:20:19 | Torne | But nobody else needs to read it, in almost all cases |
| 15:20:25 | ukleinek | Torne: so don't do it then |
| 15:20:27 | Lalufu | if you merge back, the commits will not be duplicated |
| 15:20:35 | Torne | Lalufu: huh? |
| 15:20:38 | Torne | this isn't about duplication |
| 15:20:40 | Lalufu | ukleinek: you need to merge from the master from time to time |
| 15:20:44 | Torne | this is about the merge commit itself being noise |
| 15:21:03 | Torne | example: |
| 15:21:11 | Torne | 1) i make a development branch based on master |
| 15:21:13 | * | ukleinek laughs at Torne who wants to sell doing many more merge commits |
| 15:21:15 | Torne | 2) i write some commits |
| 15:21:24 | Torne | 3) i need to catch up from master, so i merge master into my branch |
| 15:21:30 | Torne | 4) i write some more commits |
| 15:21:42 | Torne | 5) i am done, i merge my branch back to master (by whatever method, doesn't matter) |
| 15:21:56 | ukleinek | if that is all a single series, don't catch up in the middle |
| 15:21:58 | Torne | Someone who now looks at the full commit log has *no reason to care* about the merge commit i made in 3 |
| 15:22:05 | ukleinek | if it's not, dont base 4 on top of 2 |
| 15:22:08 | Torne | it is useless noise. |
| 15:22:22 | Torne | ukleinek: you don't appear to understand how long lived feature branches work |
| 15:22:38 | Torne | ukleinek: I agree that generally it's nicer to avoid doing it |
| 15:22:43 | Torne | either by just not updating, or by rebasing instead of merging |
| 15:22:53 | *** | Saving seen data "./dancer.seen" |
| 15:22:56 | Torne | But if you have a development branch that is goingt o live a long time, and is going to conflict somewhat with changes on master |
| 15:22:59 | Torne | you have no choice. |
| 15:23:06 | Torne | Never catching up on something that's long lived is hopeless |
| 15:23:18 | Torne | and trying to rebase a complicated change against a moving target is very very awkward |
| 15:23:41 | Torne | since your earlier commits may no longer apply against the current master |
| 15:24:47 | ukleinek | Torne: just adapt at the end |
| 15:24:49 | Torne | ukleinek: the point of doing merge-to-master with nonfastforward is that when looking at history you can use −−first-parent almost all the time |
| 15:24:53 | Lalufu | And git is very helpful in managing these things. |
| 15:24:59 | Torne | which takes away *all* this intermediate state |
| 15:25:04 | Torne | and just hides it |
| 15:25:08 | Torne | ukleinek: Er |
| 15:25:18 | Torne | ukleinek: you mean flatten your entire development and apply as a single patch? :) |
| 15:25:22 | Torne | or what |
| 15:25:41 | ukleinek | no, do conflict resolution at merge time (well I admit that can be hard) |
| 15:25:51 | Torne | er |
| 15:25:57 | Torne | you don't appear to be talking about the same thing |
| 15:26:00 | ukleinek | but yeah, git merge −−squash is possible, too |
| 15:26:13 | Torne | you mean never catch up and just wait until the end, right? |
| 15:26:24 | Torne | that's useless if you *care about changes that are happening in master while you work on it * |
| 15:26:45 | Torne | cherrypicking changes from master is even worse :) |
| 15:26:53 | ukleinek | yeah |
| 15:27:32 | Torne | ukleinek: okay, so you have radically departing opinions on how to do this from just about everyone else :) |
| 15:27:41 | Torne | which is, yaknow, interesting and all |
| 15:27:53 | ukleinek | Torne: agreed |
| 15:28:10 | Torne | but it doesn't really help me reach a compromise that preserves the properties ia m interested in while not being a huge inconvenience for peopel who expect to be able to use git with normal branching and merging |
| 15:28:19 | Torne | I personally quite like flattening changes and rebasing in almost all cases |
| 15:28:26 | Torne | I do this most of the time for the git repos I work with :) |
| 15:28:41 | Torne | but it was very clear last time we discussed workflows that most people are not willing to do that |
| 15:28:46 | Torne | at least, not all the time |
| 15:30:18 | ukleinek | Torne: I think that if you want a pretty history (in the sense that your patches are small and self-contained, not about having or not having ugly merges) you have to rebase your private devel tree. |
| 15:30:36 | * | B4gder agrees with ukleinek |
| 15:31:31 | Torne | B4gder: this was my initial propsal :) |
| 15:31:39 | Torne | hence why the sandbox repo currently refuses pushing merges. |
| 15:32:02 | Torne | but virtually every existing git user here disagrees |
| 15:32:11 | B4gder | well, as I'm not that involved in the development these days I won't make things more complicated by voicing strong opinions on either approach |
| 15:32:45 | | Quit XavierGr () |
| 15:32:49 | Torne | ukleinek: Do you really not see that following the only-merges-on-master policy achieves the same ends as rebasing, though? |
| 15:33:40 | Torne | If you forbid merges entirely and require that everyone rebase and squash before committing, you get a history which is a linear sequence where each one is a single logical *change*, regardless of how it was originally developed |
| 15:34:06 | Torne | If you require that *all* commits to master are merges to master, you get, if you use −−first-parent, a history which is a linear sequence where each one is a single logical *change*, regardless of how it was originally developed :) |
| 15:34:13 | Torne | But the original history is still there if someone looks |
| 15:34:15 | ukleinek | Torne: I don't see the benefit at forcing that, imho Linux is just fine |
| 15:34:57 | Torne | forcing which? |
| 15:35:03 | ukleinek | but of course you need patch hygiene |
| 15:35:14 | ukleinek | Torne: that merge-to-main-branch thing |
| 15:35:22 | Torne | but aren't you arguing for the former? |
| 15:35:29 | Torne | which, as i'm trying to point out, achieves the same effect |
| 15:35:57 | ukleinek | Torne: I'm happy with the first image on http://blog.prelode.com/2011/04/history-cleanliness-in-git/ |
| 15:36:03 | Torne | ukleinek: er |
| 15:36:14 | Torne | then why are you now talking abotu rebasing and so on? |
| 15:36:33 | Torne | That situation woudl never arise if people rebased and did clean patches |
| 15:36:37 | ukleinek | Torne: and consider "2. Only merges on master" as artifical without real gain |
| 15:36:47 | Torne | you're not making any sense |
| 15:37:06 | Torne | you are arguing for things that produce one result, while saying another result is fine :) |
| 15:37:21 | ukleinek | Torne: because the "merge as needed" workflow only works nicely if your commits are at least halfway sane |
| 15:37:38 | * | pamaury naively suggests that it's not too late to chose another tool than git :) |
| 15:37:40 | ukleinek | so during developent of a series you might have to rebase |
| 15:38:19 | ukleinek | ... or accept a intermediate merge in the history |
| 15:39:18 | Torne | ukleinek: okay, that's clearer |
| 15:39:34 | ukleinek | if you have commits like "convert first arch", "convert 2nd arch", "oh, I broke arch3 when converting arch1, fixit" you don't want the "merge as needed" workflow |
| 15:39:38 | Torne | what you're saying if i understand correctly is that you expect people will mostly just rebase and keep stuff tidy |
| 15:39:50 | Torne | and they'll only put up with doing merges in awkward situations that aren't going to work otherwise |
| 15:39:55 | ukleinek | but actually you don't want these patches in the "always merge" workflow either |
| 15:39:57 | Torne | and thus history will be pretty much ok as is |
| 15:39:58 | Torne | right? |
| 15:40:39 | Torne | or am i still misinterpreting? |
| 15:40:49 | ukleinek | yeah, maybe replace "expect" by "require" |
| 15:41:19 | Torne | OK, sure, require int he sense that we complain at people if they don't |
| 15:41:21 | ukleinek | in fact, only merge clean stuff. If people did it with or without rebasing doesn't matter much |
| 15:41:25 | Torne | (since you can't *enforce* it) |
| 15:41:55 | Torne | OK, so the problem witht aht in my mind is that I don't think people *will* work like that willingly |
| 15:42:28 | Torne | when people started trying the sandbox and found they couldn't push merges they were very concerned that their workflow normally includs doing merges just whenever. |
| 15:43:08 | ukleinek | Torne: you can enforce it with the linux-workflow. That is, with a person having the integrator role who is only merging the good stuff |
| 15:43:11 | Torne | Even if we write such guidelines I don't think people will adhere to them |
| 15:43:27 | Torne | You can, yes |
| 15:43:30 | God_Eater | hahahaha |
| 15:43:32 | Torne | But *we* can't |
| 15:43:36 | Torne | We have no such person |
| 15:43:39 | God_Eater | no-one is stupid enough to volunteer for that role here |
| 15:43:42 | | Quit pamaury (Quit: Page closed) |
| 15:43:44 | Torne | Nobody would want tod o it |
| 15:43:48 | Torne | and even if they did many people would object |
| 15:44:02 | | Join dfkt|n [0] (~dfkt@unaffiliated/dfkt) |
| 15:44:02 | Torne | Now, see |
| 15:44:09 | | Join pamaury [0] (81680b01@rockbox/developer/pamaury) |
| 15:44:10 | Torne | One thing is that "gerrit" can, in theory, be this person :) |
| 15:44:24 | God_Eater | gerrit == Mr. Someone ;) |
| 15:44:30 | ukleinek | oh, but then you have to expect more social problems when switching to git |
| 15:44:39 | Torne | Entirely aside from the actual code review, the thing about gerrit is that when you submit by hitting the button in gerrit, *it* does the submit |
| 15:44:44 | Torne | and thus it is being a single integrator |
| 15:44:50 | Torne | ANd gerrit can do that in a variety of ways |
| 15:45:10 | Torne | depending how it's configured. |
| 15:45:18 | ukleinek | AFAICT git exposes much better what was done than svn and if you don't agree that A is the integrator you might want to critisize his commits, too |
| 15:45:49 | God_Eater | commits get criticised quite a lot here already :) |
| 15:45:59 | Torne | but, for that to actually be policy requires that people always go through gerrit and forbidding direct pushes |
| 15:46:05 | Torne | which currently doesn't seem to be approved-of |
| 15:46:24 | ukleinek | Torne: then only give the good commiters commit access :-) |
| 15:46:43 | Torne | ukleinek: ther eare two kinds of "good committers" here in your idea, though |
| 15:46:46 | God_Eater | that's what we do already |
| 15:46:48 | Torne | there are "people who write good code" |
| 15:47:01 | Torne | and there are "people who take care to ensure their git commit history is tidy and doesn't include lots of noise" |
| 15:47:08 | Torne | These are not necessarily all the same people :) |
| 15:47:29 | Torne | currently we only select based on the "good code" criteria :) |
| 15:48:22 | Torne | unless you do not care at all what history looks like, there is a difference between "I approve of the diff between master and some-guys-branch" and "i approve of merging some-guys-branch into master" |
| 15:48:28 | God_Eater | it may be that those two groups don't intersect at all |
| 15:48:33 | Torne | the former only requires that the code be sound |
| 15:48:48 | Torne | the latter also requires that people ahve fgollowed some kind of DVCS best-practise :) |
| 15:49:35 | Torne | we have never had to care about the latter before because there basically is no way to screw this up in svn |
| 15:49:43 | Torne | since you *have* to "rebase" before committing |
| 15:50:32 | ukleinek | Torne: the problem about not-so-nice-commits is that they break bisection |
| 15:50:37 | Torne | Yes, absolutely |
| 15:50:54 | Torne | But, I should note, having a policy of always merging to master solves that problem |
| 15:50:59 | ukleinek | Torne: and if your users can be educated to try bisection this is a big pro |
| 15:51:02 | Torne | since in that case there is a nice linear sequence for bisect to go through |
| 15:51:22 | Torne | :) |
| 15:51:45 | ukleinek | Torne: git bisect doesn't work with your always-merge history |
| 15:51:54 | Torne | yes it does |
| 15:54:07 | n1s | ukleinek: nothing prevents users from nisecting with svn but hardly any of them do |
| 15:54:28 | Torne | ukleinek: git rev-list −−bisect −−first-parent works perfectly in the always-merge history |
| 15:55:37 | | Part LinusN |
| 15:56:03 | Torne | ukleinek: anyway, this is not going anywhere |
| 15:56:11 | Torne | ukleinek: i really do like what you suggest, if that wasn't clear |
| 15:56:22 | Torne | I am strongly in favour of encouraging people to rebase and avoid merging where possible |
| 15:56:40 | Torne | since most of the time there is no particular reason to complicate stuff with merges and it's equally trivial to rebase |
| 15:57:14 | Torne | and that was one suggestion I had last time: forbidding merge commits to be uplaoded by default, but allowing people in a certain ACL group to do it |
| 15:57:24 | Torne | which might well be a group you can add yourself to, i.e. making it opt-in |
| 15:57:36 | ukleinek | Torne: I'm ok with stopping the discussion. (One reason is I have to leave now) |
| 15:57:37 | Torne | as long as you promise to try and Do The Right THing according to some guidelines |
| 15:57:49 | Torne | but, I am concerned that this is not going to get a lot of buy-in |
| 15:57:58 | Torne | and that people would actually just keep doing what they are used to |
| 15:58:16 | kugel | which is reasonable :) |
| 15:58:27 | Torne | so, i was suggesting this as an alternative that lets people work in a varity of ways but as long as they *submit* in a certain way, it still produces an intelligible result |
| 15:58:50 | Torne | er, by "this" i mean merging-to-master |
| 15:58:51 | | Quit webguest99 (Quit: CGI:IRC (EOF)) |
| 15:58:53 | kugel | I think we're too concerned with how the history looks like |
| 15:59:09 | Torne | kugel: i think you are not concerned enough with how the history looks like |
| 15:59:10 | Torne | :) |
| 15:59:19 | kugel | :) |
| 15:59:25 | Torne | especially for a project migrating from svn where many people are *not* familiar with git |
| 15:59:51 | Torne | it's already going to be tricky enough for many casual folks (e.g. users who compile their own builds) that the versionsa re not just numbers in sequence :p |
| 16:00 |
| 16:01:30 | Torne | kugel: at the end of the day i can live with whatever. if we hav the opt-in merge group thing, with just some simple guidelines like "have you considered rebasing, it might be nicer", that would be fine; i'm just exploring options before we actually start doing it :) |
| 16:03:44 | Torne | i do kinda want that basic level of protection, or some other process which avoids the problem in the first place, though, because people who are new to git are likely to make stuff kinda yucky otherwise |
| 16:03:59 | Torne | especially as the vast majority of git docs/tutorials barely mention, or actively advise against, rebasing your changes |
| 16:04:30 | | Join TBCOOL [0] (~tb@c-c63471d5.09-42-73746f22.cust.bredbandsbolaget.se) |
| 16:05:00 | Lalufu | Torne: would you want to discourage just merging from master, or also merging bewteen development branches? |
| 16:05:26 | Lalufu | For the work I do on IAP I use rather a handful of branches, and I merge quite freely between them |
| 16:05:45 | Torne | sure |
| 16:05:50 | Torne | that's not the part that matters |
| 16:05:54 | Torne | what matters is what you commit to master |
| 16:06:02 | Torne | not what you do in the process of getting there. |
| 16:06:14 | Torne | your development branches are all just private on your local machine, right? |
| 16:06:30 | Torne | or, generally, not public to the world in a way that encourages other people to pull them |
| 16:07:21 | Lalufu | I publish one of them, but that one is explicitly produced for publishing (by cherry-picking from other branches) |
| 16:07:29 | Torne | right |
| 16:07:56 | Torne | So, currently, because we use svn, to submit you would periodically produce one or more patches and commit them |
| 16:08:16 | Torne | you might just have one patch which is "implement this new stuff", or a series which you commit in order that make up logical steps |
| 16:08:23 | Torne | but you would not commit your own private intermediate development states |
| 16:08:43 | Torne | My preference is that you'd continue to work just like this with git |
| 16:09:00 | Lalufu | so you want one big patch, instead of lots of small ones? |
| 16:09:07 | Torne | Lot sof small ones is fine too |
| 16:09:15 | Torne | as long as they reflect actual interestnig seperate steps in the development of a feature |
| 16:09:22 | Torne | like patch serieses sent to LKML |
| 16:09:30 | Torne | where things are broken up to make them easier to review and understand |
| 16:09:47 | Torne | What I would prefer *not* to see is commits like "oops, changed my mind, removing this function again" |
| 16:09:50 | Torne | or similar :) |
| 16:10:10 | Torne | Whether you even commit that kind of thing to your development branch int he first place or not varies, of course; maybe you already take care to make your development branches hygenic |
| 16:10:16 | Torne | in which case it's very easy to submit them |
| 16:10:36 | Torne | does that make sense? |
| 16:10:44 | Lalufu | Depends. If it takes two weeks to realize that I don't need the function after all it's hard to remove that entirely from the history |
| 16:10:52 | Torne | Well, you say that |
| 16:11:03 | Torne | But if that's just one big thing you are working on anyway |
| 16:11:08 | Torne | then maybe you are going to flatten it anyway |
| 16:11:15 | Torne | at which point the intermediate state with the function existing goes away |
| 16:11:33 | Lalufu | right. |
| 16:11:42 | Torne | Flattening is always possible and always gets rid of all intermediate states, but sometimes *not* flattening is desirable for some reason |
| 16:11:53 | Torne | e.g. when a patch is large and complicated and woudl be hard to review or understand in one blob |
| 16:12:09 | Torne | but in that case you generally want to produce a patch series which reflects the *logical steps* in implementing the change |
| 16:12:15 | Torne | rather than the actual chronological steps you went through developing it. |
| 16:12:42 | | Join GermanMushroom [0] (~c@s5146db6a.adsl.wanadoo.nl) |
| 16:12:47 | Torne | So yeah. In workflows like Linus's this is basically enforced because there is no other way to get your code into the tree |
| 16:12:53 | Torne | You make a patch (series) and you email it |
| 16:12:58 | Torne | and someone merges it if they like it |
| 16:13:07 | Torne | If you make a big ugly mess they will tell you to go away |
| 16:13:36 | Torne | When everyone has permissiont o push to master, you can only really enforce this by peer pressure |
| 16:14:05 | Torne | and when people make mistakes it's generally too late to change you rmind since the branch is already published and built |
| 16:14:10 | Torne | and so revising history would be bad. |
| 16:14:20 | Torne | You can explain to them what they did wrong and ask them not to do it again, but.. yeah :) |
| 16:14:44 | * | Torne idles, tree is red :) |
| 16:15:17 | Lalufu | I think I'd continue to publish the cherry-picked branch, just so that people can see the history of the thing. |
| 16:15:43 | Lalufu | whether that is pulled as-is into master, or as a series of further condensed patches or not at all is a different matter |
| 16:15:43 | | Quit B4gder (Quit: Konversation terminated!) |
| 16:23:29 | Lalufu | My problem with the rebase approach is that it kills my current workflow |
| 16:23:58 | Lalufu | Or maybe not. |
| 16:24:04 | Lalufu | Currently I do this: |
| 16:24:19 | kugel | let's not force rebase. it's can be a pida |
| 16:24:21 | kugel | poita |
| 16:24:24 | kugel | pita! |
| 16:24:28 | Lalufu | - Clone the rockbox git tree |
| 16:24:34 | Lalufu | - Create a branch |
| 16:25:06 | Lalufu | - Work on that branch |
| 16:25:25 | Lalufu | (let's call the first branch A) |
| 16:25:42 | Lalufu | - create a second branch B from the same start point |
| 16:25:51 | Lalufu | - cherry-pick from A into B |
| 16:25:54 | Lalufu | - publish B |
| 16:26:50 | Lalufu | if I now rebase A I can throw away B, right? |
| 16:28:19 | kugel | yea |
| 16:29:15 | Lalufu | especially if there are merge conflicts |
| 16:30:54 | Torne | Okay, back :) |
| 16:31:03 | Torne | OK, so I hav a problem with your workflow in the first place, I think |
| 16:31:18 | Torne | I don't think it *is* a different matter of whether your published changes are pulled as-is or not |
| 16:31:28 | Torne | Eitehr the intermediate development state is useful or it isn't |
| 16:31:33 | Torne | If it's useful it should be merged into master |
| 16:31:40 | Torne | If it's not then you have no need to keep publishing it |
| 16:32:45 | Torne | I don't quite follow your example above with cherrypicking; it would help if you explained *why* you were doing those things, not just what you did |
| 16:32:46 | Lalufu | The things I put in the published tree are the things that I think are needed for the development of the feature at that point in time. |
| 16:32:57 | Lalufu | maybe, later, some of the changes will turn out to be wrong |
| 16:33:06 | Lalufu | but I cannot unpublish them then. |
| 16:33:10 | Torne | Yes you can |
| 16:33:14 | Torne | You can just throw them away. It's trivial. |
| 16:33:33 | Lalufu | rewriting history in a published tree? |
| 16:33:37 | Torne | No |
| 16:33:41 | Torne | You misundersatnd |
| 16:33:46 | Torne | Throw away, not rewrite |
| 16:33:56 | Torne | You developm the change, publishing as you go along if you want |
| 16:34:00 | Torne | You finish it up and it's ready to submit |
| 16:34:09 | Torne | You make that into a set of nice patches and submit them to master |
| 16:34:15 | Torne | You then just throw the development branch away entirely |
| 16:34:22 | Torne | you don't rewrite it |
| 16:34:27 | Lalufu | yes, that was the difference between "pulling from the tree" and "make larger patches" |
| 16:34:31 | Torne | It's merged, so there's no need for it to exist any more |
| 16:34:32 | * | kugel thinks Torne lives in a world where you think your development state is useful, but you see mistakes in later time |
| 16:34:50 | Torne | kugel: i don't understand what you mean |
| 16:35:17 | kugel | you say "if it's useful merge to master, if not don't even publish" |
| 16:35:46 | Torne | yes.. i generally don't think my develoipment state is useful |
| 16:36:02 | Torne | I work with patchsets, not branches |
| 16:36:11 | Torne | i write a change, flattened as a single commit,a nd publish it as a patch |
| 16:36:23 | Torne | when I revise that, i amend the commit and upload it as a new patch to replace the old one |
| 16:36:34 | Torne | if it's a complex change it might be a patch series, instead of one patch |
| 16:36:48 | kugel | but there's a third where you think it's useful but notice you made mistakes in earlier commits |
| 16:37:07 | Torne | i don't see what you mean |
| 16:37:31 | | Join ChickeNES [0] (~ChickeNES@rouxbicon.rh.uchicago.edu) |
| 16:38:06 | Torne | kugel: i wasn't really meaning to imply two choices there |
| 16:38:15 | Torne | i was trying to make the point that if it's useful, it's not really development state |
| 16:38:27 | Torne | if it's useful, commit it :) |
| 16:39:04 | kugel | sometimes changes are only useful in context of other, future changes |
| 16:39:46 | Torne | sure. |
| 16:39:48 | Torne | why is that a problem? |
| 16:40:29 | kugel | you don't push it immediately |
| 16:40:36 | Torne | nobody said you had to |
| 16:40:48 | Torne | when i say "commit" i mean "keep around as a commit you are going to push" |
| 16:40:51 | Torne | not "push it right now" |
| 16:42:39 | kugel | well, what I was originally suggesting is that you can publis in a development state, and notice in a later state that earler commits are flawed |
| 16:42:55 | kugel | publish because you want to provide an early prototype or something |
| 16:42:58 | Torne | Right |
| 16:43:02 | Torne | But that's irrelevant |
| 16:43:08 | Torne | see what i just suggested to lalufu |
| 16:43:14 | Torne | You can publish it all you like |
| 16:43:17 | Torne | people can play with it, etc |
| 16:43:32 | Torne | but you are not bound to committing what you published to master |
| 16:43:43 | Torne | you can commit it in a nicer form. |
| 16:44:05 | Torne | then simply abandon that development branch |
| 16:44:13 | Torne | it's committed, it's done with. |
| 16:45:07 | Torne | brb, chrome is broken :) |
| 16:46:15 | kugel | yes of course |
| 16:51:27 | --> | "ods 200" received from cgthayer (~chatzilla@184.235.1.118) |
| 16:54:06 | | Join antil33t| [0] (~antil33t@203-100-223-143.callplus.net.nz) |
| 16:54:40 | | Quit pamaury (Quit: Page closed) |
| 16:55:01 | | Quit antil33t (Ping timeout: 260 seconds) |
| 16:58:26 | | Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) |
| 16:58:58 | | Quit blind (Ping timeout: 252 seconds) |
| 17:00 |
| 17:00:01 | ukleinek | Lalufu: I have a script for that workflow |
| 17:00:45 | | Part Zagor |
| 17:00:55 | ukleinek | Lalufu: that is maintain a always-forward-branch master and a branch master-flat with a tidied history that has master^{tree} == master-flat^{tree} |
| 17:01:39 | ukleinek | master-flat is regularily rebased to get rid of merges and a nice history for upstreaming |
| 17:01:51 | Lalufu | I'd be interested in a look at that |
| 17:02:31 | ukleinek | Lalufu: It has some rough edges but works for me (TM) |
| 17:03:13 | ukleinek | Lalufu: I will check with my employer if I can give it out, as I wrote it during my day-job. (Usually he agrees) |
| 17:03:33 | Lalufu | OK, thanks |
| 17:08:24 | Torne | yah. there are lots of ways to achieve this kind of thing, with or without scripts, depending on the exact effect you want to have and how lazy you are :) |
| 17:08:38 | Torne | i am just not sure that people are universally willing to do this *at all* |
| 17:09:06 | Torne | since it has seemed in some discussions like people are looking forward to the git transition as meaning they no longer have to do that kind of thing for the benefit of svn :) |
| 17:12:26 | ukleinek | Torne: you can sell them to do $(git merge −−squash $topicbranch) (while being on master). The upside is no ugly history + the same effect as $(svn up; svn commit), only with the better merge support of git |
| 17:12:41 | Torne | ukleinek: You *can*, but there are people who actively *do not want to do that* |
| 17:12:51 | Torne | They are looking forward to the fact that they *don't* have to do that any more |
| 17:13:06 | Torne | since right now they basically do, becaus eof svn |
| 17:14:25 | ukleinek | Torne: but the commiter has to specify the endresult of master + $theirwork anyhow (using merge) and resolve eventual conflicts. The difference is only the result and that you have to do merge −−squash instead of merge |
| 17:14:42 | Torne | ukleinek: you appear not to be understanding what i say |
| 17:14:53 | Torne | it's not the *effort* of squashing/resolving conflicts/etc that peopl eobject to |
| 17:14:59 | Torne | they *want history to end up containing all that stuff* |
| 17:15:53 | ukleinek | ah, ok. IMHO that's only acceptable for sane intermediate steps |
| 17:16:12 | ukleinek | but MHO doesn't count much I guess |
| 17:17:46 | | Quit ChickeNES (Quit: Computer has gone to sleep.) |
| 17:22:56 | *** | Saving seen data "./dancer.seen" |
| 17:24:07 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
| 17:26:20 | | Join mamarley [0] (~quassel@Lee-08-199.rh.ncsu.edu) |
| 17:32:32 | Torne | ukleinek: Yeah, I dunno :) |
| 17:32:53 | Torne | ukleinek: anyway, that is why i am considering things like the always-merge-to-master trick, to try and please a larger set of people |
| 17:33:08 | Torne | I would proabbly prefer encouraging people to put slightly more work in to tidy their stuff up, though :) |
| 17:33:48 | | Quit dfkt|n (Ping timeout: 240 seconds) |
| 17:41:02 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
| 17:50:36 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
| 17:51:02 | | Join y4n [0] (y4n@unaffiliated/y4ndexx) |
| 17:51:35 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
| 17:54:02 | | Quit matze` (Remote host closed the connection) |
| 17:58:41 | | Join Topy44 [0] (~Topy44@f049034078.adsl.alicedsl.de) |
| 18:00 |
| 18:00:07 | | Quit petur (Quit: *plop*) |
| 18:04:02 | | Quit God_Eater (Quit: Page closed) |
| 18:06:16 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
| 18:06:21 | | Join Keripo [0] (~Keripo@SEAS418.wlan.seas.upenn.edu) |
| 18:06:29 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
| 18:16:01 | | Quit GermanMushroom (Ping timeout: 258 seconds) |
| 18:25:25 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 18:33:20 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
| 18:33:37 | | Join powell14ski_ [0] (~powell14s@c-174-51-194-6.hsd1.co.comcast.net) |
| 18:35:50 | | Join Jerom [0] (~jerome@2a02:8420:215:f000:f66d:4ff:fe45:790f) |
| 18:38:09 | | Join ChickeNES [0] (~ChickeNES@rouxbicon.rh.uchicago.edu) |
| 18:41:45 | | Quit ChickeNES (Read error: Connection reset by peer) |
| 18:41:52 | | Join ChickeNES [0] (~ChickeNES@rouxbicon.rh.uchicago.edu) |
| 18:54:02 | | Join Buschel [0] (~chatzilla@p54A3BA65.dip.t-dialin.net) |
| 18:56:37 | | Join blind [0] (~blind@c-71-235-61-84.hsd1.ct.comcast.net) |
| 18:57:00 | | Quit swilde (Remote host closed the connection) |
| 18:57:02 | | Quit ChickeNES (Quit: Computer has gone to sleep.) |
| 18:57:50 | | Quit Keripo (Quit: Leaving.) |
| 18:58:58 | | Quit Jerom (Quit: Leaving.) |
| 18:59:18 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 18:59:18 | | Quit bertrik (Changing host) |
| 18:59:18 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 19:00 |
| 19:03:47 | CIA-14 | New commit by buschel (r30615): Fix a 'set but not used' warning. |
| 19:05:49 | CIA-14 | r30615 build result: All green |
| 19:06:49 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
| 19:08:21 | | Join Strife89 [0] (~Strife89@207.144.201.128) |
| 19:09:54 | | Join domonoky [0] (~Domonoky@agsb-5d871971.pool.mediaWays.net) |
| 19:10:00 | | Quit domonoky (Changing host) |
| 19:10:00 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
| 19:11:17 | | Join GermanMushroom [0] (~c@s5146db6a.adsl.wanadoo.nl) |
| 19:17:54 | | Join TheLemonMan [0] (~LemonBoy@ppp-218-41.26-151.libero.it) |
| 19:22:17 | | Quit factor (Remote host closed the connection) |
| 19:22:57 | *** | Saving seen data "./dancer.seen" |
| 19:30:00 | | Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) |
| 19:30:01 | | Quit Bagder (Changing host) |
| 19:30:01 | | Join Bagder [241] (~daniel@rockbox/developer/bagder) |
| 19:37:23 | | Join dfkt|n [0] (~dfkt@chello062178002170.1.11.univie.teleweb.at) |
| 19:37:23 | | Quit dfkt|n (Changing host) |
| 19:37:23 | | Join dfkt|n [0] (~dfkt@unaffiliated/dfkt) |
| 19:45:21 | | Quit Buschel (Ping timeout: 260 seconds) |
| 19:50:59 | Zagor | how much would break if we replace all pixel coordinates with decipercent on raaa? |
| 19:52:23 | Zagor | font sizes are problematic. and bitmaps can obviously not be scaled at whim. what else? |
| 19:53:18 | kugel | themes or internally also |
| 19:53:19 | kugel | ? |
| 19:53:50 | Zagor | I'm thinking internally, so the skin engine doesn't have to know/care |
| 19:54:25 | kugel | I don't think that works |
| 19:54:47 | kugel | also why restrict to RaaA? |
| 19:55:03 | Zagor | details, please. why doesn't it work? |
| 19:55:29 | Zagor | raaa is the main problem because it has a zillion different screen sizes. other targets are much more static. |
| 19:55:47 | kugel | but two separate code bases? |
| 19:55:48 | Zagor | if it works for raaa, it might make sense on other targets too. I'm not ruling that out. |
| 19:56:08 | | Quit madskiny (Read error: Operation timed out) |
| 19:56:13 | Zagor | no, that's why I want it internally. basically android has a 1000x1000 framebuffer |
| 19:56:25 | Zagor | s/android/raaa/ |
| 19:56:25 | kugel | I doubt you can work with only (deci)percentage |
| 19:57:26 | Zagor | that's why I'm asking. enlighten me, please! |
| 19:58:01 | kugel | well, for example the things you mentioned (bitmaps) |
| 19:58:18 | Zagor | yes but those are resources and can be supplied in density-specific versions |
| 19:58:32 | Zagor | i.e. it's just a logistics issue |
| 19:58:52 | kugel | 1000x1000 ignores aspect ratio (landscape vs portrait) |
| 19:59:19 | Zagor | our problem isn't that we have different densities, it's that we have *many* small variations in screen size |
| 19:59:23 | kugel | I can't explain exactly why I'm doubtful, I just feel it's not going to work |
| 19:59:46 | Zagor | of course it ignores it, it's percent! |
| 20:00 |
| 20:00:04 | Zagor | a percent scaled UI could even rotate |
| 20:01:26 | | Join gbl08ma [0] (~gbl08ma@195-23-182-194.net.novis.pt) |
| 20:01:58 | kugel | the same layout on portrait and landscape? |
| 20:02:35 | Zagor | scaled to proportions |
| 20:02:52 | Zagor | it might not be terribly pretty though :-) |
| 20:03:21 | Zagor | things like a square area album art needs special consideration |
| 20:04:13 | Zagor | a square area *for* album art |
| 20:04:36 | Zagor | how is AA scaling done today? |
| 20:05:01 | kugel | on load, keeping aspect ratio |
| 20:07:38 | gevaerts | Something that might work is marking specific viewports as "stretchable", and making sure that the viewports left of it or below it use offsets relative to the "other end". That of course doesn't solve *all* problems (i.e. it doesn't do anything about the backdrop), and I'm sure some themes won't be able to work well with this |
| 20:09:20 | | Join Horscht [0] (~Horscht@p57B57A8E.dip.t-dialin.net) |
| 20:09:20 | | Quit Horscht (Changing host) |
| 20:09:20 | | Join Horscht [0] (~Horscht@xbmc/user/horscht) |
| 20:09:47 | Zagor | gevaerts: but we also need stretching within each viewport. button position, for example, have to be scaled to viewport size |
| 20:10:21 | kugel | I think percentage viewports for skins would solve most problems |
| 20:10:32 | Zagor | I don't |
| 20:11:19 | Zagor | it only solves the case of one tag per viewport |
| 20:11:26 | Zagor | basically, only the list |
| 20:12:13 | gevaerts | Zagor: that depends on what's in the viewport. Stretching an AA viewport is probably reasonably easy to do, and stretching "UI viewport" (i.e. the list) is rather trivial for most themes (although I have a theme where that wouldn't work...). |
| 20:13:54 | gevaerts | I'm not convinced that it's possible to scale our current approach in a general way |
| 20:14:29 | Zagor | neither am I :-) but I think it's an idea worth exploring |
| 20:15:33 | Zagor | gevaerts: can you think of a few things in particular that won't work? (other than what I listed) |
| 20:16:56 | gevaerts | Zagor: no, fonts and bitmaps are basically it I think. |
| 20:17:32 | Zagor | I think that's solvable by having low, mid and high-density versions |
| 20:17:44 | Zagor | that's the android way |
| 20:19:42 | gevaerts | That's doable for large differences. The main things I'm concerned about are the small differences like 480x800 vs 480x832 |
| 20:19:52 | gevaerts | a.k.a. the disappearing status bar |
| 20:20:20 | gevaerts | You can just scale the whole thing of course, but I'm afraid that will be ugly in at least some cases |
| 20:20:57 | Zagor | yes, the theme has to be designed with room for such scaling |
| 20:21:32 | Zagor | we can't do pixel counting designs on android |
| 20:22:04 | gevaerts | Maybe we should also consider moving to freetype on android so we get scalable fonts |
| 20:22:25 | gevaerts | Or native font rendering, presumably |
| 20:23:02 | Zagor | that's certainly possible. but I'm trying to limit the scope a bit here :) |
| 20:23:06 | gevaerts | And (*shudder*) native buttons and lists :) |
| 20:31:02 | | Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz) |
| 20:34:11 | | Quit antil33t| (Read error: Connection reset by peer) |
| 20:35:45 | | Quit dfkt|n () |
| 20:45:56 | | Quit mamarley (Remote host closed the connection) |
| 20:58:37 | | Quit gbl08ma (Quit: Saindo) |
| 20:59:39 | CIA-14 | New commit by bertrik (r30616): FS #12296 - latvian translation update by Mārtiņš Šimis |
| 21:00 |
| 21:01:12 | | Join matze` [0] (~pflaume@p5498A67E.dip.t-dialin.net) |
| 21:01:28 | CIA-14 | r30616 build result: All green |
| 21:02:32 | CIA-14 | New commit by zagor (r30617): Enable Android status bar. |
| 21:04:07 | CIA-14 | r30617 build result: All green |
| 21:05:06 | kugel | Zagor: not sure if that's a good idea |
| 21:05:16 | Zagor | oh, why not? |
| 21:05:24 | kugel | doesn't it overlap with cabbie? |
| 21:05:38 | Zagor | I'll fix that |
| 21:05:50 | kugel | okay :) |
| 21:08:38 | | Join Slappyhaze [0] (~philjones@94-192-140-122.zone6.bethere.co.uk) |
| 21:09:14 | | Join Mineo [0] (~wh@2001:638:904:ffca:4261:86ff:fe87:5544) |
| 21:09:34 | | Quit Strife89 (Ping timeout: 248 seconds) |
| 21:09:55 | Slappyhaze | hey, I posted a query in the forums and was pointed here. Is it ok? |
| 21:10:05 | Mineo | hi. I'm not sure if this is the right place to ask because I can't access the ircguidelines linked in the topic :p |
| 21:10:11 | | Quit GermanMushroom (Read error: Connection reset by peer) |
| 21:10:45 | Mineo | I'm having trouble accessing rockbox.org over ipv6. is that a common problem? |
| 21:11:22 | Slappyhaze | I have a link to my issue: http://forums.rockbox.org/index.php/topic,28927.0.html |
| 21:12:39 | Mineo | traceroute6 is showing huge round trip times on some se.portlane.net hops which are the hops directly before www.haxx.se |
| 21:19:06 | Zagor | Mineo: hmm, I don't think I have tested ipv6 since we changed server two weeks ago. are you not getting any response at all, or packet loss? |
| 21:21:39 | | Join GermanMushroom [0] (~c@s5146db6a.adsl.wanadoo.nl) |
| 21:22:52 | Mineo | sometimes I don't get any response at all (I had to kill rockboxdev.sh because it was trying to load a patch for over 2 minutes) or loading anything takes a really long time |
| 21:22:59 | *** | Saving seen data "./dancer.seen" |
| 21:25:02 | Zagor | weird. I have no problems reaching out to for example ipv6.google.com from the server, and curl -6 www.rockbox.org on the server works too. |
| 21:26:10 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 21:26:38 | Zagor | but http://ipv6-test.com shows a problem too. hmm. |
| 21:28:27 | Mineo | fwiw I can't access portlane.net either |
| 21:29:44 | Zagor | I'll report it to them |
| 21:29:56 | Zagor | thank you for the notice |
| 21:30:52 | Mineo | no problem |
| 21:31:02 | Mineo | (and thank you very much for rockbox :) ) |
| 21:31:50 | | Join ChickeNES [0] (~ChickeNES@rouxbicon.rh.uchicago.edu) |
| 21:36:41 | | Quit TheLemonMan (Quit: WeeChat 0.3.5) |
| 21:40:17 | | Quit simonlnu (Ping timeout: 255 seconds) |
| 21:44:00 | | Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) |
| 21:49:48 | Lalufu | What's the valid range of global_settings.volume? |
| 21:51:36 | wodz | Lalufu: depends on the hardware |
| 21:53:17 | Lalufu | Is there a generic way to set/query the volume between "mute" and "this is as loud as it gets"? |
| 21:53:41 | Lalufu | where does the GUI get the info from ? |
| 21:54:30 | wodz | from audiohw_settings[] |
| 21:54:45 | wodz | which is defined in codec driver file |
| 21:55:16 | wodz | for example rockbox-git/firmware/drivers/audio/wm8751.c |
| 21:55:30 | wodz | s/rockbox-git/rockbox/ |
| 21:57:41 | Lalufu | the generic interface for that is firmware/sound.c? |
| 21:58:28 | wodz | probably, I am not very familiar with code at higher level |
| 22:00 |
| 22:01:26 | | Quit benedikt93 (Quit: Bye ;)) |
| 22:04:44 | | Quit y4n (Quit: 6,000,000 ways to die — choose one.) |
| 22:04:52 | | Part blind |
| 22:08:49 | | Join knob [0] (~knob@87.112.154.1) |
| 22:09:03 | | Join Keripo [0] (~Keripo@165.123.49.217) |
| 22:10:19 | | Join Strife89 [0] (~Strife89@207.144.201.128) |
| 22:12:44 | | Quit matze` (Remote host closed the connection) |
| 22:15:35 | | Quit GermanMushroom (Quit: Ik ga weg) |
| 22:17:39 | | Quit Keripo (Ping timeout: 252 seconds) |
| 22:18:51 | | Join notlistening [0] (~tom@94-195-105-95.zone9.bethere.co.uk) |
| 22:19:16 | notlistening | Hi what did the commit today enabling the android status bar do? |
| 22:19:18 | ukleinek | wodz: I found a contact email address in the net, but the reply directed me to their web formular |
| 22:21:33 | Zagor | notlistening: it simply makes the android app no longer be full-screen, so the android status/notification bar still shows. like in most other apps. |
| 22:23:26 | n1s | yay, i finally managed to hack up tremor enough to not allocate all the memory for huge comment packets in the codec buffer |
| 22:23:46 | Zagor | n1s: nice! |
| 22:23:51 | n1s | not in a nice way at all but it seems to work for the one file with embedded aa i have |
| 22:24:15 | | Quit petur (Remote host closed the connection) |
| 22:27:58 | | Part knob |
| 22:30:06 | notlistening | Zagor, thanks |
| 22:33:23 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 22:42:57 | | Join factor [0] (~factor@74.197.205.204) |
| 22:46:55 | | Quit saratoga (Ping timeout: 252 seconds) |
| 22:47:00 | | Quit wodz (Quit: Leaving) |
| 23:00 |
| 23:03:43 | | Quit tjb0607 (Read error: Connection reset by peer) |
| 23:04:43 | | Join tjb0607 [0] (~quassel@208-100-128-206.bendbroadband.com) |
| 23:07:28 | | Join T44 [0] (~Topy44@g228173242.adsl.alicedsl.de) |
| 23:08:34 | | Part Zagor |
| 23:10:38 | | Quit Topy44 (Ping timeout: 248 seconds) |
| 23:13:44 | | Join Marcin_ [0] (~chatzilla@baq194.neoplus.adsl.tpnet.pl) |
| 23:18:15 | | Part Slappyhaze |
| 23:20:03 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 23:21:39 | | Join [Saint] [0] (~st.lasciv@203.184.50.187) |
| 23:23:03 | *** | Saving seen data "./dancer.seen" |
| 23:25:57 | | Join mamarley [0] (~quassel@Lee-08-199.rh.ncsu.edu) |
| 23:32:19 | | Quit n1s (Remote host closed the connection) |
| 23:36:29 | | Quit bluefoxx_ (Ping timeout: 252 seconds) |
| 23:49:52 | | Quit bertrik (Ping timeout: 255 seconds) |
| 23:51:57 | | Join hilbert [0] (~hilbert@adsl-89-217-42-135.adslplus.ch) |
| 23:58:35 | | Quit stripwax (Quit: http://miranda-im.org) |
icon identifies that the person is a core developer (has commit access).