From MAILER-DAEMON Thu Nov 02 08:40:36 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eAEnU-00085W-P4 for mharc-lmi@gnu.org; Thu, 02 Nov 2017 08:40:36 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41938) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAEnS-00085P-Bl for lmi@nongnu.org; Thu, 02 Nov 2017 08:40:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eAEnM-0007ed-ES for lmi@nongnu.org; Thu, 02 Nov 2017 08:40:34 -0400 Received: from sonic313-16.consmr.mail.bf2.yahoo.com ([74.6.133.126]:38548) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eAEnM-0007as-8I for lmi@nongnu.org; Thu, 02 Nov 2017 08:40:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1509626421; bh=QfRnk9ta3wyPU66Gu/tywlVqqEBJER1hxsFL3C+vTQM=; h=To:From:Subject:Date:From:Subject; b=RGZI6dAmatitf62lGIkjXmq/fZ7izCxxxkWySoJxH/3yzjY3sJaWMRp/ygYJr4li8g1dcPEv0fFJ1B5ejfNB+wGQ/PDBjTNUfVrAkwaEsTIwkjOJrJyLmbGVsAqbuRquQfBbGlcvB1gVRnJCTf1jgpYLoai45zS5Wj64JZQPbtY13tSIhwpUensas9I+6iB+9pD4LY1p68dWw5q4aI+M7hSxbR9euA1b6pHpRKkqgPDuKDn462kxeW1gP+QqPttfCayJovi0bBdbgj/aOt6dibyDgyTYEXL3DajE79h8nbTHqXC8YV2czqbkxnuVYU3wpJNcoF2ipL6LKLhg5AbDsw== X-YMail-OSG: s3expdYVM1kB.c3_2eMPlbfYuDQ9wYcLUDgXGX_o_6W0WMAIhoDtL6sGgMGt8U1 4CnPQPbs.Q.wz6Ns3c2e5rMDiovKkrjc_xTQf1xC0ghUS6PoN8KPy5FNfOrEwFoQRliRLd4JdlfQ v2q.ChBw0GUbMFL7WscXMimx4DAG6uIyyWnchAJLD037HxzqPjTDHo9A3YTF7HTyiEWQTAhrYDdL CiYflRqrpABD3o4gK.mQvid_rBuv2GMlIvz8ALSDOnQUSdksAFaqOn69oL5v5BRzU.VLXfG_8zHH zVruGxe2BaecVVUbsZ5.gTabDL1yBuXFHTQs8YQ1BFxCtXeILQE9iZIEow30BJqjkyazqIpBKNpR cJiL.Tn4bBiMfQZ3MjXa_Lcx_rksug4QNxGcjfeq.TVhIrvyT5uEInTp6qrXyam63197Eyyhq.ty wG7jV0y4Doc10bNGgt0TD_t01532f.SCg54wvJ0OsfkPlRR2cK260F0DAoHxhBcP7tjK2C8vBqEz Yz9d0qCYopsr6MGQhccmV2oFPzNnzLHSArKWu_b.vmf.ANSaLXReZFvo8vvpdu20- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Thu, 2 Nov 2017 12:40:21 +0000 Received: from [127.0.0.1] by smtp113.sbc.mail.bf1.yahoo.com with NNFMP; 02 Nov 2017 12:40:21 -0000 X-Yahoo-Newman-Id: 923600.57088.bm@smtp113.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: s3expdYVM1kB.c3_2eMPlbfYuDQ9wYcLUDgXGX_o_6W0WMA IhoDtL6sGgMGt8U14CnPQPbs.Q.wz6Ns3c2e5rMDiovKkrjc_xTQf1xC0ghU S6PoN8KPy5FNfOrEwFoQRliRLd4JdlfQv2q.ChBw0GUbMFL7WscXMimx4DAG 6uIyyWnchAJLD037HxzqPjTDHo9A3YTF7HTyiEWQTAhrYDdLCiYflRqrpABD 3o4gK.mQvid_rBuv2GMlIvz8ALSDOnQUSdksAFaqOn69oL5v5BRzU.VLXfG_ 8zHHzVruGxe2BaecVVUbsZ5.gTabDL1yBuXFHTQs8YQ1BFxCtXeILQE9iZIE ow30BJqjkyazqIpBKNpRcJiL.Tn4bBiMfQZ3MjXa_Lcx_rksug4QNxGcjfeq .TVhIrvyT5uEInTp6qrXyam63197Eyyhq.tywG7jV0y4Doc10bNGgt0TD_t0 1532f.SCg54wvJ0OsfkPlRR2cK260F0DAoHxhBcP7tjK2C8vBqEzYz9d0qCY opsr6MGQhccmV2oFPzNnzLHSArKWu_b.vmf.ANSaLXReZFvo8vvpdu20- X-Yahoo-SMTP: mjD.OBqswBAPbVUxYJaYPvc61jLEnpq8VnBwJGdbEJOPA9xw To: "Let me illustrate..." From: Greg Chicares Message-ID: <0980d2d0-8dc0-a9ad-89d7-b97b52a33bdb@sbcglobal.net> Date: Thu, 2 Nov 2017 12:40:19 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.6.133.126 Subject: [lmi] konsole clipboard stopped working (fixed) X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 12:40:35 -0000 [I've resolved this problem, but pose a question in the last paragraph.] Yesterday, copying from konsole to the clipboard stopped working. Nothing copied from konsole could be pasted anywhere: not into thunderbird, nor into vim (neither "+P or "*P), nor into konsole itself. One (only one) of my (many) konsole sessions said: QXcbClipboard: SelectionRequest too old QXcbClipboard::setMimeData: Cannot set X11 selection owner A web search for these error messages found many problem reports over several years, but the most plausible suggestion I saw was to reboot. (Reboot? Linux??) Instead of taking that advice, I closed every konsole session, then opened new ones. The problem disappeared. I guess this resolution is as good as can realistically be hoped for. I'm really glad I took the time to port and document the scripts in http://git.savannah.nongnu.org/cgit/lmi.git/tree/tabs that I had originally developed for cygwin, which set up the group of sessions I'm accustomed to. These scripts are clunky, but tiny and comprehensible, so I prefer them to tmux or gnu screen. There is one question I'd like to ask, though. My habit is to run schroot with identical parameters in each of approximately five terminal tabs. That seems to work perfectly well, but is it distasteful for some reason that I'm not perceiving? I have no wish to keep these sessions isolated from one another; actually, I want them to work together as though they were one single chroot. And they do work that way: I can edit files in one terminal tab and git-commit them in another. From MAILER-DAEMON Thu Nov 02 09:05:05 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eAFBA-0004W8-Vj for mharc-lmi@gnu.org; Thu, 02 Nov 2017 09:05:05 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47600) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAFB7-0004UA-BZ for lmi@nongnu.org; Thu, 02 Nov 2017 09:05:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eAFB1-0008Pt-CQ for lmi@nongnu.org; Thu, 02 Nov 2017 09:05:01 -0400 Received: from sunset.tt-solutions.com ([82.240.17.225]:59068 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eAFB1-0008LO-3K for lmi@nongnu.org; Thu, 02 Nov 2017 09:04:55 -0400 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eAFAt-00029S-UX for lmi@nongnu.org; Thu, 02 Nov 2017 14:04:48 +0100 Date: Thu, 2 Nov 2017 14:04:49 +0100 From: Vadim Zeitlin To: "Let me illustrate..." MIME-Version: 1.0 References: <0980d2d0-8dc0-a9ad-89d7-b97b52a33bdb@sbcglobal.net> In-Reply-To: <0980d2d0-8dc0-a9ad-89d7-b97b52a33bdb@sbcglobal.net> X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 82.240.17.225 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: [lmi] konsole clipboard stopped working (fixed) X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 13:05:02 -0000 On Thu, 2 Nov 2017 12:40:19 +0000 Greg Chicares wrote: GC> Yesterday, copying from konsole to the clipboard stopped working. GC> Nothing copied from konsole could be pasted anywhere: not into GC> thunderbird, nor into vim (neither "+P or "*P), nor into konsole GC> itself. One (only one) of my (many) konsole sessions said: GC> QXcbClipboard: SelectionRequest too old GC> QXcbClipboard::setMimeData: Cannot set X11 selection owner GC> A web search for these error messages found many problem reports GC> over several years, but the most plausible suggestion I saw was GC> to reboot. (Reboot? Linux??) This is indeed distasteful. GC> Instead of taking that advice, I closed every konsole session, GC> then opened new ones. The problem disappeared. I guess this GC> resolution is as good as can realistically be hoped for. If konsole were a wxWidgets program, I'd be worried that there is a resource leak in wxClipboard. It isn't, of course, and I don't care about Qt bugs nearly as much, but it does look like a QXcbClipboard bug... GC> I'm really glad I took the time to port and document the GC> scripts in GC> http://git.savannah.nongnu.org/cgit/lmi.git/tree/tabs I couldn't help looking at those scripts and I wonder about the use of "git remote update" at http://git.savannah.nongnu.org/cgit/lmi.git/tree/tabs/1/startup_script#n6 What is it for? And while I was writing this, I received the email about your commit 3df3e622be691da20f5a38dcd19700b0f62998f3 ("Synchronize more than one recent commit to local mirror") which addresses my other question. However I still question the use of HEAD~5 in the script, might you really want to use HEAD@{1}, i.e. the previous value of the HEAD pointer before it was changed by the subsequent command (git pull) instead? GC> These scripts are clunky, but tiny and comprehensible, so I prefer them GC> to tmux or gnu screen. FWIW screen is pretty similar, you just list the commands you'd like to execute in your ~/.screenrc and that's it. Of course, you can get fancier if needed, e.g. my own ~/.screenrc is split in host-independent and host-specific parts, but you don't have to do it like this. And it allows you to give specific numbers and titles to the different windows, which is not the case of your scripts AFAICS. BTW, I don't want to disparage tmux, it's supposed to be better than screen, it's just that I've never used it because I'm too used to screen. GC> There is one question I'd like to ask, though. My habit is to GC> run schroot with identical parameters in each of approximately GC> five terminal tabs. That seems to work perfectly well, but is GC> it distasteful for some reason that I'm not perceiving? No, I don't think so. There is no real overhead in using chroot, i.e. launching N chroot'ed processes shouldn't be materially different from launching N processes inside a chroot. I probably still would use a single chroot and just launch a screen inside it because I absolutely always use screen anyhow (if only not to lose my session in case of disconnection/closing the window/anything else short of reboot -- but this should never happen, of course, see above). And using a single screen inside a chroot just seems more logical as it ensures that all windows inside it have the same filesystem view while it could be possible to accidentally mix up chrooted and not-chrooted processes otherwise. But it's just a subjective preference, really, there is nothing wrong with doing it in the way you do. Regards, VZ From MAILER-DAEMON Thu Nov 02 11:44:15 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eAHfD-0007l4-7h for mharc-lmi@gnu.org; Thu, 02 Nov 2017 11:44:15 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58100) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAHf9-0007kn-UE for lmi@nongnu.org; Thu, 02 Nov 2017 11:44:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eAHf5-0000ou-ED for lmi@nongnu.org; Thu, 02 Nov 2017 11:44:11 -0400 Received: from sonic309-16.consmr.mail.bf2.yahoo.com ([74.6.129.126]:37693) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eAHf5-0000np-7S for lmi@nongnu.org; Thu, 02 Nov 2017 11:44:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1509637445; bh=tqZkMdSqHD81KVO2S1V8KJ3+yYAYRr5gnjzAAKr+6dA=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=YydMB2OL+6aTHi5Hh2qKBnHohhM88B4ySO+NSq9tt6TBhDBPCboqddkeYFeLFu0xGeW8+Js3Ycmh+/+6C7/ijcZkFjZ3x9TSf8SBXHV8Ont0eUuOlmM5geztPqflXaK2ccPbZA/TgB+TY6Xep5Nz6Obc8wZviRMkVKbAtkCEstFnk7dEMhisib4Em5AiFvyrl9Ldsfl0+dnOKdJIYcRYNbiAotNZ1suDW4mWD/a6NeEPgxAo7OG8Ffp7kPOU6+AofrmCb/4tWzQNv9HQLv7a76rNCfN3tA9/yIQJ0GC2po+mH3URxEJRaKfFDTznuqjSa0tl9u/reNZlF1ZeJYrgAQ== X-YMail-OSG: 7.172L0VM1kwl1KGBbfa40Jgy4h.X12F6IPSY_3bNXEjvrjMtnOGAT8ZF9nwYfg qoHOLdDBJM7MClQxXZBvIqN8UW73DiXthH4jl8lDXOxnkKeSfWYBvdjkMskUaweWeAW04zwMD.7g JlZSXWvxSqP40yzT9CzNpg.Fyowwahi3ZEf5R.tcnDd.INkIMWwTOJ8XEckRLmvAZcH6EoBXPt2s yXRXfTw8LKpcAUd3qZxtOam0Y7AmvcFotFjA8zIL5JJVm2KUOTsMRJVV6Clk4A88Mwtrcs9gpkrF L6LMNxNSgIWjw7Z_WLAaF3rNPf9rBDfaAISQwl_9MpiVuPSMbA4z27c9Q.YavTHqZiImB5plzD5N OHFxi.msv2Vxi2QZIu92U_EcDZSUDh3GOAb20rVSJri5sOAIZMkZgIXadBM6vvXXf37kl_q.HMAe DpGzi8hSJS.jmn8nIkgm0k0Kibm3twGPDKG3ifUY.Ot11jiEx4_vTsjSiHJSRCcaQpVLtux6XysB HmwnW36iAn8DpABaexiatN9AJYbDl8g6DzWmCdvwRf9fAT5d4rnOoMf2mmmmp5TI- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Thu, 2 Nov 2017 15:44:05 +0000 Received: from [127.0.0.1] by smtp111.sbc.mail.bf1.yahoo.com with NNFMP; 02 Nov 2017 15:44:04 -0000 X-Yahoo-Newman-Id: 71122.79319.bm@smtp111.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 7.172L0VM1kwl1KGBbfa40Jgy4h.X12F6IPSY_3bNXEjvrj MtnOGAT8ZF9nwYfgqoHOLdDBJM7MClQxXZBvIqN8UW73DiXthH4jl8lDXOxn kKeSfWYBvdjkMskUaweWeAW04zwMD.7gJlZSXWvxSqP40yzT9CzNpg.Fyoww ahi3ZEf5R.tcnDd.INkIMWwTOJ8XEckRLmvAZcH6EoBXPt2syXRXfTw8LKpc AUd3qZxtOam0Y7AmvcFotFjA8zIL5JJVm2KUOTsMRJVV6Clk4A88Mwtrcs9g pkrFL6LMNxNSgIWjw7Z_WLAaF3rNPf9rBDfaAISQwl_9MpiVuPSMbA4z27c9 Q.YavTHqZiImB5plzD5NOHFxi.msv2Vxi2QZIu92U_EcDZSUDh3GOAb20rVS Jri5sOAIZMkZgIXadBM6vvXXf37kl_q.HMAeDpGzi8hSJS.jmn8nIkgm0k0K ibm3twGPDKG3ifUY.Ot11jiEx4_vTsjSiHJSRCcaQpVLtux6XysBHmwnW36i An8DpABaexiatN9AJYbDl8g6DzWmCdvwRf9fAT5d4rnOoMf2mmmmp5TI- X-Yahoo-SMTP: mjD.OBqswBAPbVUxYJaYPvc61jLEnpq8VnBwJGdbEJOPA9xw To: "Let me illustrate..." References: <0980d2d0-8dc0-a9ad-89d7-b97b52a33bdb@sbcglobal.net> From: Greg Chicares Message-ID: Date: Thu, 2 Nov 2017 15:44:02 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.6.129.126 Subject: Re: [lmi] konsole clipboard stopped working (fixed) X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 15:44:13 -0000 On 2017-11-02 13:04, Vadim Zeitlin wrote: > On Thu, 2 Nov 2017 12:40:19 +0000 Greg Chicares wrote: [...] > GC> I'm really glad I took the time to port and document the > GC> scripts in > GC> http://git.savannah.nongnu.org/cgit/lmi.git/tree/tabs > > I couldn't help looking at those scripts I'm very glad to have your comments. > and I wonder about the use of > "git remote update" at > http://git.savannah.nongnu.org/cgit/lmi.git/tree/tabs/1/startup_script#n6 > What is it for? Here's the history: $git log --patch -G'remote' gwc/develop1.txt [...] -svn status --show-updates -svn update +git remote -v update +git pull Back in svn days, I ran svn status --show-updates unconditionally whenever I started up a group of terminal sessions (on average, once or twice a day with cygwin in an ever-crashing VM), because it was a relatively lightweight way to ascertain whether there were any savannah changes that had not yet been reflected in my local mirror. The 'svn update' command was run not at startup, but only on demand--partly because it's more resource-intensive, and partly because other people were changing the svn repository more often than is now the case and I wanted to keep their changes out of my local mirror until I had reviewed them. Those concerns are certainly less important nowadays, and perhaps completely irrelevant, but rather than rethink the commands, I just translated them. > And while I was writing this, I received the email about your commit > 3df3e622be691da20f5a38dcd19700b0f62998f3 ("Synchronize more than one recent > commit to local mirror") which addresses my other question. However I still > question the use of HEAD~5 in the script, might you really want to use > HEAD@{1}, i.e. the previous value of the HEAD pointer before it was changed > by the subsequent command (git pull) instead? I had no idea that any such syntax as 'HEAD@{1}' existed. But now, comparing 'git reflog' in my working copy vs. my mirror, I see that it does exactly what I want, so I'll update 3df3e62. Thanks. BTW, running 'touch' only on files that have actually changed did save a few noisy seconds when I was using a HDD, but with an SSD it doesn't matter much if I just touch everything: $time (for z in * ; do touch --reference=/opt/lmi/src/lmi/$z $z; done) ( for z in *; do; touch --reference=/opt/lmi/src/lmi/$z $z; done; ) \ 0.04s user 0.25s system 25% cpu 1.146 total Still, having written a selective, resource-saving command, it seems a sin not to use it, even though it probably saves less SSD wear than a single invocation of 'make install' causes. > GC> These scripts are clunky, but tiny and comprehensible, so I prefer them > GC> to tmux or gnu screen. > > FWIW screen is pretty similar Yet screen's HTML manual is 352Kb and it has https://savannah.gnu.org/bugs/?group=screen 237 open defects. Sure, screen and tmux would let me show multiple text windows, but I can comfortably see only 24x80 anyway, so I always work with a single maximized window anyway. > [...] And it allows > you to give specific numbers and titles to the different windows, which is > not the case of your scripts AFAICS. Actually, my tabs are named {ONE TWO THREE FOUR FIVE}, as set by the "title:" field on each line of 'tabs/konsole_tabs'. But since I'm working in this directory anyway, {Mirror Commit Build Misc Test} seem slightly more evocative...so I'll commit that change without testing because, hey, this is konsole, so what could go wrong? > GC> There is one question I'd like to ask, though. My habit is to > GC> run schroot with identical parameters in each of approximately > GC> five terminal tabs. That seems to work perfectly well, but is > GC> it distasteful for some reason that I'm not perceiving? > > No, I don't think so. There is no real overhead in using chroot, i.e. > launching N chroot'ed processes shouldn't be materially different from > launching N processes inside a chroot. Okay, thanks, that's good to know--I've been meaning to ask you about this for some time. > I probably still would use a single chroot and just launch a screen inside > it because I absolutely always use screen anyhow (if only not to lose my > session in case of disconnection/closing the window/anything else short of > reboot -- but this should never happen, of course, see above). My guess is that every 100th 'apt-get upgrade' requires restarting konsole, which is the worst terminal emulator except for every other. > And using a > single screen inside a chroot just seems more logical as it ensures that > all windows inside it have the same filesystem view while it could be > possible to accidentally mix up chrooted and not-chrooted processes > otherwise. I have one xfce workspace for host and one for chroot. And using 'konsole_tabs' to set up all chroots ensures that they all have the same filesystem view. Since I've settled on this setup, I don't even have to do 'ls -di /' anymore ('ischroot' being unreliable) to know where I am. Thanks for your comments. I knew I'd learn something useful. From MAILER-DAEMON Thu Nov 02 13:23:21 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eAJD7-00016j-TD for mharc-lmi@gnu.org; Thu, 02 Nov 2017 13:23:21 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55491) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAJD5-00016Y-Dn for lmi@nongnu.org; Thu, 02 Nov 2017 13:23:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eAJD1-0000mg-AK for lmi@nongnu.org; Thu, 02 Nov 2017 13:23:19 -0400 Received: from sunset.tt-solutions.com ([82.240.17.225]:33552 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eAJD0-0000lY-WF for lmi@nongnu.org; Thu, 02 Nov 2017 13:23:15 -0400 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eAJCx-0002Uk-7s for lmi@nongnu.org; Thu, 02 Nov 2017 18:23:11 +0100 Date: Thu, 2 Nov 2017 18:23:10 +0100 From: Vadim Zeitlin To: "Let me illustrate..." MIME-Version: 1.0 References: <0980d2d0-8dc0-a9ad-89d7-b97b52a33bdb@sbcglobal.net> In-Reply-To: X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 82.240.17.225 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: [lmi] konsole clipboard stopped working (fixed) X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 17:23:20 -0000 On Thu, 2 Nov 2017 15:44:02 +0000 Greg Chicares wrote: GC> On 2017-11-02 13:04, Vadim Zeitlin wrote: GC> > On Thu, 2 Nov 2017 12:40:19 +0000 Greg Chicares wrote: GC> [...] ... GC> > and I wonder about the use of GC> > "git remote update" at GC> > http://git.savannah.nongnu.org/cgit/lmi.git/tree/tabs/1/startup_script#n6 GC> > What is it for? GC> GC> Here's the history: GC> GC> $git log --patch -G'remote' gwc/develop1.txt GC> [...] GC> -svn status --show-updates GC> -svn update GC> +git remote -v update GC> +git pull GC> GC> Back in svn days, I ran GC> svn status --show-updates I don't remember what did this variant of "svn status" do exactly, but I'm almost sure that "git remote update" doesn't do the same thing as it doesn't actually show anything. Of course, it absolutely doesn't hurt to run it in any case, although personally I prefer "git fetch --all" (which is its exact synonym AFAICS) that I find more clear. GC> > And while I was writing this, I received the email about your commit GC> > 3df3e622be691da20f5a38dcd19700b0f62998f3 ("Synchronize more than one recent GC> > commit to local mirror") which addresses my other question. However I still GC> > question the use of HEAD~5 in the script, might you really want to use GC> > HEAD@{1}, i.e. the previous value of the HEAD pointer before it was changed GC> > by the subsequent command (git pull) instead? GC> GC> I had no idea that any such syntax as 'HEAD@{1}' existed. But now, GC> comparing 'git reflog' in my working copy vs. my mirror, I see that GC> it does exactly what I want, so I'll update 3df3e62. Thanks. You don't need to use reflog often, but when you do, it's surprisingly useful, especially for someone not as accurate with one's work organization as you (how did you know I was speaking from personal experience?). GC> > GC> These scripts are clunky, but tiny and comprehensible, so I prefer them GC> > GC> to tmux or gnu screen. GC> > GC> > FWIW screen is pretty similar GC> GC> Yet screen's HTML manual is 352Kb and it has GC> https://savannah.gnu.org/bugs/?group=screen GC> 237 open defects. Sure, screen and tmux would let me show multiple GC> text windows, but I can comfortably see only 24x80 anyway, so I GC> always work with a single maximized window anyway. While tmux can tile multiple windows, screen "windows" are actually always full screen. If screen were written today, instead of 30 (?) years ago, they would have been called "tabs". Also, comfortably switching windows from keyboard (without having to learn the different keyboard shortcuts provided by different terminal emulators, when they even bother to provide them) is just part of the fun. Copy and pasting text (inside or between windows) using just the keyboard is something I'd have real trouble living without, and I don't think common terminal emulators provide this. Screen is not as life-changing as the other members of my personal holy trinity (zsh, Vim, Git), but the combination of multiple windows, hangup survival and operations such as searching, copying and pasting from keyboard still makes it very, very useful. Regards, VZ From MAILER-DAEMON Fri Nov 03 08:57:17 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eAbXB-00061x-GY for mharc-lmi@gnu.org; Fri, 03 Nov 2017 08:57:17 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAbX8-00060a-P2 for lmi@nongnu.org; Fri, 03 Nov 2017 08:57:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eAbX4-0000NS-R2 for lmi@nongnu.org; Fri, 03 Nov 2017 08:57:14 -0400 Received: from sonic309-16.consmr.mail.bf2.yahoo.com ([74.6.129.126]:37921) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eAbX4-0000Mq-KN for lmi@nongnu.org; Fri, 03 Nov 2017 08:57:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1509713828; bh=9XLi4fXzQY1a+KbNSMgu2osCxm8F2fqBUn/Xs910wG0=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=qzAJHtp9ktP3J8vGTTeArXpXVEzETEM92jtDdLGfmvzpYHB26E81DNj8HjXuFg79ttwkVLP1UVifMF3D6hFAx/GBamWgVef6scP3GmOuNSyFACmAf8Y27zSNMYPk1NT33WRktL/ICzX48twkJrs7OZrUbNQWlUInOp2sJbF9MQH2COR1KEFJjIzz9RWVkMfSrdBKp0kKI0UsAJL+Ny1MmFOfhzt5XcCI3ulb6AjSEj4A4wwvJXR/R7bh6/jOSZfugGST7HXmO3QjNI5HrciosoDAIKY3RAtw47fbtdBk/hlnyCb/Kf+cCdhHGuE6kBy48TVCzyy6e3C17wO4UEZyFQ== X-YMail-OSG: Zh4fke8VM1m8uehhqNMjwypEe2I5xxemWDt.9zrXjmppG7KyNbMgX.JwK0Cw3KA OStE7AEbvXSUxMzVniEmGN1g2XA0k2zWiRZNlhbgLhxawrPVPu2dVkYFehaU4nt3fVMIeaLSrvdY Pr3PAVRTzrvRdfcmrikdd7jAdqyFyVRfv9Bzr3cWywoUs82ITIhdcgJQMncS6mTxPSr.sAcJt3y9 BJIAPl3jzLhoVmehnMr9ZaRcvajAYvds9uK5.0G3N0Z3bJWIIoqo7IuUSe7UGfKacRhKSMnnCj1n Dhbtov1.OT5GNSdSyS0otEfsAZGQ.5iVVksW_RrbKZNdhoLgXF37r14qHh_Sx6JxwkCl7Jg..HZX dCSyBCoo14UcURoYb8pPCYqa1TD6JxuOg5uZzwgEhgHEoxGYpVTIo78bABfvQYrVmt4YsxjK_gF0 2nestZneisjHve8my4bo.zcE1Tbvt8VTcxEA5LdEvTuzzhsxICOXMJohV.gccG3arOu2hduWhlm2 3OXXyc9pCea5Tmom0QcmJZgjZdlFxQAK_1Uk7nDDNM5ISF1UtRlce0f0rAKaqoAI- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Fri, 3 Nov 2017 12:57:08 +0000 Received: from [127.0.0.1] by smtp113.sbc.mail.bf1.yahoo.com with NNFMP; 03 Nov 2017 12:57:06 -0000 X-Yahoo-Newman-Id: 613727.89566.bm@smtp113.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Zh4fke8VM1m8uehhqNMjwypEe2I5xxemWDt.9zrXjmppG7K yNbMgX.JwK0Cw3KAOStE7AEbvXSUxMzVniEmGN1g2XA0k2zWiRZNlhbgLhxa wrPVPu2dVkYFehaU4nt3fVMIeaLSrvdYPr3PAVRTzrvRdfcmrikdd7jAdqyF yVRfv9Bzr3cWywoUs82ITIhdcgJQMncS6mTxPSr.sAcJt3y9BJIAPl3jzLho VmehnMr9ZaRcvajAYvds9uK5.0G3N0Z3bJWIIoqo7IuUSe7UGfKacRhKSMnn Cj1nDhbtov1.OT5GNSdSyS0otEfsAZGQ.5iVVksW_RrbKZNdhoLgXF37r14q Hh_Sx6JxwkCl7Jg..HZXdCSyBCoo14UcURoYb8pPCYqa1TD6JxuOg5uZzwgE hgHEoxGYpVTIo78bABfvQYrVmt4YsxjK_gF02nestZneisjHve8my4bo.zcE 1Tbvt8VTcxEA5LdEvTuzzhsxICOXMJohV.gccG3arOu2hduWhlm23OXXyc9p Cea5Tmom0QcmJZgjZdlFxQAK_1Uk7nDDNM5ISF1UtRlce0f0rAKaqoAI- X-Yahoo-SMTP: mjD.OBqswBAPbVUxYJaYPvc61jLEnpq8VnBwJGdbEJOPA9xw To: "Let me illustrate..." References: <0980d2d0-8dc0-a9ad-89d7-b97b52a33bdb@sbcglobal.net> From: Greg Chicares Message-ID: <44c70f0f-3fe9-4e15-58b9-b7657922e3d1@sbcglobal.net> Date: Fri, 3 Nov 2017 12:57:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.6.129.126 Subject: Re: [lmi] konsole clipboard stopped working (fixed) X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 12:57:16 -0000 On 2017-11-02 17:23, Vadim Zeitlin wrote: > On Thu, 2 Nov 2017 15:44:02 +0000 Greg Chicares wrote: [...] > GC> -svn status --show-updates > GC> -svn update > GC> +git remote -v update > GC> +git pull > GC> > GC> Back in svn days, I ran > GC> svn status --show-updates > > I don't remember what did this variant of "svn status" do exactly, but I'm It indicates whether or not the local working copy and the server are synchronized. http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.status.html | Print the status of working copy files and directories. With no | arguments, it prints only locally modified items (no repository | access). With --show-updates (-u), it adds working revision and | server out-of-date information. > almost sure that "git remote update" doesn't do the same thing as it > doesn't actually show anything. Let's test it. Before running 'git pull' to synchronize my local mirror to savannah master, it says: /opt/lmi/free/src/lmi[0]$git remote -v update Fetching origin Looking up git.savannah.nongnu.org ... done. Connecting to git.savannah.nongnu.org (port 9418) ... 208.118.235.201 done. remote: Counting objects: 11, done. remote: Compressing objects: 100% (10/10), done. remote: Total 11 (delta 8), reused 0 (delta 0) Unpacking objects: 100% (11/11), done. >From git://git.savannah.nongnu.org/lmi 3df3e622..ff7a3f5b master -> origin/master Running it again immediately produces different output: /opt/lmi/free/src/lmi[0]$git remote -v update Fetching origin Looking up git.savannah.nongnu.org ... done. Connecting to git.savannah.nongnu.org (port 9418) ... 208.118.235.201 done. >From git://git.savannah.nongnu.org/lmi = [up to date] master -> origin/master ....which isn't exactly what I wanted (or what I believe the svn command did). I want a const accessor that inquires whether git-pull would change anything, but without actually changing anything yet. > Of course, it absolutely doesn't hurt to > run it in any case, although personally I prefer "git fetch --all" (which > is its exact synonym AFAICS) that I find more clear. I'm guessing that what I really want is git fetch --all --dry-run but of course that does nothing at the moment because of the mutating command I had just run above. However, I've made a local branch and haven't yet pushed it to savannah, so let me push it now (with immense trepidation stemming from years of using svn, where mistakes cannot be undone without privileged access to the central server): /opt/lmi/src/lmi[0]$git push origin gwc-no-xslfo Enter passphrase for key '/home/greg/.ssh/id_rsa': Total 0 (delta 0), reused 0 (delta 0) remote: Sending notification emails to: lmi-commits@nongnu.org To git.sv.gnu.org:/srv/git/lmi.git * [new branch] gwc-no-xslfo -> gwc-no-xslfo And now (switching from my working copy to my mirror directory, as the $PROMPT indicates): /opt/lmi/free/src/lmi[0]$git fetch --all --dry-run Fetching origin >From git://git.savannah.nongnu.org/lmi * [new branch] gwc-no-xslfo -> origin/gwc-no-xslfo The moment of truth: is that inspection command reentrant? /opt/lmi/free/src/lmi[0]$git fetch --all --dry-run Fetching origin >From git://git.savannah.nongnu.org/lmi * [new branch] gwc-no-xslfo -> origin/gwc-no-xslfo Yes, it is, so that's the command I want. Now, when I git-pull, I get the 3df..ff7 changes that 'git remote update' had indicated: /opt/lmi/free/src/lmi[0]$git pull >From git://git.savannah.nongnu.org/lmi * [new branch] gwc-no-xslfo -> origin/gwc-no-xslfo Updating 3df3e622..ff7a3f5b Fast-forward gwc/develop1.txt | 5 ++--- tabs/1/startup_script | 2 +- tabs/konsole_tabs | 10 +++++----- 3 files changed, 8 insertions(+), 9 deletions(-) And now I want to confirm that treating the repository as linear still works--e.g., that if Kim uses only 'git pull', she won't get my branch if she doesn't ask for it: /opt/lmi/free/src/lmi[0]$git branch * master Looks good: my branch is available, but not pulled by default; whereas, in my working copy, I see the branches I want: /opt/lmi/src/lmi[0]$git branch gwc-no-xslfo * master vz-no-xslfo From MAILER-DAEMON Fri Nov 03 09:53:26 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eAcPW-00049f-M9 for mharc-lmi@gnu.org; Fri, 03 Nov 2017 09:53:26 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40401) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAcPU-00048j-U3 for lmi@nongnu.org; Fri, 03 Nov 2017 09:53:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eAcPR-0004c2-RT for lmi@nongnu.org; Fri, 03 Nov 2017 09:53:24 -0400 Received: from sonic313-16.consmr.mail.bf2.yahoo.com ([74.6.133.126]:41932) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eAcPR-0004bO-Kk for lmi@nongnu.org; Fri, 03 Nov 2017 09:53:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1509717200; bh=Gj3exuBLp9XJ3vzCq1VtAeBKGVo3O4zX+9P1wf2lTrA=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=CPo8DOrukiUq/LnDoT9qewi3bSIzjyqDyHoeznwC9Bxp98If6eyBnD+++TJ2Zbgdgq3vIaF2lTjnUEmdaF/A62OHSedOuGLPwYk6z8gC/5d4NjGHqD9ufVaybqmEr6Ik5stBSP9suoWTD7qFeXdPD70E4BaWABNubDOrmkiQOiVObenp48dvogx2Kahoin8O1PqXJL/Tvg/0dpxEp/3JK3SyzQK/Wn5d8MHYexGNEq4eEv5ieXh9L3UEPkqbovVMc5w9HvWHeU7fB7+4/gvrPymi4/d3iGgqTpbtYWZWa8t5OjateCHMx5luY1SLtJ8z26ND3+waH1vARJ/CEwtRXA== X-YMail-OSG: kbAmpzcVM1k2MU_AqpqFJIKCEkfyqtquio6tc6Isr_W39jSvsowM7AD53o0X2zY NoAaqEarBTEaK7rUYjqCW0Crq6ImycInk1WJ6T1iIgd2kz6bc5QzkaOubJvsIFi8sLzUDRMVYeaF xQrGK010p6VGWys4f.LOeEqaR5kpyb.ijyyP7U_v.l6bn3cB6FbtAYs260q0Pu3tEBLJlmvuNIBn Op6jdiV5AeWzEtn9N6lzgfyKrtEASu8FtLtsSVW3XepludvuTlUqjNVI_CHpZ0rSsjQNYI4FSACP m1A4OGc55.AJ49KrR.em2h6K43wu60ZWjYk52PcqiXrI86L9I07hH8hlzibAnEoRr89Axp_wrTTn jUApETMGwxq8wxTnAdY951NdV8DRA3E.XKrJy.OcuxvBJtqBJbsu.wgzQDJUa2Q9L2_i5fQyrCpN o_P3SL31v6WYy7Asi5eepPhV474RTf1ZMwyrEgum5jtVE5FgG6NKFd_yBEwchPUhteC0255kx26O iZCzfsgfKrC47U7lsUDEWDvSLyVNv94EFc842wFbBxnsq7l935rwCzhgZtMN6bfk- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Fri, 3 Nov 2017 13:53:20 +0000 Received: from [127.0.0.1] by smtp116.sbc.mail.bf1.yahoo.com with NNFMP; 03 Nov 2017 13:53:16 -0000 X-Yahoo-Newman-Id: 72340.70006.bm@smtp116.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: kbAmpzcVM1k2MU_AqpqFJIKCEkfyqtquio6tc6Isr_W39jS vsowM7AD53o0X2zYNoAaqEarBTEaK7rUYjqCW0Crq6ImycInk1WJ6T1iIgd2 kz6bc5QzkaOubJvsIFi8sLzUDRMVYeaFxQrGK010p6VGWys4f.LOeEqaR5kp yb.ijyyP7U_v.l6bn3cB6FbtAYs260q0Pu3tEBLJlmvuNIBnOp6jdiV5AeWz Etn9N6lzgfyKrtEASu8FtLtsSVW3XepludvuTlUqjNVI_CHpZ0rSsjQNYI4F SACPm1A4OGc55.AJ49KrR.em2h6K43wu60ZWjYk52PcqiXrI86L9I07hH8hl zibAnEoRr89Axp_wrTTnjUApETMGwxq8wxTnAdY951NdV8DRA3E.XKrJy.Oc uxvBJtqBJbsu.wgzQDJUa2Q9L2_i5fQyrCpNo_P3SL31v6WYy7Asi5eepPhV 474RTf1ZMwyrEgum5jtVE5FgG6NKFd_yBEwchPUhteC0255kx26OiZCzfsgf KrC47U7lsUDEWDvSLyVNv94EFc842wFbBxnsq7l935rwCzhgZtMN6bfk- X-Yahoo-SMTP: mjD.OBqswBAPbVUxYJaYPvc61jLEnpq8VnBwJGdbEJOPA9xw To: "Let me illustrate..." References: <007fcaa4-cb05-542b-6222-d1df245957f2@sbcglobal.net> <16996b95-ac64-0531-7bcc-d3284ee87a3e@sbcglobal.net> From: Greg Chicares Message-ID: <68921510-79e9-1a6c-1c79-2055fac5f3d5@sbcglobal.net> Date: Fri, 3 Nov 2017 13:53:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.6.133.126 Subject: Re: [lmi] Branching to replace XSL-FO X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 13:53:26 -0000 On 2017-10-28 00:56, Vadim Zeitlin wrote: > On Sat, 28 Oct 2017 00:27:32 +0000 Greg Chicares wrote: > > just do, when you're on your branch: > > $ git checkout vz-no-xslfo '*.mst' > $ git commit -m 'Create template files' [...] > GC> I can check out your branch: > GC> git checkout vz-no-xslfo AFAICT, git-checkout does starkly different things in different contexts: $git checkout gwc-no-xslfo This switches from one branch to another, without changing any contents. $git checkout vz-no-xslfo '*.mst' This takes some files from the named branch and puts them in the current branch, without switching branches. There are two concepts here that are utterly distinct in my mind: (1) switching among branches--i.e., just moving the asterisk here: $git branch gwc-no-xslfo * master vz-no-xslfo (2) copying files across branches and it pains me terribly to think that a single command serves both purposes depending on whether or not I add an extra argument. Please tell me I'm worrying over nothing. Maybe this make sense if we think of git-checkout as fundamentally meaning "change the working copy": (a) git checkout X.txt Replace working copy of named file with last commit. (b) git checkout X.branch Replace entire working copy with the set of files a branch contains. (c) git checkout X.branch X.txt Replace working copy of named file with the version last committed on named branch. Apparently it has multiple meanings, by deliberate design... https://git-scm.com/docs/git-checkout "Switch branches or restore working tree files" ....and, as with C++'s 'static' keyword, we must simply accept a conflation of orthogonal concepts. From MAILER-DAEMON Fri Nov 03 09:59:47 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eAcVf-0005HH-R9 for mharc-lmi@gnu.org; Fri, 03 Nov 2017 09:59:47 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42165) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAcVd-0005Gf-0a for lmi@nongnu.org; Fri, 03 Nov 2017 09:59:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eAcVZ-0000rb-0k for lmi@nongnu.org; Fri, 03 Nov 2017 09:59:45 -0400 Received: from sunset.tt-solutions.com ([82.240.17.225]:45278 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eAcVY-0000qK-N5 for lmi@nongnu.org; Fri, 03 Nov 2017 09:59:40 -0400 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eAcVV-00060c-RX for lmi@nongnu.org; Fri, 03 Nov 2017 14:59:37 +0100 Date: Fri, 3 Nov 2017 14:59:37 +0100 From: Vadim Zeitlin To: "Let me illustrate..." MIME-Version: 1.0 References: <0980d2d0-8dc0-a9ad-89d7-b97b52a33bdb@sbcglobal.net> <44c70f0f-3fe9-4e15-58b9-b7657922e3d1@sbcglobal.net> In-Reply-To: <44c70f0f-3fe9-4e15-58b9-b7657922e3d1@sbcglobal.net> X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 82.240.17.225 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: [lmi] konsole clipboard stopped working (fixed) X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 13:59:47 -0000 On Fri, 3 Nov 2017 12:57:04 +0000 Greg Chicares wrote: GC> On 2017-11-02 17:23, Vadim Zeitlin wrote: [...] GC> > Of course, it absolutely doesn't hurt to run it in any case, although GC> > personally I prefer "git fetch --all" (which is its exact synonym GC> > AFAICS) that I find more clear. GC> GC> I'm guessing that what I really want is GC> git fetch --all --dry-run ... GC> Yes, it is, so that's the command I want. Well, yes and no. "Yes" in the sense that it does work in the way you want, but it's inefficient and requires completely unnecessary multiple trips to the server. So I would still recommend omitting the "--dry-run" part. "git fetch" doesn't modify the working tree (or index) in any way, so while it's "mutating", strictly speaking, it only mutates Git internal storage and this shouldn't, and doesn't, matter in any way to you. You also shouldn't rely on the (purely informative) messages from git fetch, if only because they're not idempotent, but compare your branch directly with its remote counterpart to get the real state of things. I.e. the right commands to check the state of the local branch are $ git fetch # --all if you want but you typically only need one # This assumes you're on the local branch already $ git log ..remote/branch ... or ... $ git diff remote/branch ... or ... $ git diff --stat remote/branch and so on. Notice that the "..remote/branch" is the same as "HEAD..remote/branch" which is (by assumption above) the same as "branch..remote/branch" and means "all the commits in remote/branch but not in the local branch", i.e. all the new commits. If you want to view all the commits done in your branch but not pushed to the remote yet, you would reverse the order and use "remote/branch..". And if you wanted to view all commits not present in both branches, i.e. the union of these two commands output, you could use "remote/branch..." or "...remote/branch" -- the order here doesn't matter as "..." is symmetric. Personally I prefer to avoid "..." however and just run 2 separate commands instead as I find it more clear. [Purely theoretic digression] You may notice that there is an inevitable race condition here: someone could change the remote branch between your execution of "git fetch" and "git log-or-diff" and you won't know it until you tried to "git push" your branch which would then be refused by server as being out of date. And you would need to redo "git fetch" then, merge or rebase your changes and push again and hope the remote branch hasn't changed in the meanwhile. This is indeed a problem for some very busy repositories with hundreds or even thousands of contributors, but it has, of course, no chances of happening with lmi, so I'll just ignore this possibility. [End of digression] And if you want to update your local branch to be the same as the remote branch, you don't need to run "git pull" as it would do "git fetch" again which is unnecessary because you've just done it. Instead, you can do $ git merge --ff-only remote/branch to advance your branch pointer to point to the last commit in the remote branch if you don't have any local commits not present remotely. If you do have them, and the remote branch also has some commits that you don't have, it means that your branches have diverged. There is nothing tragic in this, but it does mean that you have the choice between doing a real merge or just rebasing your changes on top of those done remotely. Usually, for one (or few unrelated) commits you would prefer to rebase to keep the (branch) history linear while more involved sets of changes would merit having their own (sub-)branch and be merged at the end. But we can speak more about this when/if you run into such situation, which normally shouldn't happen any time soon. Regards, VZ From MAILER-DAEMON Fri Nov 03 10:13:56 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eAcjM-0000Fv-BC for mharc-lmi@gnu.org; Fri, 03 Nov 2017 10:13:56 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44766) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAcjJ-0000Es-W1 for lmi@nongnu.org; Fri, 03 Nov 2017 10:13:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eAcjF-0003Cc-0v for lmi@nongnu.org; Fri, 03 Nov 2017 10:13:53 -0400 Received: from sunset.tt-solutions.com ([82.240.17.225]:45474 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eAcjE-0003A3-O5 for lmi@nongnu.org; Fri, 03 Nov 2017 10:13:48 -0400 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eAcjA-0006UL-UB for lmi@nongnu.org; Fri, 03 Nov 2017 15:13:45 +0100 Date: Fri, 3 Nov 2017 15:13:44 +0100 From: Vadim Zeitlin To: "Let me illustrate..." MIME-Version: 1.0 References: <007fcaa4-cb05-542b-6222-d1df245957f2@sbcglobal.net><16996b95-ac64-0531-7bcc-d3284ee87a3e@sbcglobal.net> <68921510-79e9-1a6c-1c79-2055fac5f3d5@sbcglobal.net> In-Reply-To: <68921510-79e9-1a6c-1c79-2055fac5f3d5@sbcglobal.net> X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 82.240.17.225 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: [lmi] Branching to replace XSL-FO X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 14:13:55 -0000 On Fri, 3 Nov 2017 13:53:14 +0000 Greg Chicares wrote: GC> On 2017-10-28 00:56, Vadim Zeitlin wrote: GC> > On Sat, 28 Oct 2017 00:27:32 +0000 Greg Chicares wrote: GC> > GC> > just do, when you're on your branch: GC> > GC> > $ git checkout vz-no-xslfo '*.mst' GC> > $ git commit -m 'Create template files' GC> [...] GC> > GC> I can check out your branch: GC> > GC> git checkout vz-no-xslfo GC> GC> AFAICT, git-checkout does starkly different things in different contexts: Yes. This is one of the most confusing git commands and a poster child of Git poor UI. GC> $git checkout gwc-no-xslfo GC> This switches from one branch to another, without changing any contents. GC> GC> $git checkout vz-no-xslfo '*.mst' GC> This takes some files from the named branch and puts them in the current GC> branch, without switching branches. GC> GC> There are two concepts here that are utterly distinct in my mind: I could try to justify why are they not so different from the implementation point of view, but why bother when you're obviously right and they should clearly have been different commands. GC> Maybe this make sense if we think of git-checkout as fundamentally GC> meaning "change the working copy": GC> GC> (a) git checkout X.txt GC> Replace working copy of named file with last commit. GC> GC> (b) git checkout X.branch GC> Replace entire working copy with the set of files a branch contains. GC> GC> (c) git checkout X.branch X.txt GC> Replace working copy of named file with the version last committed on GC> named branch. I think this explanation is not quite right. Switching branches in git consists in 2 steps: 1. Update the working tree with the contents of the (tree associated to the) commit corresponding to the new branch pointer. 2. Update HEAD to point to the new branch. Now you can kind of imagine, if you squint a little, that if you want to update only some parts of the working tree, e.g. only "*.mst" files, then you can still do (1), limited to these files only, but you can't really do (2) because then you'd end up in a state where all the _other_ files would be modified (compared to the branch you would now be on, as they were not updated) while the files you specified on the command line would be (the only ones) unchanged. As this doesn't make any sense at all, Git does the next best thing: after partially doing (1), it doesn't do (2) at all. So you end up with just the files you specified being updated, but HEAD is unchanged. As I wrote above, it kind of makes sense from the implementation point of view, but it doesn't justify this leaking into the interface level, of course. GC> Apparently it has multiple meanings, by deliberate design... I'm not sure if you can really call it "design", I think in the early days of Git things mostly "just happened". But I wasn't there, so I don't know how did it really happen. GC> https://git-scm.com/docs/git-checkout GC> "Switch branches or restore working tree files" The second part probably refers to using "git checkout -- filespec" to revert the changes in the working copy by checking out the file from the index. I.e. this description doesn't even cover what we're discussing here. GC> ....and, as with C++'s 'static' keyword, we must simply accept a GC> conflation of orthogonal concepts. I'm afraid we must indeed. Some other Git UI was improved, even at the price of incompatible changes sometimes, but "git checkout" is such an often used command, that I'm almost sure it's never going to change now. I hesitate to mention it, but you may easily create your own aliases for it, e.g. you could use "git switch " for changing branches and "checkout" for everything else. Or on the contrary use "git get-file " and "git checkout" for switching branches. But I think that in the long term it's easier to just get used to this command behaviour, illogical as it is. Sorry if this isn't the reply you hoped for, but it's the only one I could write, VZ From MAILER-DAEMON Fri Nov 03 10:46:15 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eAdEd-0000Jk-9O for mharc-lmi@gnu.org; Fri, 03 Nov 2017 10:46:15 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54753) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAdEX-0000JW-Gt for lmi@nongnu.org; Fri, 03 Nov 2017 10:46:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eAdEU-00026v-DS for lmi@nongnu.org; Fri, 03 Nov 2017 10:46:09 -0400 Received: from sonic315-16.consmr.mail.bf2.yahoo.com ([74.6.134.126]:45197) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eAdEU-00025u-7H for lmi@nongnu.org; Fri, 03 Nov 2017 10:46:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1509720355; bh=XTSzNPZSNDpftODOfBfJNWEUjaveT/1U8kjecdUpWmo=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=NyEVnVGTPloJCVPa+zR88qEzQwuxt0QcNbHrFa0WHxpn4XzHvAdpreodSkYMQEtFCtNOjYdx8/LBWqNVhmd4LO/1SEscdODRe3OCaib3C2Bm8PpXHoFdsG4QxONe4u1Srug6rqpi2grIvajIHBcuWyPwB8r/7+SYX7IcDYGetmjW8HUrHZ/kTXIpl4/1la8Yvkq5+suibpqMmPfWa0D5vYpLkXea3HQ0gQktHhByxBrauMSUL1zFtfcfKE1yTh99ZhiELvM6zJywrY2Hx7UL7RQoi0K6UFHmK29Ipgr/rjw5gBaKt1tvBE3Z/o1Nl4Cv8IxOdjIWoi2i5E5OkfpiFg== X-YMail-OSG: dUrN.igVM1ltn.Enfm1Ey5Ce_HUzuaNMC1JrOiFCQHGfIyxVH8bGVflXhgnRUwS XjrEmOaJjMUgqxiuP_U7peZ0ETiUE7ENDre3au0XaDGFw2u4ZYXNq3jcIxgdEUwp1OV8QW_4v1kS Gu2GdNTR4S2I1whwE.yf3Ste6JjYlwDvAjLQOm7vkZinKZn.hZ2m5JSLoarf5K5VLAjEtmO1p1RF rAyZ6waFUDKPw7fC0Ya71n_Z_BeMtvUqAocf0VjS8e.6GMH58YzgUpk5WJNTZYyS_aFB1mzUqLjS cGmEzwfm8VpFdsX9gazDE3Lng6nceWjNMao5luZnWtvzVHXvzPVckjXIn.1NJNsKRoDG1bc.UJH5 XmtSQfHwIIshgng09NfSBQFfmAUGpzaO2ZHcNceAsmwuuFATEGhZjoJqlmIy9fODHbHmNkS6GhKU 019HYV4GRGbmLUv3_o0LZpaMxtRCdrr_zlxQKb8AIaI77SRKmyi4OXca8D5WOm0wtg2bGQe0mEQc 8IE3l4h3w89W8PdmPWK0q8oWXIuRX4mcnLOUuWX4LIaTl_VZy2j2CNNBewqd0oI4- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Fri, 3 Nov 2017 14:45:55 +0000 Received: from [127.0.0.1] by smtp114.sbc.mail.bf1.yahoo.com with NNFMP; 03 Nov 2017 14:45:54 -0000 X-Yahoo-Newman-Id: 744381.35852.bm@smtp114.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: dUrN.igVM1ltn.Enfm1Ey5Ce_HUzuaNMC1JrOiFCQHGfIyx VH8bGVflXhgnRUwSXjrEmOaJjMUgqxiuP_U7peZ0ETiUE7ENDre3au0XaDGF w2u4ZYXNq3jcIxgdEUwp1OV8QW_4v1kSGu2GdNTR4S2I1whwE.yf3Ste6JjY lwDvAjLQOm7vkZinKZn.hZ2m5JSLoarf5K5VLAjEtmO1p1RFrAyZ6waFUDKP w7fC0Ya71n_Z_BeMtvUqAocf0VjS8e.6GMH58YzgUpk5WJNTZYyS_aFB1mzU qLjScGmEzwfm8VpFdsX9gazDE3Lng6nceWjNMao5luZnWtvzVHXvzPVckjXI n.1NJNsKRoDG1bc.UJH5XmtSQfHwIIshgng09NfSBQFfmAUGpzaO2ZHcNceA smwuuFATEGhZjoJqlmIy9fODHbHmNkS6GhKU019HYV4GRGbmLUv3_o0LZpaM xtRCdrr_zlxQKb8AIaI77SRKmyi4OXca8D5WOm0wtg2bGQe0mEQc8IE3l4h3 w89W8PdmPWK0q8oWXIuRX4mcnLOUuWX4LIaTl_VZy2j2CNNBewqd0oI4- X-Yahoo-SMTP: mjD.OBqswBAPbVUxYJaYPvc61jLEnpq8VnBwJGdbEJOPA9xw To: "Let me illustrate..." References: <007fcaa4-cb05-542b-6222-d1df245957f2@sbcglobal.net> <16996b95-ac64-0531-7bcc-d3284ee87a3e@sbcglobal.net> <68921510-79e9-1a6c-1c79-2055fac5f3d5@sbcglobal.net> From: Greg Chicares Message-ID: Date: Fri, 3 Nov 2017 14:45:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.6.134.126 Subject: Re: [lmi] Branching to replace XSL-FO X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 14:46:14 -0000 On 2017-11-03 14:13, Vadim Zeitlin wrote: [...] > I hesitate to mention it, but you may easily create your own aliases for > it, e.g. you could use "git switch " for changing branches and > "checkout" for everything else. Understood. Synthesizing commands that implement new behaviors would be a reasonable use case. But I don't want to use aliases as a crutch to avoid learning the tricky stuff. > Sorry if this isn't the reply you hoped for, but it's the only one I could > write, It's exactly what I hoped for. Thanks for bearing with me. Your explanation that git-checkout can both change the working directory and change where HEAD points was particularly helpful. From MAILER-DAEMON Sat Nov 04 11:42:14 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eB0aM-0006qL-Ll for mharc-lmi@gnu.org; Sat, 04 Nov 2017 11:42:14 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50426) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eB0aJ-0006qA-8s for lmi@nongnu.org; Sat, 04 Nov 2017 11:42:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eB0aG-0004rJ-32 for lmi@nongnu.org; Sat, 04 Nov 2017 11:42:11 -0400 Received: from sonic313-16.consmr.mail.bf2.yahoo.com ([74.6.133.126]:42913) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eB0aF-0004lz-Ro for lmi@nongnu.org; Sat, 04 Nov 2017 11:42:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1509810124; bh=KwYtwhxTkTTxOMfPWj1vceT7eeLEmkVysQGTfb2i8Hs=; h=To:From:Subject:Date:From:Subject; b=F+V0ubyUJPyDViZoiGvEHoulLLJrI9D7RXSzh2+AxeYI+kfJ/P5zU43dlfxOBYIzGqD+hTy+FDt207Jy96T6kOUZNdljkQOOsyDJnRa4cJ/tXUYCyJUT03T/BsZDMC6TrCwRYSbDcj73msVtyw4Ls8GdvGUDr92MxozQ286LymARtLypjHncAfal2767wzHJVDttHsvVYKV6tYLWnqYE2q3gGkbG0/6KY1E04Y9Ey0EpP6z8k1e4BN3R7PcbbLAYYQ3Yjy+oVBK3O/d8iaOs9KQHcIZObkE5mrHyBPgTn6c/mC2lVVOx4r+fKXEM9jECU+ze+L4yzUjA80BEipKP/w== X-YMail-OSG: ExDg1EQVM1kER2Q3cNLmG6LBkwk585tcv4IIMQSDs_c.3cJ0i1SEHu.qIpOU1Ot 0_7cBxN2w.fU8nCa9iUVtf1tMTs.nkiCej9cTMRyg2U7XuREoOl9evLxEtVHql9PzXkI3kJ1qe3r 4WnN8uW3fSbHCWPP6R5aQylXe8OxHi4kwGEk9I6GuevK8Smqb6DIHSPK5mrgOqHJiPYDe6EpYNf4 5hUT6YSF2LwJw0pH6dmeuRRNaM5GBOC2835gfAUWGEE.ipAiBuQo.GhHWEjwWmnqZyo9_g9YvlfH 94CZW93mhZAOhuh8sdOMyAEI.qyMh28cily.AFT7Vn_Y2X1penlAbdZ0PIHmCsb.rHHCpKTZVtrN 3N9YKo4JIRgD8Bzqay1XdvcFdgzdL4R1waEJjoHABTDWxQEcHRulY8c5CWhk1KhrSDM0jx_63O5h RrlE2a6BEg8Qe5Dy.nC1BiJwE9yFGG3f4wnXEyCXf6u_ra_cy.yP8j7qxVaSIfgec7CoeVD3yGGS 6iU.56xiDyBOXL4j_UhUmZLWLfJ0tJb4FGwq84oz8WVi4kpOA4anEuQHc.tZe72I- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Sat, 4 Nov 2017 15:42:04 +0000 Received: from [127.0.0.1] by smtp114.sbc.mail.bf1.yahoo.com with NNFMP; 04 Nov 2017 15:42:01 -0000 X-Yahoo-Newman-Id: 772926.51321.bm@smtp114.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ExDg1EQVM1kER2Q3cNLmG6LBkwk585tcv4IIMQSDs_c.3cJ 0i1SEHu.qIpOU1Ot0_7cBxN2w.fU8nCa9iUVtf1tMTs.nkiCej9cTMRyg2U7 XuREoOl9evLxEtVHql9PzXkI3kJ1qe3r4WnN8uW3fSbHCWPP6R5aQylXe8Ox Hi4kwGEk9I6GuevK8Smqb6DIHSPK5mrgOqHJiPYDe6EpYNf45hUT6YSF2LwJ w0pH6dmeuRRNaM5GBOC2835gfAUWGEE.ipAiBuQo.GhHWEjwWmnqZyo9_g9Y vlfH94CZW93mhZAOhuh8sdOMyAEI.qyMh28cily.AFT7Vn_Y2X1penlAbdZ0 PIHmCsb.rHHCpKTZVtrN3N9YKo4JIRgD8Bzqay1XdvcFdgzdL4R1waEJjoHA BTDWxQEcHRulY8c5CWhk1KhrSDM0jx_63O5hRrlE2a6BEg8Qe5Dy.nC1BiJw E9yFGG3f4wnXEyCXf6u_ra_cy.yP8j7qxVaSIfgec7CoeVD3yGGS6iU.56xi DyBOXL4j_UhUmZLWLfJ0tJb4FGwq84oz8WVi4kpOA4anEuQHc.tZe72I- X-Yahoo-SMTP: mjD.OBqswBAPbVUxYJaYPvc61jLEnpq8VnBwJGdbEJOPA9xw To: "Let me illustrate..." From: Greg Chicares Message-ID: Date: Sat, 4 Nov 2017 15:41:59 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.6.133.126 Subject: [lmi] wxProgressDialog z-order anomaly X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 15:42:13 -0000 [Much of this introduction has been discussed in recent personal email, but I'll summarize it for the list.] These anomalies: https://trac.wxwidgets.org/ticket/13185 https://trac.wxwidgets.org/ticket/13933 slipped into the 2017-11-01 release because we had upgraded to gcc-6.3.0 (whereas gcc-4.9.x, due to system-header differences, has actually been using wxGenericProgressDialog all along). For the time being, I've changed lmi to use the generic version in all cases. Although it's still early in the month, I've pushed that as a month-end release candidate so that we stand ready to release it quickly to anyone who's sorely troubled by these issues. Next, I'll work on these changes: https://github.com/vadz/lmi/pull/60 which address certain slight GUI anomalies--for example, a depressed toolbar button might not repaint as quickly as expected on some machines in certain circumstances. To that end, I'll first do the following, which I recite here mostly for my own future reference (a copy-pastable list of commands that are known to have worked extends my comfort zone)...but at the last step, things go awry... # Add Vadim's github repository as a remote, giving it a name # that doesn't begin with 'v' because so many branch names # begin with 'v' that autocompletion becomes unworkable. # ['g' wasn't a good choice either...see far below] git remote add github-vz https://github.com/vadz/lmi.git # Grab an up-to-date local copy of all branches on that remote. # Running this again later updates an existing local copy. git fetch github-vz # Locally alias Vadim's no-xslfo branch. git branch vz-no-xslfo github-vz/direct-pdf-gen-master # Establish my own no-xslfo branch for code review. git branch gwc-no-xslfo `git merge-base master vz-no-xslfo` # Now I think I can push this without harming the savannah # repository. git push origin gwc-no-xslfo # And now (as discussed off-list) I should be able to merge # https://github.com/vadz/lmi/pull/60 # easily, without laboriously downloading patches from github, # and it should be a fast-forward merge if I do it now; AFAICT, # the command for that is: git merge --ff-only github-vz/menu-refresh-fix Except that doesn't work: /opt/lmi/src/lmi[0]$git merge --ff-only github-vz/menu-refresh-fix fatal: Not possible to fast-forward, aborting. Well, this isn't svn, so I can make as many mistkaes as I want and still expect to clean them up neatly, as long I don't push them; so, ignoring the advice given here: http://lists.nongnu.org/archive/html/lmi/2016-12/msg00016.html and forging blithely ahead: /opt/lmi/src/lmi[128]$git merge github-vz/menu-refresh-fix Merge made by the 'recursive' strategy. single_choice_popup_menu.cpp | 32 +++++++++++++++----------------- single_choice_popup_menu.hpp | 10 ++-------- 2 files changed, 17 insertions(+), 25 deletions(-) /opt/lmi/src/lmi[0]$git log --graph --oneline HEAD~2..HEAD * ebcf1b2dd Merge remote-tracking branch 'github-vz/menu-refresh-fix' |\ | * 188309c53 Repaint area covered by SingleChoicePopupMenu after showing it | * 4bea744df Don't derive SingleChoicePopupMenu from wxWindow | * c334ae093 Simplify SingleChoicePopupMenu by using wxWidgets functionality * ad4e45100 Improve command to test mirror synchronization with server Is it still a fox-trot merge https://developer.atlassian.com/blog/2016/04/stop-foxtrots-now/ if all the asterisks between the first and last lines are in one column? And shouldn't there be a second-to-last line with just "|/"? Maybe I need to run git-log from the original point of divergence... /opt/lmi/src/lmi[0]$git merge-base master github-vz/menu-refresh-fix 188309c53b2a759516024fef525e8f31fa07c6fc /opt/lmi/src/lmi[0]$git log --graph --oneline 188309c..HEAD * ebcf1b2dd Merge remote-tracking branch 'github-vz/menu-refresh-fix' * ad4e45100 Improve command to test mirror synchronization with server [snip nine lines of purely linear history] * 8784138ae Improve documentation I thought that would just expand the scope of the graph, but instead the commits along the branch got collapsed. I tried adding '--all' just to see what would happen, but that didn't show me the recent nonlinear zone in the graph that I expected to see. Instead, it produced two scary effects: it filled a 'less' buffer with tons of old history, and it caused a robot to phone me with an emergency notification that my "microsoft license key" has expired. But I can alter the fabric of time: /opt/lmi/src/lmi[0]$git log -2 --pretty=oneline ebcf1b2dd431164716241205f20068b342af9485 Merge remote-tracking branch 'github-vz/menu-refresh-fix' ad4e451000e7982366fb9152d2c3d9b4dca73066 Improve command to test mirror synchronization with server /opt/lmi/src/lmi[0]$git reset --hard ad4e45100 Looking at the advice given when I last did a fox-trot merge: http://lists.nongnu.org/archive/html/lmi/2016-12/msg00016.html I think maybe I want to do this: /opt/lmi/src/lmi[0]$git pull --rebase github-vz menu-refresh-fix >From https://github.com/vadz/lmi * branch menu-refresh-fix -> FETCH_HEAD First, rewinding head to replay your work on top of it... Applying: Improve documentation Applying: Implement NAAR solves in an expedient manner Applying: Designate release candidate 20171012T2109Z Applying: Refine git configuration in chroot Applying: Fall back on generic progress dialog to work around regressions Applying: Dismiss a marked defect [382] Applying: Designate release candidate 20171101T2204Z Applying: Synchronize more than one recent commit to local mirror Applying: Synchronize files most recently git-pulled to local mirror Applying: Name konsole tabs more klearly Applying: Improve command to test mirror synchronization with server As a general rule, maybe that's what's wanted, because the history seems linear, without any "fox-trot" knot: /opt/lmi/src/lmi[0]$git log --graph --oneline f79cec2b4^..HEAD * ea879fef0 Improve command to test mirror synchronization with server * f492a5de8 Name konsole tabs more klearly * aff831fa1 Synchronize files most recently git-pulled to local mirror * 5861eba41 Synchronize more than one recent commit to local mirror * b244d52db Designate release candidate 20171101T2204Z * b9a40d891 Dismiss a marked defect [382] * 17acc2aa2 Fall back on generic progress dialog to work around regressions * b6d7b659b Refine git configuration in chroot * c433c728b Designate release candidate 20171012T2109Z * abbb1db3d Implement NAAR solves in an expedient manner * ee71c7709 Improve documentation * 188309c53 Repaint area covered by SingleChoicePopupMenu after showing it * 4bea744df Don't derive SingleChoicePopupMenu from wxWindow * c334ae093 Simplify SingleChoicePopupMenu by using wxWidgets functionality * f79cec2b4 Enable and apply stable and security upgrades in chroot However, in this case, there's a practical problem. I don't want to rewind across any "Designate release candidate" commit. I understand that git mavens might say I should create "release branches", but I can learn git only at a finite rate, and sometimes I feel like I'm going too fast, like a participant in a hot-dog-eating contest (USA cultural allusion--it's like gavage in foie gras production, except the subjects are human and they stuff themselves willingly). In this case, origin/master has this commit: bd4bcb5 Designate release candidate 20171101T2204Z and I don't want to alter the history that preceded it, turning it into some new and different c433c728b. Therefore, do I really want git merge github-vz/menu-refresh-fix (without '--ff-only') in this situation, even if it is a fox-trot? Pending expert advice, let's $git reset --hard ad4e45100 again and practice some simpler git stuff. I want autocompletion to be tidier than this: /opt/lmi/src/lmi[0]$git checkout g [press Tab to autocomplete] git-svn github-vz/menu-refresh-fix github-vz/automake-tests github-vz/new-boost [...snip twelve lines...] github-vz/master-new and in theory I might rename 'git-svn', but that's presumably the zeroth commit and it seems unwise to disturb ancient relics, so let's change the 'github' thing I recently added. Apparently 'git remote rm' should remove it (so that I can later recreate it with a different name): /opt/lmi/src/lmi[0]$git remote github-vz origin /opt/lmi/src/lmi[0]$git branch gwc-no-xslfo * master vz-no-xslfo /opt/lmi/src/lmi[0]$git remote rm github-vz /opt/lmi/src/lmi[0]$git remote origin /opt/lmi/src/lmi[0]$git branch gwc-no-xslfo * master vz-no-xslfo That's surprising: https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes | git remote rm | Once you delete the reference to a remote this way, all | remote-tracking branches and configuration settings | associated with that remote are also deleted. Why do I still have a 'vz-no-xslfo' branch? Isn't that a "remote-tracking branch" that should have been deleted? It's a branch the corresponds to a remote, but I guess it doesn't "track" the remote branch in some sense. Yet it's not "local" either, in the following sense: /opt/lmi/src/lmi[0]$git branch --merged gwc-no-xslfo * master Well, no matter--I can use the '--force' if necessary to vaporize branches: /opt/lmi/src/lmi[0]$git branch --delete gwc-no-xslfo Deleted branch gwc-no-xslfo (was f79cec2b4). /opt/lmi/src/lmi[0]$git branch --no-merged vz-no-xslfo /opt/lmi/src/lmi[0]$git branch --delete vz-no-xslfo error: The branch 'vz-no-xslfo' is not fully merged. If you are sure you want to delete it, run 'git branch -D vz-no-xslfo'. /opt/lmi/src/lmi[1]$git branch --delete --force vz-no-xslfo Deleted branch vz-no-xslfo (was 0c85a7a99). No more branches or remotes now? /opt/lmi/src/lmi[0]$git branch * master /opt/lmi/src/lmi[0]$git remote origin Well, not actually--I guess I could have answered my own question about remote "tracking" branches with commands like these: /opt/lmi/src/lmi[0]$git branch --remotes origin/HEAD -> origin/master origin/gwc-no-xslfo origin/master /opt/lmi/src/lmi[0]$git branch --all * master remotes/origin/HEAD -> origin/master remotes/origin/gwc-no-xslfo remotes/origin/master I certainly don't want to remove any of those except 'gwc-no-xslfo'. And there's no point in removing that one except to prove that I can, but I do want to prove that to myself. The inverse of the commands that created it: git branch gwc-no-xslfo `git merge-base master vz-no-xslfo` git push origin gwc-no-xslfo is apparently either this: git branch --delete --remotes or one of these: git remote prune [--dry-run] origin which I tried first because it has a '--dry-run' option, and which apparently does nothing in this situation; git remote update --prune (but it seems weird to update and then prune); or git remote rm gwc-no-xslfo which sounds like exactly what I want, except... /opt/lmi/src/lmi[0]$git remote --verbose origin chicares@git.sv.gnu.org:/srv/git/lmi.git (fetch) origin chicares@git.sv.gnu.org:/srv/git/lmi.git (push) ....I certainly don't want to remove any of those, and thus 'gwc-no-xslfo' is apparently a "remote branch" but not a "remote". But here's another idea: git push origin :gwc-no-xslfo where the colon means "delete": /opt/lmi/src/lmi[0]$git push origin :gwc-no-xslfo --verbose Pushing to [my identity, at-sign,] git.sv.gnu.org:/srv/git/lmi.git [...credentials validated...] remote: Sending notification emails to: lmi-commits@nongnu.org To git.sv.gnu.org:/srv/git/lmi.git - [deleted] gwc-no-xslfo updating local tracking ref 'refs/remotes/origin/gwc-no-xslfo' The verbose output seems promising, and this command seems to confirm that it worked: /opt/lmi/src/lmi[0]$git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/master I was worried because the 'gwc-no-xslfo' thing persisted here: http://git.savannah.nongnu.org/cgit/lmi.git/refs/ for a minute, but probably just as a caching artifact, because it's gone now. Okay, so I've figured out several ways to do the wrong thing, and how to revert experimental mistakes. But how can I integrate https://github.com/vadz/lmi/pull/60 without altering history prior to the latest release candidate? From MAILER-DAEMON Sat Nov 04 12:40:10 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eB1UQ-0003lj-S3 for mharc-lmi@gnu.org; Sat, 04 Nov 2017 12:40:10 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59798) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eB1UO-0003je-6E for lmi@nongnu.org; Sat, 04 Nov 2017 12:40:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eB1UK-0001Py-Qw for lmi@nongnu.org; Sat, 04 Nov 2017 12:40:08 -0400 Received: from sunset.tt-solutions.com ([82.240.17.225]:60550 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eB1UK-0001NT-9q for lmi@nongnu.org; Sat, 04 Nov 2017 12:40:04 -0400 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eB1UF-0005J9-7l for lmi@nongnu.org; Sat, 04 Nov 2017 17:39:59 +0100 Date: Sat, 4 Nov 2017 17:39:58 +0100 From: Vadim Zeitlin To: "Let me illustrate..." MIME-Version: 1.0 References: In-Reply-To: X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 82.240.17.225 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: [lmi] wxProgressDialog z-order anomaly X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 16:40:10 -0000 On Sat, 4 Nov 2017 15:41:59 +0000 Greg Chicares wrote: [... many git commands ...] I'm not sure if it's useful to review all of these commands (and their results) in details, because you seem to have mostly figured everything out correctly already -- except for the root cause of the problem, but then I don't see it neither and I suspect that somehow the commands given in your email were not executed exactly as written. Let me describe what you have right now instead and describe how I would investigate the problem instead: So, first I would check what do we have now. For this I need to know when was the PR branch split from master: $ git merge-base master github/menu-refresh-fix f79cec2b455693b9ccf81ce4a0116e88f7d6bf64 (BTW, just in case: the name of the branch can be seen near the top of the page, just under the PR title -- you would also see the git commands specifying how you could merge this branch near the bottom of the page if you were logged in, but just the branch name should be mostly sufficient). This commit is nothing special, it was just the latest master commit in my local master when I did this change (notice that I forgot to update it, Savannah master did have a couple of more commits even back then). It so happens (but this is just a pure coincidence), that this is also the merge-base of direct-pdf-gen-master branch and master. But, even these 2 branches start from the same master commit, they diverge and contain completely different changes, i.e. you have this graph, where the horizontal axis is time and goes in the usual direction and I've also shown that there were more commits done on master (exactly 11 of them at the time of this writing) since then: *---*---... about 150 more ... ---*---* direct-pdf-gen-master / --- *---*---*--- ... 8 more ... ---*---* master \ *---*---* menu-refresh-fix So it makes total sense that you can't fast-forward a branch based on direct-pdf-gen-master to menu-refresh-fix, they're not collinear. OTOH if you did create a new branch starting from the base commit (the one where the graph above bifurcates), as you wrote: GC> # Establish my own no-xslfo branch for code review. GC> git branch gwc-no-xslfo `git merge-base master vz-no-xslfo` then you should be able to fast-forward it to menu-refresh fix because they would indeed be on the same line. I.e. the command above directly followed by GC> git merge --ff-only github-vz/menu-refresh-fix really should have worked. If it didn't, you must have either done some changes to gwc-no-xslfo branch or were on a wrong branch. The first can be ascertained by doing $ git log --oneline master.. (I use "--oneline" because I'm not interested in commit details, I just want to see if there were any of them and, if so, which ones) which would show you all the commits done in the branch since it split from master. For the fast-forward merge with menu-refresh-fix to succeed, there must be none. And the second can be checked using either "git branch" or "git symbolic-ref HEAD" which I have always shown in my zsh prompt. But the most important thing is that even if the merge above had worked, this wouldn't really help you at all, because your goal is to integrate my changes in master, not some other branch. I don't know if you intentionally wanted to combine them with your integration work on PDF generation or not, but if you did, then I'd like to strongly argue against this: they're completely different things and it makes no sense to mix them together. Of course, please don't take this into account if it was just a mistake. So, after saying all this, let me finally answer the question: GC> Okay, so I've figured out several ways to do the wrong thing, GC> and how to revert experimental mistakes. But how can I integrate GC> https://github.com/vadz/lmi/pull/60 GC> without altering history prior to the latest release candidate? First of all, let's forget about direct-pdf-gen-branch and gwc-no-xslfo, they still exist as they did before, but it doesn't matter as we won't use them at all. Instead, let's start by returning to master: $ git checkout master It is presumably always at the latest origin/master (where "origin" is the remote corresponding to Savannah repository), but it doesn't hurt to check: $ git fetch origin And if this brings any new changes: $ git merge --ff-only origin/master (BTW, I have "ff = merge --ff-only" in the [alias] section of my ~/.gitconfig because I use this command so often). Now let's examine the new commits in the branch we want to integrate: $ git log ..github-vz/menu-refresh-fix ... shows my 3 commits ... We can also check, or confirm, that there are some commits in master that have been done since this PR $ git log github-vz/menu-refresh-fix.. ... shows your commits postdating my PR ... This shows that fast-forwarding is impossible and we now have a choice: either you just merge the branch into master or your replay the changes done in the branch onto the newest master. The first choice is the "native Git" way of doing things. A simple $ git merge github-vz/menu-refresh-fix is enough to do it and while it will indeed create a merge commit, i.e. result in current master --- *---*---*--- ... ---*---*------------* new master \ / *------*--------* ------------ menu-refresh-fix there is really no problem with this and, in fact, there is an advantage in seeing that the 3 commits merged into master as one are parts of logically-related changes. But if you want to preserve the linear history, you have another choice: replace the 3 commits of the branch on master. This can be done manually by using "git cherry-pick" to pick the commits one by one: $ git cherry-pick github-vz/menu-refresh-fix~2 $ git cherry-pick github-vz/menu-refresh-fix~1 $ git cherry-pick github-vz/menu-refresh-fix Or it can be done by cherry-picking them all at once: $ git cherry-pick ..github-vz/menu-refresh-fix (you can check using "git log" that this commit selection expression results in exactly the same commits). Or, and this is probably the most confusing, but also the most powerful and, in practice, most useful, way by doing "git rebase": this is a command which basically automates calling cherry-pick in a loop and also provides many other handy features via its "-i" (interactive) option, like the ability to amend commits on the fly, change their order, commit message, selectively drop some of them and more. In this case you want to rebase the menu-refresh-fix branch, so you need to switch to it first and, as you can't switch to a remote branch, you need to create your local branch first: $ git branch gwc-menu-refresh-fix github-vz/menu-refresh-fix $ git checkout gwc-menu-refresh-fix (as you probably already know, you can also combine these 2 commands by using "git checkout -b", but I give their full form for clarity). Now you can rebase, i.e. replay, all the branch commits on master. If you don't need to do anything fancy, you don't need to use the -i option, so it's just $ git rebase master It looks like nothing happened as you still have the same (or almost, their SHA-1s have changed) commits on your branch. Except that instead of --- *---*---*--- ... 8 more ... ---*---M master \ A---B---C gwc-menu-refresh-fix things now looks like this: --- *---*---*--- ... 8 more ... ---*---M---A'---B'---C' gwc-menu-refresh-fix (notice that master is still unchanged and continues to point to "M"). And this is important because it means that _now_ you can fast-forward master to this branch, so let's do just this: $ git checkout master $ git merge --ff-only gwc-menu-refresh-fix Once this is done, you don't need the branch any longer and you can just $ git branch -d gwc-menu-refresh-fix And, of course, you end up by doing $ git push origin master to really push out the changes, maybe after doing more commits to improve or extend my changes. I hope this answers your question and this post is already sufficiently long for me to not go into further details but please let me know if you still have any specific questions that you'd like me to answer. Also note that if you want to change something in my commits before applying them, there is a simple way to do it with "git rebase -i": please let me know if/when you'd like to know more about it. Good luck! VZ From MAILER-DAEMON Sat Nov 04 14:04:02 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eB2na-0007qA-Lj for mharc-lmi@gnu.org; Sat, 04 Nov 2017 14:04:02 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48798) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eB2nY-0007q2-II for lmi@nongnu.org; Sat, 04 Nov 2017 14:04:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eB2nU-00088y-65 for lmi@nongnu.org; Sat, 04 Nov 2017 14:04:00 -0400 Received: from sonic315-16.consmr.mail.bf2.yahoo.com ([74.6.134.126]:34879) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eB2nU-00088g-0L for lmi@nongnu.org; Sat, 04 Nov 2017 14:03:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1509818634; bh=moFuUeHJek8NIamO8Gaqjr4t3rbNrnKOslQqehKD0a8=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=Yto/0aJVmxPeRQC67q9bbSnKU0JBS0iomx7NIXOs8Qp/FOZhL1w39L9VRy2QhFpweNhJTNdsgxfTVj8iGPw0r47amtPbsVoNrVzRnqFNr10L4jjbVsGAFQeUenJ3kvKkzYSNUpwWepQq6xAgZj2MIzS7c8reMqCbFFnrOleblNs20qm0BuHP+6AKD8xFFFbZUKxzTk/emS7D3i57k7OSndTWxBjhiZLIfeIlFWfGVtkMlKpTiYzUw++kcdi4nG68Pc4Lld2pATjxqzqv0YPMtx7A3DPbpj9+g47eCbXEKK4X7JulxjcmE04UGkPN4TiwtZc4iiFtBS244teyiNVOEg== X-YMail-OSG: ce2Wl28VM1nKU8ULdKqFHQsn30JCYaBO.bc12iq3sc4Z1ZQ.PB5ry9rO.9jOYQT fVKWUI_GkX5ydfSB_cgITHCwdYby0CKHbY9F0XGbd_d5UKbbtA2cUxPafsFPqbOnc0i35xMhm03B vkZrLGgsYqxeTZFPhd98p0JT1UZP3mq1PfS.znFhLiJ51bQlzogrYtesFz9hRuJp7kDlPGPYttFf OflYazz9i6j2mSnCXpoS74bso68UL9VxIzmRm0j_0xBFKmH1RLlQUnhTkpNo4IJA5PU3eXFOaN8a UhCGIGI35XJNSGGA63Mz5TA.m3_NIFjlufqMEeoqF2FW2yZfPrayZ6t2Nfdms.WZ7hgawx6DJmIq u9PeFYU62ncEyXqqtDlgZ98IJkaVzij92fgMCa2MLS9p2bIXzi67iEBs1WvBUvb6ClGnwVuix0QK cxx4HNiUqkvb53Oj5Uc0UXedPkf5FsDitH_VFkQygVGq2DIpUAkRrhjjx4hTKDIziCODPVQZXX.G h43aJN27dfeUoIHWal.w2IWpL5atoGty0h0JXGOf6SMFb8eVcBhVsxKN1.rYM.Ms- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Sat, 4 Nov 2017 18:03:54 +0000 Received: from [127.0.0.1] by smtp111.sbc.mail.bf1.yahoo.com with NNFMP; 04 Nov 2017 18:03:53 -0000 X-Yahoo-Newman-Id: 905670.49026.bm@smtp111.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ce2Wl28VM1nKU8ULdKqFHQsn30JCYaBO.bc12iq3sc4Z1ZQ .PB5ry9rO.9jOYQTfVKWUI_GkX5ydfSB_cgITHCwdYby0CKHbY9F0XGbd_d5 UKbbtA2cUxPafsFPqbOnc0i35xMhm03BvkZrLGgsYqxeTZFPhd98p0JT1UZP 3mq1PfS.znFhLiJ51bQlzogrYtesFz9hRuJp7kDlPGPYttFfOflYazz9i6j2 mSnCXpoS74bso68UL9VxIzmRm0j_0xBFKmH1RLlQUnhTkpNo4IJA5PU3eXFO aN8aUhCGIGI35XJNSGGA63Mz5TA.m3_NIFjlufqMEeoqF2FW2yZfPrayZ6t2 Nfdms.WZ7hgawx6DJmIqu9PeFYU62ncEyXqqtDlgZ98IJkaVzij92fgMCa2M LS9p2bIXzi67iEBs1WvBUvb6ClGnwVuix0QKcxx4HNiUqkvb53Oj5Uc0UXed Pkf5FsDitH_VFkQygVGq2DIpUAkRrhjjx4hTKDIziCODPVQZXX.Gh43aJN27 dfeUoIHWal.w2IWpL5atoGty0h0JXGOf6SMFb8eVcBhVsxKN1.rYM.Ms- X-Yahoo-SMTP: mjD.OBqswBAPbVUxYJaYPvc61jLEnpq8VnBwJGdbEJOPA9xw To: "Let me illustrate..." References: From: Greg Chicares Message-ID: Date: Sat, 4 Nov 2017 18:03:51 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.6.134.126 Subject: Re: [lmi] wxProgressDialog z-order anomaly X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 18:04:01 -0000 On 2017-11-04 16:39, Vadim Zeitlin wrote: > On Sat, 4 Nov 2017 15:41:59 +0000 Greg Chicares wrote: [...severe pruning...] > But if you want to preserve the linear history, you have another choice: > replace the 3 commits of the branch on master. This can be done manually by > using "git cherry-pick" to pick the commits one by one: > > $ git cherry-pick github-vz/menu-refresh-fix~2 > $ git cherry-pick github-vz/menu-refresh-fix~1 > $ git cherry-pick github-vz/menu-refresh-fix > > Or it can be done by cherry-picking them all at once: > > $ git cherry-pick ..github-vz/menu-refresh-fix I want to study the rest of your email first before choosing a method, but if I were to do it this way, should it have the same effect as my wearisome but proven method of adding '.patch' at the end of each individual patch's URL, viz.: https://github.com/vadz/lmi/commit/c334ae0937894937570737f5348c0b19d83da0b6.patch https://github.com/vadz/lmi/commit/4bea744dfba3ddca45bb312ea61528761de9a549.patch https://github.com/vadz/lmi/commit/188309c53b2a759516024fef525e8f31fa07c6fc.patch and then saving their contents and running git-am on each in succession? BTW, I reviewed the changes, and they're tremendous improvements. (Actually, at first I made the mistake of reviewing them all reversed, and every single reversed change was shockingly awful--I don't know how I could ever have written that stuff.) I have only one question, concerning this line: if (wxEventLoopBase* const loop = wxEventLoopBase::GetActive()) Do you think this: if (nullptr != wxEventLoopBase* const loop = wxEventLoopBase::GetActive()) would be an improvement, because it makes it clear that we're checking for a null pointer? Or would it be worse, because such a construct with " != ... = ' introduces more confusion? Hmm...or maybe wxEventLoopBase* const loop = wxEventLoopBase::GetActive(); if (nullptr != loop) would be best of all? From MAILER-DAEMON Sat Nov 04 14:16:30 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eB2ze-0000XM-Qq for mharc-lmi@gnu.org; Sat, 04 Nov 2017 14:16:30 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50377) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eB2zc-0000XG-AJ for lmi@nongnu.org; Sat, 04 Nov 2017 14:16:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eB2zZ-0007ZM-4N for lmi@nongnu.org; Sat, 04 Nov 2017 14:16:28 -0400 Received: from sunset.tt-solutions.com ([82.240.17.225]:33254 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eB2zY-0007YY-Pb for lmi@nongnu.org; Sat, 04 Nov 2017 14:16:25 -0400 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eB2zW-0008SP-50 for lmi@nongnu.org; Sat, 04 Nov 2017 19:16:22 +0100 Date: Sat, 4 Nov 2017 19:16:21 +0100 From: Vadim Zeitlin To: "Let me illustrate..." MIME-Version: 1.0 References: In-Reply-To: X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 82.240.17.225 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: [lmi] wxProgressDialog z-order anomaly X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 18:16:29 -0000 On Sat, 4 Nov 2017 18:03:51 +0000 Greg Chicares wrote: GC> On 2017-11-04 16:39, Vadim Zeitlin wrote: GC> > On Sat, 4 Nov 2017 15:41:59 +0000 Greg Chicares wrote: GC> [...severe pruning...] GC> > But if you want to preserve the linear history, you have another choice: GC> > replace the 3 commits of the branch on master. This can be done manually by GC> > using "git cherry-pick" to pick the commits one by one: GC> > GC> > $ git cherry-pick github-vz/menu-refresh-fix~2 GC> > $ git cherry-pick github-vz/menu-refresh-fix~1 GC> > $ git cherry-pick github-vz/menu-refresh-fix GC> > GC> > Or it can be done by cherry-picking them all at once: GC> > GC> > $ git cherry-pick ..github-vz/menu-refresh-fix GC> GC> I want to study the rest of your email first before choosing a method, GC> but if I were to do it this way, should it have the same effect as my GC> wearisome but proven method of adding '.patch' at the end of each GC> individual patch's URL, viz.: GC> https://github.com/vadz/lmi/commit/c334ae0937894937570737f5348c0b19d83da0b6.patch GC> https://github.com/vadz/lmi/commit/4bea744dfba3ddca45bb312ea61528761de9a549.patch GC> https://github.com/vadz/lmi/commit/188309c53b2a759516024fef525e8f31fa07c6fc.patch GC> and then saving their contents and running git-am on each in succession? Yes, this is basically what it does underneath (and so does "git rebase" too). Using "git cherry-pick" is more convenient because it has handy options like "--abort" to return to the initial state if something has gone very wrong and it cleans up its temporary files automatically but, again, fundamentally that's all it does. Remember that Git is just "stupid content tracker", it doesn't do anything complicated, but just does a lot of simple things automatically for you. Of course, as anybody who has studied dialectical materialism knows, at some point the sheer quantity of all these small things it does for you automatically transforms into a drastic change in quality of your workflow. GC> BTW, I reviewed the changes, and they're tremendous improvements. GC> (Actually, at first I made the mistake of reviewing them all reversed, GC> and every single reversed change was shockingly awful--I don't know GC> how I could ever have written that stuff.) I'm pretty sure that GetPopupMenuSelectionFromUser() didn't exist when you wrote this code, so the first two commits are just a modernization and not a real improvement. As for the last one, it's really just a dirty hack and I am not at all proud of it, but it seems like a small cost to pay to solve a problem which is not _that_ critical in the grand scheme of things and so might not be worth spending more time on it. GC> I have only one question, GC> concerning this line: GC> GC> if (wxEventLoopBase* const loop = wxEventLoopBase::GetActive()) GC> GC> Do you think this: GC> GC> if (nullptr != wxEventLoopBase* const loop = wxEventLoopBase::GetActive()) GC> GC> would be an improvement, No, because it wouldn't compile. GC> Hmm...or maybe GC> GC> wxEventLoopBase* const loop = wxEventLoopBase::GetActive(); GC> if (nullptr != loop) GC> GC> would be best of all? I prefer the current version because it doesn't leak the "loop" variable outside of the block where it is used. I really don't think that the idea of testing for a pointer validity using a simple "if" is bad on its own. In some sense it's actually better than comparing it with nullptr explicitly IMO because we're not really interested in a comparison, but just in its validity. E.g. if we used smart pointers and not raw ones, we could still write exactly the same thing with exactly the same intent and actual effect, which is IMO on its own a good argument for preferring it. I do realize that this is a contentious point though... VZ From MAILER-DAEMON Sun Nov 05 12:50:05 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eBP3d-0005Xv-Gc for mharc-lmi@gnu.org; Sun, 05 Nov 2017 12:50:05 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55298) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eBP3a-0005Xm-1n for lmi@nongnu.org; Sun, 05 Nov 2017 12:50:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eBP3W-0004De-3e for lmi@nongnu.org; Sun, 05 Nov 2017 12:50:02 -0500 Received: from sonic315-16.consmr.mail.bf2.yahoo.com ([74.6.134.126]:46394) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eBP3V-0004Bc-SR for lmi@nongnu.org; Sun, 05 Nov 2017 12:49:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1509904194; bh=MAXQRSp6kVNDLUC77nlFzEFgmrh4LLmBKCatSDTqOPs=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=gYHfIFNMcY0wYVaYTi074lzJVVKcDkQHCdR5BENadLUQOM2tn2yVPqc/sxcPfsXbH38htFNuwOkRkIFENHjMXSJX+gpoCa72XhvRzzsrtASr+BPolhzyB1yOGNH1Iq5X3Emj8GPF95sIjG+iEI50f8x8lBJL5eXQ13kTqls7/Wp/inQw6y3w9bUm40WG6Fl+pjP4/bCbcw4bt5I2aPxrV0AzaxjxdiBa9I5ivBHCjN0PPvMViZNaFWe3fRjgC3+Jl8iVPlqwhz2AmFvS06kn2tMT2W5ZNQMZcqM6oFszBSWpt6npanv+MKyERp0WoHYjHbPPVRwYAU+EJ6a4dUNmyA== X-YMail-OSG: hQpw7iMVM1ndi5Fe.HQeE2uNEnfqqGdbolA6_dSCW2RctBC1nyeWaKz6WaxpNkc KokhR275rlC_gsiBlX79BD0vQS0Spu6ye0E25B.IkvlZb2NPoFKRd5Ii_tTUnfasJ.F.wlA_suD8 tynT7ZHiVQrhZpcYdERo4.rQK7kovufpi4Ft1uRKvOclu3BuwGZqrN2GvKAtNfIuJaFff4AorzJu kjcdlZ5gYQgAiwhgjxLO809GkOdPzVMmXQh8UQyuIRG89KFtFK.hA1gNo3I_DsQMFkB4949Ovvkg C1CPV.dhoJAaFgsngNkBAh1j70wqhqJmXlfjgzD1naHVTkvLwBFvh382.1isaThs_PmwPUoMTRDv XFqYXYcjk0g_hzWSylSUGLM0nCTDde42XvutfFRwNvppG.eaR9sMFtYiaJKwBe3D3dOeCiInvjQr 05WEz1plii7u1EK1rMdghxMUQj.JCjziYZPCR8WcTPQv6LwVobeouodBAQJ3WD6ZwGkOjCfcHCqS s5dxA_Chv442DXhacEN1P0lkCQroRRINP_ToXQABclFgoZmWhTPkQSlJfy1FQbY4- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Sun, 5 Nov 2017 17:49:54 +0000 Received: from [127.0.0.1] by smtp116.sbc.mail.bf1.yahoo.com with NNFMP; 05 Nov 2017 17:49:52 -0000 X-Yahoo-Newman-Id: 67681.59591.bm@smtp116.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: hQpw7iMVM1ndi5Fe.HQeE2uNEnfqqGdbolA6_dSCW2RctBC 1nyeWaKz6WaxpNkcKokhR275rlC_gsiBlX79BD0vQS0Spu6ye0E25B.IkvlZ b2NPoFKRd5Ii_tTUnfasJ.F.wlA_suD8tynT7ZHiVQrhZpcYdERo4.rQK7ko vufpi4Ft1uRKvOclu3BuwGZqrN2GvKAtNfIuJaFff4AorzJukjcdlZ5gYQgA iwhgjxLO809GkOdPzVMmXQh8UQyuIRG89KFtFK.hA1gNo3I_DsQMFkB4949O vvkgC1CPV.dhoJAaFgsngNkBAh1j70wqhqJmXlfjgzD1naHVTkvLwBFvh382 .1isaThs_PmwPUoMTRDvXFqYXYcjk0g_hzWSylSUGLM0nCTDde42XvutfFRw NvppG.eaR9sMFtYiaJKwBe3D3dOeCiInvjQr05WEz1plii7u1EK1rMdghxMU Qj.JCjziYZPCR8WcTPQv6LwVobeouodBAQJ3WD6ZwGkOjCfcHCqSs5dxA_Ch v442DXhacEN1P0lkCQroRRINP_ToXQABclFgoZmWhTPkQSlJfy1FQbY4- X-Yahoo-SMTP: mjD.OBqswBAPbVUxYJaYPvc61jLEnpq8VnBwJGdbEJOPA9xw To: "Let me illustrate..." References: From: Greg Chicares Message-ID: <5c40e07b-88ff-8df9-8b20-37bba71c5362@sbcglobal.net> Date: Sun, 5 Nov 2017 17:49:49 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.6.134.126 Subject: Re: [lmi] wxProgressDialog z-order anomaly X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 17:50:04 -0000 On 2017-11-04 16:39, Vadim Zeitlin wrote: > On Sat, 4 Nov 2017 15:41:59 +0000 Greg Chicares wrote: > > [... many git commands ...] > > I'm not sure if it's useful to review all of these commands (and their > results) in details, because you seem to have mostly figured everything out > correctly already -- except for the root cause of the problem, but then I > don't see it neither and I suspect that somehow the commands given in your > email were not executed exactly as written. My goal is to distill that stuff down to a small collection of reusable snippets. Having torn everything down yesterday, I reconstruct it (with a remote name chosen for single-letter autocompletion) thus, reusing proven snippets: git remote add xanadu https://github.com/vadz/lmi.git git fetch xanadu git branch vz-no-xslfo xanadu/direct-pdf-gen-master git branch gwc-no-xslfo `git merge-base master vz-no-xslfo` git push origin gwc-no-xslfo > So, first I would check what do we have now. For this I need to know when > was the PR branch split from master: > > $ git merge-base master github/menu-refresh-fix > f79cec2b455693b9ccf81ce4a0116e88f7d6bf64 git merge-base master xanadu/menu-refresh-fix f79cec2b455693b9ccf81ce4a0116e88f7d6bf64 > (BTW, just in case: the name of the branch can be seen near the top of the > page, just under the PR title -- you would also see the git commands > specifying how you could merge this branch near the bottom of the page if > you were logged in, but just the branch name should be mostly sufficient). > This commit is nothing special, it was just the latest master commit in my > local master when I did this change (notice that I forgot to update it, > Savannah master did have a couple of more commits even back then). https://github.com/vadz/lmi/pull/60 | vadz wants to merge 3 commits into master from menu-refresh-fix So far so good. > It so happens (but this is just a pure coincidence), that this is also the > merge-base of direct-pdf-gen-master branch and master. Yes, 'f79cec...' did seem eerily familiar. > But, even these 2 > branches start from the same master commit, they diverge and contain > completely different changes, i.e. you have this graph, where the > horizontal axis is time and goes in the usual direction and I've also shown > that there were more commits done on master (exactly 11 of them at the time > of this writing) since then: > > > *---*---... about 150 more ... ---*---* direct-pdf-gen-master > / > --- *---*---*--- ... 8 more ... ---*---* master > \ > *---*---* menu-refresh-fix > > So it makes total sense that you can't fast-forward a branch based on > direct-pdf-gen-master to menu-refresh-fix, they're not collinear. OTOH if > you did create a new branch starting from the base commit (the one where > the graph above bifurcates), as you wrote: > > GC> # Establish my own no-xslfo branch for code review. > GC> git branch gwc-no-xslfo `git merge-base master vz-no-xslfo` > > then you should be able to fast-forward it to menu-refresh fix because they > would indeed be on the same line. I.e. the command above directly followed > by > > GC> git merge --ff-only github-vz/menu-refresh-fix > > really should have worked. Aha. The '-ff-only' merge would have worked on my 'gwc-no-xslfo' branch, but I'm trying to merge 'menu-refresh-fix' into master. > If it didn't, you must have either done some changes to gwc-no-xslfo > branch or were on a wrong branch. The first can be ascertained by doing > > $ git log --oneline master.. That command shows nothing, because I'm on master: /opt/lmi/src/lmi[0]$git log --oneline master.. /opt/lmi/src/lmi[0]$git branch gwc-no-xslfo * master vz-no-xslfo > And the second can be checked using either "git branch" or "git > symbolic-ref HEAD" which I have always shown in my zsh prompt. /opt/lmi/src/lmi[0]$git symbolic-ref HEAD refs/heads/master > But the most important thing is that even if the merge above had worked, > this wouldn't really help you at all, because your goal is to integrate my > changes in master, not some other branch. I don't know if you intentionally > wanted to combine them with your integration work on PDF generation or not, No. > but if you did, then I'd like to strongly argue against this: We're in agreement here. 'menu-refresh-fix' fixes a repainting anomaly in production, so I want to put it into master for release at the end of this month--keeping it separate from the 'no-xslfo' work that will be kept out of master until it's fully tested. > So, after saying all this, let me finally answer the question: > > GC> Okay, so I've figured out several ways to do the wrong thing, > GC> and how to revert experimental mistakes. But how can I integrate > GC> https://github.com/vadz/lmi/pull/60 > GC> without altering history prior to the latest release candidate? > > First of all, let's forget about direct-pdf-gen-branch and gwc-no-xslfo, > they still exist as they did before, but it doesn't matter as we won't use > them at all. > > Instead, let's start by returning to master: > > $ git checkout master > > It is presumably always at the latest origin/master (where "origin" is the > remote corresponding to Savannah repository), but it doesn't hurt to check: > > $ git fetch origin /opt/lmi/src/lmi[0]$git checkout master Already on 'master' Your branch is up-to-date with 'origin/master'. /opt/lmi/src/lmi[0]$git fetch origin [...credentials...] /opt/lmi/src/lmi[0]$ > And if this brings any new changes: > > $ git merge --ff-only origin/master /opt/lmi/src/lmi[0]$git merge --ff-only origin/master Already up-to-date. > Now let's examine the new commits in the branch we want to integrate: > > $ git log ..github-vz/menu-refresh-fix > ... shows my 3 commits ... > > We can also check, or confirm, that there are some commits in master that > have been done since this PR > > $ git log github-vz/menu-refresh-fix.. > ... shows your commits postdating my PR ... Confirmed. BTW, is there some place in git-scm.com/docs/ where the syntax of arguments is explained? I don't remember ever seeing a leading or trailing '..', for example. I guess that there's an "empty" argument there that defaults to the current branch name (and adding 'master' in the commands above, then rerunning them, seems to confirm that). > This shows that fast-forwarding is impossible and we now have a choice: > either you just merge the branch into master or your replay the changes > done in the branch onto the newest master. > > The first choice is the "native Git" way of doing things. A simple > > $ git merge github-vz/menu-refresh-fix /opt/lmi/src/lmi[0]$git merge xanadu/menu-refresh-fix Merge made by the 'recursive' strategy. single_choice_popup_menu.cpp | 32 +++++++++++++++----------------- single_choice_popup_menu.hpp | 10 ++-------- 2 files changed, 17 insertions(+), 25 deletions(-) > is enough to do it and while it will indeed create a merge commit, i.e. > result in > > current > master > --- *---*---*--- ... ---*---*------------* new master > \ / > *------*--------* ------------ > menu-refresh-fix > > there is really no problem with this and, in fact, there is an advantage in > seeing that the 3 commits merged into master as one are parts of > logically-related changes. Let's see what that looks like: /opt/lmi/src/lmi[0]$git log --graph --oneline HEAD~4..HEAD * 43aeef7cd Merge remote-tracking branch 'xanadu/menu-refresh-fix' |\ | * 188309c53 Repaint area covered by SingleChoicePopupMenu after showing it | * 4bea744df Don't derive SingleChoicePopupMenu from wxWindow | * c334ae093 Simplify SingleChoicePopupMenu by using wxWidgets functionality * ad4e45100 Improve command to test mirror synchronization with server * ff7a3f5b5 Name konsole tabs more klearly * f8f5ccf00 Synchronize files most recently git-pulled to local mirror This troubles me for a several reasons. A trivial reason is that I imagined 'HEAD~4..HEAD' would show the state before the merge plus three commits, whereas the three commits have become one; perhaps I just need to learn more about how to specify such arguments. A bigger reason, though, is that I see a "|\" line but no "|/" line to match it. It looks like the three commits came out of nowhere (whereas your ASCII art above shows where they came from), and that clashes with some sort of conservation law in my mental model. However, I can resolve that perfectly well by going back farther: /opt/lmi/src/lmi[0]$git log --graph --oneline f79cec^..HEAD * 43aeef7cd Merge remote-tracking branch 'xanadu/menu-refresh-fix' |\ | * 188309c53 Repaint area covered by SingleChoicePopupMenu after showing it | * 4bea744df Don't derive SingleChoicePopupMenu from wxWindow | * c334ae093 Simplify SingleChoicePopupMenu by using wxWidgets functionality * | ad4e45100 Improve command to test mirror synchronization with server [...snip nine lines...] * | 8784138ae Improve documentation |/ * f79cec2b4 Enable and apply stable and security upgrades in chroot and the {|\, |/} symmetry is conserved after all. Therefore, I believe I really do understand this. The final reason why this troubles me is: isn't this a fox-trot merge? If not, why not? Or if so, then why is this one okay when others aren't? > But if you want to preserve the linear history, you have another choice: > replace the 3 commits of the branch on master. This can be done manually by > using "git cherry-pick" to pick the commits one by one: > > $ git cherry-pick github-vz/menu-refresh-fix~2 > $ git cherry-pick github-vz/menu-refresh-fix~1 > $ git cherry-pick github-vz/menu-refresh-fix > > Or it can be done by cherry-picking them all at once: > > $ git cherry-pick ..github-vz/menu-refresh-fix > > (you can check using "git log" that this commit selection expression > results in exactly the same commits). Okay, let's test the hypothesis that this is the same as laboriously copy-pasting patches from the github website and applying them with git-am. I happen to have grabbed the patches that way yesterday, so: /opt/lmi/src/lmi[0]$git am ../stash/0.patch Applying: Simplify SingleChoicePopupMenu by using wxWidgets functionality This is convenient for review, because I can copy the patched file elsewhere: /opt/lmi/src/lmi[0]$cp -a single_choice_popup_menu.?pp ../stash and then diff it with any tool I like (meld, e.g.) against the result of applying the next patch. (I think there's a way to tell git to use a specified alternative tool, but that's not what I'm trying to learn today.) /opt/lmi/src/lmi[0]$git am ../stash/1.patch Applying: Don't derive SingleChoicePopupMenu from wxWindow /opt/lmi/src/lmi[0]$git am ../stash/2.patch Applying: Repaint area covered by SingleChoicePopupMenu after showing it And now the graphical log is linear, and 'HEAD~4..HEAD' means what I thought it would mean: /opt/lmi/src/lmi[0]$git log --graph --oneline HEAD~4..HEAD * 6923da91a Repaint area covered by SingleChoicePopupMenu after showing it * 07ef56d66 Don't derive SingleChoicePopupMenu from wxWindow * f019e04ca Simplify SingleChoicePopupMenu by using wxWidgets functionality * ad4e45100 Improve command to test mirror synchronization with server This git-am process, though balky, is already deep inside my comfort zone, so let's see if we can ditch the balkiness: /opt/lmi/src/lmi[0]$git reset --hard ad4e45100 HEAD is now at ad4e45100 Improve command to test mirror synchronization with server /opt/lmi/src/lmi[0]$git cherry-pick ..xanadu/menu-refresh-fix [master 1ddf486fc] Simplify SingleChoicePopupMenu by using wxWidgets functionality Author: Vadim Zeitlin Date: Wed Oct 25 23:02:29 2017 +0200 2 files changed, 2 insertions(+), 18 deletions(-) [master 004e4381e] Don't derive SingleChoicePopupMenu from wxWindow Author: Vadim Zeitlin Date: Wed Oct 25 23:08:17 2017 +0200 2 files changed, 6 insertions(+), 9 deletions(-) [master 86b0c8333] Repaint area covered by SingleChoicePopupMenu after showing it Author: Vadim Zeitlin Date: Wed Oct 25 23:14:29 2017 +0200 1 file changed, 11 insertions(+) Although I cherry-picked everything in one combined operation here because I had already reviewed each change previously, it's good to know that I can cherry-pick the commits individually. /opt/lmi/src/lmi[0]$git log --graph --oneline HEAD~4..HEAD * 86b0c8333 Repaint area covered by SingleChoicePopupMenu after showing it * 004e4381e Don't derive SingleChoicePopupMenu from wxWindow * 1ddf486fc Simplify SingleChoicePopupMenu by using wxWidgets functionality * ad4e45100 Improve command to test mirror synchronization with server It does indeed appear equivalent to the git-am procedure. It's not identical in the sense of matching the SHA1s, but I recall from earlier discussions of the git-am workflow we use for a proprietary repository that SHA1s depend upon fine details (e.g., author vs. committer time stamps) that are convenient to ignore in cases like this. Just to make sure: if I expand the scope of the git-log argument: /opt/lmi/src/lmi[0]$git log --graph --oneline f79cec^..HEAD there's nothing unexpected: it's all linear. Compared to the "native git" strategy above: git merge xanadu/menu-refresh-fix the advantage of linearity comes at the expense of preserving the branch-and-merge nature. We can no longer see the merge-base of the branch, but that's not important anyway because this set of three commits doesn't collide with any changes in the linear history. In a way, it's as though you had rebased your changeset on today's master HEAD, and I had then applied it as a fast-forward merge. And only after writing that do I understand this: > Or, and this is probably the most confusing, but also the most powerful > and, in practice, most useful, way by doing "git rebase" > > $ git branch gwc-menu-refresh-fix github-vz/menu-refresh-fix > $ git checkout gwc-menu-refresh-fix [...] > $ git rebase master > > It looks like nothing happened as you still have the same (or almost, their > SHA-1s have changed) commits on your branch. Except that instead of > > --- *---*---*--- ... 8 more ... ---*---M master > \ > A---B---C gwc-menu-refresh-fix > > things now looks like this: > > --- *---*---*--- ... 8 more ... ---*---M---A'---B'---C' gwc-menu-refresh-fix > > (notice that master is still unchanged and continues to point to "M"). > > And this is important because it means that _now_ you can fast-forward > master to this branch, so let's do just this: > > $ git checkout master > $ git merge --ff-only gwc-menu-refresh-fix ....which seems to say exactly the same thing, right? (I had skipped that section on first reading your email because it seemed so abstruse. I had to discover the underlying motivation for myself, I guess; and now I can understand it in retrospect as a step-by-step guide.) > Also note that if you want to change something in my commits before > applying them, there is a simple way to do it with "git rebase -i": please > let me know if/when you'd like to know more about it. As a general rule, I imagine that it's an excellent idea to adopt your changes as given and only then modify them (if desired) in a separate, subsequent step. That way, you can see whether or not I've applied all of your changes faithfully; and, if an error is introduced, we can determine who introduced it. This seems far better than a modify-while-adopting approach whereby I commit altered versions of your changes, with the woeful effect that the point where a defect was introduced cannot be ascertained. Thanks for an informative discussion. In this case, I'll use the cherry-pick method and push the z-order changes presently. From MAILER-DAEMON Sun Nov 05 17:43:48 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eBTds-0005Zj-AN for mharc-lmi@gnu.org; Sun, 05 Nov 2017 17:43:48 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39339) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eBTdp-0005Zd-Vk for lmi@nongnu.org; Sun, 05 Nov 2017 17:43:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eBTdl-0000o7-PJ for lmi@nongnu.org; Sun, 05 Nov 2017 17:43:46 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:49346 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eBTdl-0000m2-9n for lmi@nongnu.org; Sun, 05 Nov 2017 17:43:41 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eBTde-00087A-Hk for lmi@nongnu.org; Sun, 05 Nov 2017 23:43:34 +0100 Date: Sun, 5 Nov 2017 23:43:33 +0100 From: Vadim Zeitlin To: "Let me illustrate..." MIME-Version: 1.0 References: <5c40e07b-88ff-8df9-8b20-37bba71c5362@sbcglobal.net> In-Reply-To: <5c40e07b-88ff-8df9-8b20-37bba71c5362@sbcglobal.net> X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 82.240.17.225 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: [lmi] wxProgressDialog z-order anomaly X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 22:43:47 -0000 On Sun, 5 Nov 2017 17:49:49 +0000 Greg Chicares wrote: [...] To avoid making this email even longer than necessary, I'm trimming all parts of your email that don't contain any questions and that I don't have any comments about. I hope you don't mind this, but please let me know if I missed any (perhaps implicit, because I do think I got all the explicit ones) questions to be answered. GC> BTW, is there some place in git-scm.com/docs/ where the syntax of GC> arguments is explained? Yes: the reference documentation is at https://git-scm.com/docs/gitrevisions (also accessible as "man gitrevisions" locally) and a more tutorial-like introduction can be found in e.g. https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection GC> I don't remember ever seeing a leading or trailing '..', for example. I GC> guess that there's an "empty" argument there that defaults to the GC> current branch name (and adding 'master' in the commands above, then GC> rerunning them, seems to confirm that). Yes, the omitted argument is taken to be HEAD (and in your case HEAD is master). [...] GC> The final reason why this troubles me is: isn't this a fox-trot merge? GC> If not, why not? Or if so, then why is this one okay when others aren't? It is not what is called a fox-trot merge (which is not an official term, BTW, and I'm not sure if I really like it as it seems not very clear to me but, admittedly, I'm not the best person to ask about dance-related terms). To answer the "why not" question, a fox-trot merge is, by definition, a merge which has origin/master as its second parent, i.e. it's a merge of origin/master into some other branch (which may, and usually is, the local master). This one merges a topic branch into master, which always is, and remains, collinear with origin/master, so it's a perfectly normal and good merge. To make it even more explicit: a fox-trot merge would happen if you had done this merge (or any other local changes), while in the meanwhile I would have committed something to origin/master and then, usually by just doing "git pull" you would have merged origin/master again into your master, before pushing it out. Git itself doesn't care about fox-trot merges, but they make history more confusing as in the example just above there is no good reason why origin/master should have been merged into, basically, itself. The end result would still be the same but it would be more clear if this fox-trot merge didn't exist. [...] GC> (I think there's a way to tell git to use a specified alternative tool, GC> but that's not what I'm trying to learn today.) Yes, see e.g. "git difftool --help". As you might have heard before, I recommend just using Vim-fugititve. [...] GC> In a way, it's as though you had rebased your changeset on today's GC> master HEAD, and I had then applied it as a fast-forward merge. Exactly. GC> And only after writing that do I understand this: GC> GC> > Or, and this is probably the most confusing, but also the most powerful GC> > and, in practice, most useful, way by doing "git rebase" [...] GC> ....which seems to say exactly the same thing, right? Yes. Again, "git rebase" can do [much] more, but at the most basic level it just automates cherry-picking many commits in a row and its extra features just add other things to do before or after cherry-picking. GC> > Also note that if you want to change something in my commits before GC> > applying them, there is a simple way to do it with "git rebase -i": please GC> > let me know if/when you'd like to know more about it. GC> GC> As a general rule, I imagine that it's an excellent idea to adopt GC> your changes as given and only then modify them (if desired) in a GC> separate, subsequent step. That way, you can see whether or not GC> I've applied all of your changes faithfully; and, if an error is GC> introduced, we can determine who introduced it. This seems far GC> better than a modify-while-adopting approach whereby I commit GC> altered versions of your changes, with the woeful effect that GC> the point where a defect was introduced cannot be ascertained. From my point of view, the preferred order for integrating my changes is: 1. Merge my changes (maybe after doing more commits in the branch, fixing/adding things, of course). 2. Cherry-pick (as you did) or rebase my branch to ff-merge it (again, maybe with extra changes in separate commits). . . . 99. Apply slightly different but not identical changes as different commits. (1) is ideal because I can just delete my branch after the merge: this will only work if the merge really did happen and I can be sure that no commits were left/forgotten. A nice extra benefit of (1) is that GitHub will automatically close the PR opened for the branch as it detects that the branch was merged. (2) is not really much more trouble because I can just rebase my branch on the latest master and Git will skip all already applied commits _if_ they are identical: it's smart enough to know that commits with different metadata can still have identical body (so you can change timestamps, commit parents and even commit messages if you want to reword them, this is not a problem as long as the commit body is exactly the same), so rebasing will happen quickly and confirm, again, that no unapplied changes remain. (99) is the worst because it can't be handled in any automatic way. If I want to check whether all changes were applied, I still need to rebase, but this will now result in conflicts for each modified commit, and each such conflict will need to be painstakingly resolved. With many commits (e.g. ~150 in the direct-pdf-gen branch) this becomes prohibitively time-consuming and so it's easier to just delete the branch and just trust you to have merged it without forgetting anything -- which is, of course, not a problem on its own, but I'd still rather have Git safety-net. GC> Thanks for an informative discussion. In this case, I'll use GC> the cherry-pick method and push the z-order changes presently. FWIW everything seems to have worked just fine and I've just rebased my branch on master and confirmed that there are no changes remaining and closed the PR (as well as a couple of other ones that I forgot to close when they were taken care of, leaving only a single still relevant one at https://github.com/vadz/lmi/pull/56). Thanks for merging this! VZ From MAILER-DAEMON Thu Nov 09 11:46:18 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eCpy5-0007Ua-W4 for mharc-lmi@gnu.org; Thu, 09 Nov 2017 11:46:18 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35829) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCpy4-0007UP-3M for lmi@nongnu.org; Thu, 09 Nov 2017 11:46:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eCpxz-0000mW-8r for lmi@nongnu.org; Thu, 09 Nov 2017 11:46:16 -0500 Received: from sonic315-16.consmr.mail.bf2.yahoo.com ([74.6.134.126]:36568) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eCpxz-0000lL-0v for lmi@nongnu.org; Thu, 09 Nov 2017 11:46:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1510245957; bh=ynL5WHv5lSOdQZpLyoqHiUWMUI0RquRdtek8zFi8loM=; h=To:From:Subject:Date:From:Subject; b=DpZNkQzM0rw4W9km9jEEfvo01d8dZ/d5QdgJSh8VOeiVpb5u5kVZhBC/4fNWhuYvUfmEw75iTyt/ijSeOKA9N/0IaLZb9Wy+SeUN1STPDSi+r6Gd6Z4jlQTf/oRZ87AcabmVS0OeEv/LbEtEfN+gr+qKhpuBlzGLlmpbg/Sezoboq0UMC8HTNXrqwdwyBp/QtPex0H6Z+34ZRispZDRixq3cOCX7eWbf4csSwJ0qwZXf8jY5UHwEBoqv5NSAOTH+Xn8PK/55SPxUqofPoRW9sfOzNbUKeR9nUqzsW5H9VsXAqG5EYoS1/gZNKn/1rLSBFlX3/EDIHkwidOdvBQ3BeQ== X-YMail-OSG: RXRT0f8VM1nH49bQWOz6V3MK1LBdnsTggxoUFP6yrVL6zf2mmPfOVDNtYCIx89s obw20OaBoOBvvNTGge8NFz0HbkVYgMb1WbVYov4b7VoGXWzsQUl.d9nKKIZNfBSK613SdYziAcZG sHPDCqxmkthn888XEeAud9cUjOcUk8Yr7FKIGBd_Bn0KcpkcN48m7qEz6UHgZD8_8EXIPrgraqZB zUr.bSoIjheNr66dc_AjE9KnZPrIrfCHKYsQnV3Urq6sPIisLcR8uFaV51inGLlbMAvEI6y46r89 Hyc8Bi2wzjdz8Zrz0R_SZCl_id_IbnmtFE.rKFVuAHeM1H6.Rv9K5JvqknNSGDLwm6zVAeXYnFLM OGZXK3MEx.JaRdvDU4Oyl8YJbrJZtnFwgQ5vJEFqXCl8WauY7okTIgP954g2QqIwGGnqLNZgop9h g992Vl2nHGmRUDV4jFcahSXH09cu1qI_PG0Buz_cTlidHl0u9hhDcxAh5Jo3kjP4UvqOgRHOXGSp 5vzVeNw9mqDp86L3VxdOJgOTt.ZBAYAmzSv5hj.pPSnZCE17XRz66dggyXrQSakw- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Thu, 9 Nov 2017 16:45:57 +0000 Received: from [127.0.0.1] by smtp115.sbc.mail.bf1.yahoo.com with NNFMP; 09 Nov 2017 16:45:54 -0000 X-Yahoo-Newman-Id: 643766.20220.bm@smtp115.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: RXRT0f8VM1nH49bQWOz6V3MK1LBdnsTggxoUFP6yrVL6zf2 mmPfOVDNtYCIx89sobw20OaBoOBvvNTGge8NFz0HbkVYgMb1WbVYov4b7VoG XWzsQUl.d9nKKIZNfBSK613SdYziAcZGsHPDCqxmkthn888XEeAud9cUjOcU k8Yr7FKIGBd_Bn0KcpkcN48m7qEz6UHgZD8_8EXIPrgraqZBzUr.bSoIjheN r66dc_AjE9KnZPrIrfCHKYsQnV3Urq6sPIisLcR8uFaV51inGLlbMAvEI6y4 6r89Hyc8Bi2wzjdz8Zrz0R_SZCl_id_IbnmtFE.rKFVuAHeM1H6.Rv9K5Jvq knNSGDLwm6zVAeXYnFLMOGZXK3MEx.JaRdvDU4Oyl8YJbrJZtnFwgQ5vJEFq XCl8WauY7okTIgP954g2QqIwGGnqLNZgop9hg992Vl2nHGmRUDV4jFcahSXH 09cu1qI_PG0Buz_cTlidHl0u9hhDcxAh5Jo3kjP4UvqOgRHOXGSp5vzVeNw9 mqDp86L3VxdOJgOTt.ZBAYAmzSv5hj.pPSnZCE17XRz66dggyXrQSakw- X-Yahoo-SMTP: mjD.OBqswBAPbVUxYJaYPvc61jLEnpq8VnBwJGdbEJOPA9xw To: "Let me illustrate..." From: Greg Chicares Message-ID: <192110b6-fe72-34b8-25d7-bf6d0c896af3@sbcglobal.net> Date: Thu, 9 Nov 2017 16:45:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.6.134.126 Subject: [lmi] 'cp' fails with "permission" error X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 16:46:16 -0000 Vadim--On a new machine in the office (configured by corporate IT) we observe: cp --preserve /cache_for_lmi/downloads/md5sum.exe /opt/lmi/third_party/bin cp: failed to preserve ownership for '/opt/lmi/third_party/bin/md5sum.exe': Permission denied make: *** [install_miscellanea.make:219: md5sum_msw] Error 1 How would we go about debugging this? I'm guessing the answer involves something like 'icacls', but I know nothing about msw permissions since the msw-xp era. (I thought this was supposed to be an msw-10 machine, but cygwin diagnostics identify it as msw-7.) From MAILER-DAEMON Thu Nov 09 15:29:31 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eCtS7-0001gi-RO for mharc-lmi@gnu.org; Thu, 09 Nov 2017 15:29:31 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36649) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCtS5-0001fH-49 for lmi@nongnu.org; Thu, 09 Nov 2017 15:29:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eCtS1-0002cN-TB for lmi@nongnu.org; Thu, 09 Nov 2017 15:29:29 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:50168 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eCtS1-0002UH-Ix for lmi@nongnu.org; Thu, 09 Nov 2017 15:29:25 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eCtRw-0008GX-9v for lmi@nongnu.org; Thu, 09 Nov 2017 21:29:20 +0100 Date: Thu, 9 Nov 2017 21:29:20 +0100 From: Vadim Zeitlin To: "Let me illustrate..." MIME-Version: 1.0 References: <192110b6-fe72-34b8-25d7-bf6d0c896af3@sbcglobal.net> In-Reply-To: <192110b6-fe72-34b8-25d7-bf6d0c896af3@sbcglobal.net> X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 82.240.17.225 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: [lmi] 'cp' fails with "permission" error X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 20:29:30 -0000 On Thu, 9 Nov 2017 16:45:52 +0000 Greg Chicares wrote: GC> Vadim--On a new machine in the office (configured by corporate IT) GC> we observe: GC> GC> cp --preserve /cache_for_lmi/downloads/md5sum.exe /opt/lmi/third_party/bin GC> cp: failed to preserve ownership for '/opt/lmi/third_party/bin/md5sum.exe': Permission denied GC> make: *** [install_miscellanea.make:219: md5sum_msw] Error 1 GC> GC> How would we go about debugging this? I'm guessing the answer GC> involves something like 'icacls', but I know nothing about GC> msw permissions since the msw-xp era. GC> GC> (I thought this was supposed to be an msw-10 machine, but cygwin GC> diagnostics identify it as msw-7.) Hello, First of all, I wonder if using the "--preserve" cp option is really crucial here? POSIX ownership/permissions maps only imperfectly on MSW ACL-based security model, so why insist on propagating them? I'd say that if everything works fine without "--preserve" on this machine, then nothing would be lost by just dropping it. If things don't work when doing just a simple copy, e.g. if the file loses its "executable" status, then you do need to use icacls (or cacls, which is deprecated, but still works fine under MSW 7 AFAIK) to gather more information. I'd start by running just "icacls c:/opt/lmi/third_party/bin" to see if there are any unusual ACLs associated with this directory and, maybe, do the same for its parent directories, recursively. I expect the current user doesn't have full control ("(F)" in icacls output) over that directory, but I can't say much more than that and I don't know what fix would be appropriate as this depends on the local security policies that I also don't know anything about. Sorry if this is not particularly helpful, VZ From MAILER-DAEMON Fri Nov 10 12:59:25 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eDDaP-0004N3-OB for mharc-lmi@gnu.org; Fri, 10 Nov 2017 12:59:25 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55317) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eDDaM-0004M4-C2 for lmi@nongnu.org; Fri, 10 Nov 2017 12:59:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eDDaI-0000vb-1M for lmi@nongnu.org; Fri, 10 Nov 2017 12:59:22 -0500 Received: from sonic302-7.consmr.mail.bf2.yahoo.com ([74.6.135.46]:39444) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eDDaH-0000uW-Q7 for lmi@nongnu.org; Fri, 10 Nov 2017 12:59:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1510336754; bh=1T0Yilp7Z7oLV7KWr1ChbaaxiIDRak9HZOPI5Xf0xG8=; h=Subject:From:To:References:Date:In-Reply-To:From:Subject; b=Ic01Hy4qD/66sPqOM7dHrRxVPDD+dcEcKbbUQpE6F3u0BCJNYxWjX4otT91LChbl6GWFGeIsm35QnJSk2YA4gyJfIi4+qeLI33jTzZUAIvRGnC3GlzjDrLijXiKVG/i3twjzMCc1LXQjRf2pSqCo04S7hZubxOKSdxpIfpwFbXtizUVOaS+KTJVk0MNR1ADh9HUEn8oVZuzTWbBvonoZoiqy5pWgwH2zwyNCzxwB6S64AImh3aNE2nuj+vGJP/nCAfpzZo4pgtSDMEXg3wJvlbuADVGn5oSdmEpDs4ATXijWUUwii/bbcqt/8Rn+JhpPC3d/DYjw6tEm0y7lSR+4lQ== X-YMail-OSG: z10x_LgVM1np1VeBpf1DqSzHyMeCZOA4Bf.N3ofx4VKzlXPylmTffjS2VoIvbru b1torY7QebdD69bGnBUdM5SKS2P.tHax7Nas6pjLlBZ286_98TFUeH96zWoJDgTHOG1wCLIp2Pr_ 4NTjfvdDZNZttGC7z3yuB8R.CoYf5mlboUnm01x9j9ZzHNRctt76uaM_DzE1hYWw3sjriqIG4oN. gaPUd81FZbVFJolecJ2MCrRbvPnbTMooyy68qvPuLm1qBIMIMmn4boQlpDncxVhxtPGo3gUshK6c Sd3Kyt5Vxzs6M3yOWiKkLy3XYDqclTLpxgrpzOtPBqoFT9n0BO6rAPWC6Ls7gK0URwAnaK4DYcj2 WavHmne22Jrw1W8U994km7fDTwbGl3cZnu9Jk75.J8njYTa2WmHmE2spNWoBCcYKY8muqp7nx549 6t5geoiKaCjOMg7CN_1cBRGS1jfxo4DoFwUVaYsyeYRBu0HMa5D_KRAFaqgCuvSqmw1y_2_7YghM sLDpUBkMXywdJrVqCV..7FnqAAcpK7ix72BvBjWK.jFmjZonEhT9Ky9xmD85rLY4- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Fri, 10 Nov 2017 17:59:14 +0000 Received: from [127.0.0.1] by smtp120.sbc.mail.bf1.yahoo.com with NNFMP; 10 Nov 2017 17:59:11 -0000 X-Yahoo-Newman-Id: 259824.34396.bm@smtp120.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: z10x_LgVM1np1VeBpf1DqSzHyMeCZOA4Bf.N3ofx4VKzlXP ylmTffjS2VoIvbrub1torY7QebdD69bGnBUdM5SKS2P.tHax7Nas6pjLlBZ2 86_98TFUeH96zWoJDgTHOG1wCLIp2Pr_4NTjfvdDZNZttGC7z3yuB8R.CoYf 5mlboUnm01x9j9ZzHNRctt76uaM_DzE1hYWw3sjriqIG4oN.gaPUd81FZbVF JolecJ2MCrRbvPnbTMooyy68qvPuLm1qBIMIMmn4boQlpDncxVhxtPGo3gUs hK6cSd3Kyt5Vxzs6M3yOWiKkLy3XYDqclTLpxgrpzOtPBqoFT9n0BO6rAPWC 6Ls7gK0URwAnaK4DYcj2WavHmne22Jrw1W8U994km7fDTwbGl3cZnu9Jk75. J8njYTa2WmHmE2spNWoBCcYKY8muqp7nx5496t5geoiKaCjOMg7CN_1cBRGS 1jfxo4DoFwUVaYsyeYRBu0HMa5D_KRAFaqgCuvSqmw1y_2_7YghMsLDpUBkM XywdJrVqCV..7FnqAAcpK7ix72BvBjWK.jFmjZonEhT9Ky9xmD85rLY4- X-Yahoo-SMTP: mjD.OBqswBAPbVUxYJaYPvc61jLEnpq8VnBwJGdbEJOPA9xw From: Greg Chicares To: "Let me illustrate..." References: <56DDC545.7060506@sbcglobal.net> <56EEFF07.4090506@sbcglobal.net> Message-ID: <3544b675-4fda-9b9a-7809-f6ad9679fb3d@sbcglobal.net> Date: Fri, 10 Nov 2017 17:59:09 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <56EEFF07.4090506@sbcglobal.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.6.135.46 Subject: Re: [lmi] Proposed workflow for proprietary repository X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 17:59:24 -0000 On 2016-03-20 19:50, Greg Chicares wrote: [...] > Here's how to create a bundle to share by email. Make any number of > changes to the local repository, and commit them in whatever groups > make sense: > > cd /opt/lmi/proprietary > git commit --all -m"One set of changes" > git commit --all -m"Another set of changes" > > When it's ready to share, do this: > > cd /opt/lmi/proprietary > git bundle create YourBundleName ^origin/master HEAD --branches > > (using a more descriptive name) and send the file as an email > attachment. Vadim--This has worked perfectly until about a month ago. Since then, every time Kim prepares a bundle, permissions on many files get changed. Please help us figure out how to prevent this. Applying a bundle sent yesterday (possibly from a new machine configured by corporate IT), I see: data/NAME-REDACTED.database | 4 ++-- [for each of six files] src/my_db.cpp | 12 ++++++------ That's six files with four lines changed in each (24) plus one with 12, for a total of 36, which is the same total as the summary line: 1030 files changed, 18 insertions(+), 18 deletions(-) but there are just over a thousand lines like this: data/sample.database | 0 and then another thousand or so like this: mode change 100644 => 100755 data/sample.database No binaries are stored in this proprietary repository, and no scripts outside its hooks/ directory, so we really do want 644 for everything except for these two hooks/ scripts that should use 755: /opt/lmi/proprietary[0]$ls -o hooks/ total 8 -rwxr-xr-x 1 greg 1216 Aug 17 20:12 commit-msg -rwxr-xr-x 1 greg 1662 Aug 17 20:12 pre-commit Both those scripts are identical to the corresponding scripts in the public savannah repository except that the pre-commit hook recursively runs 'make check_concinnity' in all subdirectories of the proprietary repository. But that makefile target diagnoses these mode changes as errors and should have blocked the commit. My guess is that the script wasn't run in this case because the msw filesystem migration failed to preserve cygwin symlinks, and we must do this: cd /opt/lmi/proprietary ln --symbolic --force --no-dereference ../hooks .git manually each time we get a new machine. However, that technique only _detects_ undesirable permission changes, yet I'd like to find a way to _prevent_ such problems from arising. For example, several hundred of these files are freshly regenerated by msw-native programs (rather than being migrated from another machine), and it would be helpful to intercept and reverse permission changes before a git bundle is created. I hesitate to suggest doing the following (for cygwin only): git config core.filemode false because it seems like a kludge, and data files really shouldn't ever have the executable bit set. I'm thinking of adding appropriate commands at the beginning of the pre-commit hook, something like [not quite correct]: chmod +R -x+X in the hope that this will prove inexpensive and perfectly robust. If that sounds like a good idea, could you help me figure out how to write the command correctly? [...here, as so often, my stream of consciousness leads me through a thicket of ideas whose inutility becomes apparent only after they have been written out, and I'm unwilling to delete them in case I've dismissed good ideas for bad reasons, but it seems only polite to suggest you read from the bottom up, starting with section [3] and stopping at the bottommost line where the problem is well solved...] [1] I wrote "-x+X" above to remove execute permission yet retain the flag that makes directories work normally, but even if that's what it really does, it's not right because some files really should be executable. I've seen commands like these suggested, e.g. on stackoverflow: # First make subdirectories accessible: find . -type d -print0 | xargs -0 chmod 755 # Then remove execute permission on all files: find . -type f -print0 | xargs -0 chmod 644 # Then restore execute permission on selected files: find . -name '*.sh' -type f | xargs chmod +x where they always lead to arguments: some commenters want to avoid 'find ... xargs', while others suggest slight syntax changes. The rules I seem to want are: +X for directories -x for most files +x for '*.sh', '*.sed', 'hooks/*', and 'debian/rules' but that feels wrong because it doesn't provide for new files that should be executable...and now I see that I forgot to mention the scripts under lmi's tabs/ subdirectory. [2] Maybe I should invert the sense of this, recognizing that Kim isn't going to add any executable file ever and that the only problem is "+x" leaking through from her msw+cygwin setup, so perhaps I could come up with a reliable list of files that should never have "+x": md5sums *.txt *.?pp *.cns *.gpt *.ill *.mec *.ini *.inix *.database *.funds *.policy *.rounding *.strata *.rates Ewww--on second thought, that doesn't seem like a good approach; and, oops, I forgot '*Log' and probably some others. [3] For my third attempt, I observe that this rule in 'GNUMakefile' has worked very well for years: @$(LS) --classify ./* \ | $(SED) -e'/\*$$/!d' -e'/^\.\//!d' -e'/.sh\*$$/d' -e'/.sed\*$$/d' \ | $(SED) -e's/^/Improperly executable: /' for each directory in which we run 'make check_concinnity' (which excludes hooks/ and debian/). And the pre-commit hook for the proprietary repository already names every subdirectory we care about (and would have to be modified anyway if we ever add another subdirectory, but that might happen once a decade): printf "checking " printf "src..." cd $toplevel/src && check_concinnity printf "data..." cd $toplevel/data && check_concinnity printf "test..." cd $toplevel/test && check_concinnity printf "tables..." cd $toplevel/tables && check_concinnity so maybe I should just copy that logic...or restructure it thus: for d in src data test tables; do \ printf "$d..." && cd $toplevel/$d && MAGICAL_COMMAND \ done and then just ask your opinion on what MAGICAL_COMMAND should be. Maybe use some 'find ... xargs' thing to exclude '*.sh' and '*.sed', and apply 'chmod -x' to every file not excluded? E.g. [untested]: find . -name '*.sh' -o -name '*.sed' -type f | xargs chmod -x Would that work reliably in a directory with thousands of files? (I think is should, and that's why we use 'find', but I don't understand this stuff very well.) From MAILER-DAEMON Fri Nov 10 17:17:09 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eDHbp-0007XC-JX for mharc-lmi@gnu.org; Fri, 10 Nov 2017 17:17:09 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48397) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eDHbm-0007W8-V9 for lmi@nongnu.org; Fri, 10 Nov 2017 17:17:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eDHbh-00073y-Ve for lmi@nongnu.org; Fri, 10 Nov 2017 17:17:06 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:38510 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eDHbh-00072Z-G8 for lmi@nongnu.org; Fri, 10 Nov 2017 17:17:01 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eDHbd-00057Y-6k for lmi@nongnu.org; Fri, 10 Nov 2017 23:16:57 +0100 Date: Fri, 10 Nov 2017 23:16:52 +0100 From: Vadim Zeitlin To: "Let me illustrate..." MIME-Version: 1.0 References: <56DDC545.7060506@sbcglobal.net> <56EEFF07.4090506@sbcglobal.net> <3544b675-4fda-9b9a-7809-f6ad9679fb3d@sbcglobal.net> In-Reply-To: <3544b675-4fda-9b9a-7809-f6ad9679fb3d@sbcglobal.net> X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 82.240.17.225 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: [lmi] Proposed workflow for proprietary repository X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 22:17:08 -0000 On Fri, 10 Nov 2017 17:59:09 +0000 Greg Chicares wrote: GC> On 2016-03-20 19:50, Greg Chicares wrote: GC> [...] GC> > Here's how to create a bundle to share by email. Make any number of GC> > changes to the local repository, and commit them in whatever groups GC> > make sense: GC> > GC> > cd /opt/lmi/proprietary GC> > git commit --all -m"One set of changes" GC> > git commit --all -m"Another set of changes" GC> > GC> > When it's ready to share, do this: GC> > GC> > cd /opt/lmi/proprietary GC> > git bundle create YourBundleName ^origin/master HEAD --branches ^^^^^^^^^^^^^^^^^^^ This is off-topic, but I'd just like to note that now that you're aware of Git "A..B" notation, you could replace this part with "origin/master..HEAD" which is a bit a more understandable IMHO as closer to the standard interval notation (except in Git intervals are open-closed semi-intervals). GC> > (using a more descriptive name) and send the file as an email GC> > attachment. GC> GC> Vadim--This has worked perfectly until about a month ago. Since then, GC> every time Kim prepares a bundle, permissions on many files get changed. GC> Please help us figure out how to prevent this. Brief answer is to set core.filemode to false. When I started to use Git with Cygwin (admittedly, this was a long -- was it really 9 years?? -- time ago), I experimented with different settings/combinations of file modes/ACLs and this was the only possibility to make things work reliably. Maybe things have changed since then, but your experience seems to disprove this and in any case the one thing I'm sure about is that they still work fine with core.filemode set to false. Additionally, my ~/.gitconfig has this comment: [core] # setting this to false make git status twice faster because # ignoreCygwinFSTricks is turned on by default then filemode = false and while, again, things could have changed since then, but this did have a big effect on Git performance back then and Git documentation still mentions 2x speedup from it. GC> Applying a bundle sent yesterday (possibly from a new machine configured GC> by corporate IT), I see: GC> GC> data/NAME-REDACTED.database | 4 ++-- [for each of six files] GC> src/my_db.cpp | 12 ++++++------ GC> GC> That's six files with four lines changed in each (24) plus one with 12, GC> for a total of 36, which is the same total as the summary line: GC> GC> 1030 files changed, 18 insertions(+), 18 deletions(-) GC> GC> but there are just over a thousand lines like this: GC> GC> data/sample.database | 0 GC> GC> and then another thousand or so like this: GC> GC> mode change 100644 => 100755 data/sample.database If you really want to debug this, you need to look at MSW ACL for this file, using cacls or icacls as discussed just recently. Of course, even if you see that some ACL is unexpectedly set or unset, it won't necessarily help that much, but we need to start with at least something. Also, I'm not completely sure if the file is actually executable on the machine where "git bundle" was made, could you please confirm whether it is the case? GC> [...] yet I'd like to find a way GC> to prevent such problems from arising. For example, several hundred GC> of these files are freshly regenerated by msw-native programs (rather GC> than being migrated from another machine), and it would be helpful to GC> intercept and reverse permission changes before a git bundle is GC> created. Unfortunately I don't think there are any hooks invoked during git bundle creation. And, anyhow, detecting the problem at this moment could be too late to be helpful. So the only solution I see is to indeed ensure that commit hooks check for this -- and are executed, of course. Maybe you could print something from the commit hook even if all checks passed successfully (of course, I advise this, but I'd hate it for the main lmi repository...) and ask everybody committing to it to check that this message was given. GC> I hesitate to suggest doing the following (for cygwin only): GC> git config core.filemode false GC> because it seems like a kludge, and data files really shouldn't ever GC> have the executable bit set. Honestly, if this solves the problem -- and I think it ought to -- I'd do it without a second thought. Yes, core.files is a kludge, but then the entire concept of Cygwin is a kludge anyhow, so I don't think it's worth fighting for immaculate purity when using it. GC> I'm thinking of adding appropriate commands at the beginning of the GC> pre-commit hook, something like [not quite correct]: GC> chmod +R -x+X GC> in the hope that this will prove inexpensive and perfectly robust. GC> If that sounds like a good idea, could you help me figure out how GC> to write the command correctly? [...] GC> Maybe use some 'find ... xargs' thing to exclude '*.sh' and '*.sed', GC> and apply 'chmod -x' to every file not excluded? E.g. [untested]: GC> GC> find . -name '*.sh' -o -name '*.sed' -type f | xargs chmod -x GC> GC> Would that work reliably in a directory with thousands of files? GC> (I think is should, and that's why we use 'find', but I don't GC> understand this stuff very well.) I guess it's just a typo, but the logic of the command above is reversed: there should be a -not (or "!" if you want to be POSIX compliant) or two here and it should be something like this (still untested) instead: find . \! -name '*.sh' \! -name '*.sed' -type f | xargs chmod -x (of course, you can rewrite this "!A & !B" as "!(A | B)" if you prefer, but this would require quoting even more characters from the shell). Other than that the command looks fine to me. Purists would argue that you should use "find -printf0" and "xargs -0", but as long as you avoid white space in your file names (which is an excellent idea anyhow), this is not necessary. And I think the idea of making non-executable all but whitelisted files is a better one than blacklisting some files because if you add another category of files that should be executable and their executable bit is reset by this script, it will get noticed much sooner than if you add some new type of non-executable files and forget to blacklist it. Regards, VZ From MAILER-DAEMON Fri Nov 10 19:33:23 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eDJjf-0004ZL-8E for mharc-lmi@gnu.org; Fri, 10 Nov 2017 19:33:23 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44184) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eDJjc-0004ZC-Hp for lmi@nongnu.org; Fri, 10 Nov 2017 19:33:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eDJjZ-0007uM-BD for lmi@nongnu.org; Fri, 10 Nov 2017 19:33:20 -0500 Received: from sonic303-7.consmr.mail.bf2.yahoo.com ([74.6.131.46]:40148) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eDJjZ-0007u3-5F for lmi@nongnu.org; Fri, 10 Nov 2017 19:33:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1510360394; bh=p+7mzMx/3ECZzzGWK61a7BMpG+iSepnXKHZIZ9/yb2g=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=FLVRxQDN9Kw5EgtyioV6NqdjUdzU4tKtH5n1nlEBeGlApUA7weMbv1mFnkJBqpINcb4WDVo4ajj8+hwn5SdKzGvIrQBQmsExJPh73SfETcXnKl9q88fULYKR5Olfudrx0EEdOjVsxnoiJEaF0869OHtD1w1aWfMiDcxZdyk9kVSs13rDW1I9eXo5Hyt5sLdDNWVS12naha6bcxEVMNP08Y4mjp7VcE69vY48Mv1xKLx7VrG+RjfLrY3fnjfXFxpvu0Jtf20ATlCC0HVVD0+71G+U1PDOqnnwtHHkAJ8T09FEcId8b07fVNsJAWQWMJ11vajDuoowWG2ZPSq439ZJvQ== X-YMail-OSG: 6V6bLg8VM1kHvndTqfPLk9sZE1AlYmqed3c1xfhyXrSiukLce3TZ3JAW3AWw1cf UAEXIgHCzrd_8BHYG189diLFWyYlP_HiK81nO08OV8Lx0KlSos_Vvo2skylZGoY2H3efpWeRhYuK PkAymXgiEwIU8LtJ8z9NF2AmkI_uUs_9OpGInUCZBOgcNRwrchRs_VZJzzEweUlZkmOukt1tYE7u B8ahK1VAaeoDSqzRiHSPPHpQ8Pr8dMTqABfRL7UzfSI1rg.Y4u2QQZbh2NMcDb7gO7M6FclQtvEN itkdDremjCryGUpNDMvStvk8EprwacQeDleo97MgC767_5WcyLbKT7BxIHWZvXer7cJvbsNYg6JA 7vD0gmmE7aZ1RvcI2zjZ0r4.hKLElPqrfktOpQYnnKNaG6D763qMurdov8gR7mkhT1BhiiYiMOk2 MrkU5cgza.qRzVhOcy9kDUlVAReEZUagrO9tDBeX9Ej2lPQHAyB1JrX.tyVfs_fbjofA4bsA2vLL vGDPjXe6DmUP2ofuOQmbr4wHC32854dgZncE5b4PEgA3cmL8O2MDDJv0_NxDXhkY- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Sat, 11 Nov 2017 00:33:14 +0000 Received: from [127.0.0.1] by smtp112.sbc.mail.bf1.yahoo.com with NNFMP; 11 Nov 2017 00:33:10 -0000 X-Yahoo-Newman-Id: 93224.76044.bm@smtp112.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 6V6bLg8VM1kHvndTqfPLk9sZE1AlYmqed3c1xfhyXrSiukL ce3TZ3JAW3AWw1cfUAEXIgHCzrd_8BHYG189diLFWyYlP_HiK81nO08OV8Lx 0KlSos_Vvo2skylZGoY2H3efpWeRhYuKPkAymXgiEwIU8LtJ8z9NF2AmkI_u Us_9OpGInUCZBOgcNRwrchRs_VZJzzEweUlZkmOukt1tYE7uB8ahK1VAaeoD SqzRiHSPPHpQ8Pr8dMTqABfRL7UzfSI1rg.Y4u2QQZbh2NMcDb7gO7M6FclQ tvENitkdDremjCryGUpNDMvStvk8EprwacQeDleo97MgC767_5WcyLbKT7Bx IHWZvXer7cJvbsNYg6JA7vD0gmmE7aZ1RvcI2zjZ0r4.hKLElPqrfktOpQYn nKNaG6D763qMurdov8gR7mkhT1BhiiYiMOk2MrkU5cgza.qRzVhOcy9kDUlV AReEZUagrO9tDBeX9Ej2lPQHAyB1JrX.tyVfs_fbjofA4bsA2vLLvGDPjXe6 DmUP2ofuOQmbr4wHC32854dgZncE5b4PEgA3cmL8O2MDDJv0_NxDXhkY- X-Yahoo-SMTP: mjD.OBqswBAPbVUxYJaYPvc61jLEnpq8VnBwJGdbEJOPA9xw To: "Let me illustrate..." References: <56DDC545.7060506@sbcglobal.net> <56EEFF07.4090506@sbcglobal.net> <3544b675-4fda-9b9a-7809-f6ad9679fb3d@sbcglobal.net> From: Greg Chicares Message-ID: <4fedfed7-8e0a-1f98-8163-f103fa1aed80@sbcglobal.net> Date: Sat, 11 Nov 2017 00:33:07 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.6.131.46 Subject: Re: [lmi] Proposed workflow for proprietary repository X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 00:33:22 -0000 First let me ask whether you received the message that you replied to here in normal email, because I did not, not even at my corporate email account that is also subscribed to this mailing list. On 2017-11-10 22:16, Vadim Zeitlin wrote: > On Fri, 10 Nov 2017 17:59:09 +0000 Greg Chicares wrote: > > GC> On 2016-03-20 19:50, Greg Chicares wrote: > GC> [...] > GC> > Here's how to create a bundle to share by email. Make any number of > GC> > changes to the local repository, and commit them in whatever groups > GC> > make sense: > GC> > > GC> > cd /opt/lmi/proprietary > GC> > git commit --all -m"One set of changes" > GC> > git commit --all -m"Another set of changes" > GC> > > GC> > When it's ready to share, do this: > GC> > > GC> > cd /opt/lmi/proprietary > GC> > git bundle create YourBundleName ^origin/master HEAD --branches > ^^^^^^^^^^^^^^^^^^^ > This is off-topic, but I'd just like to note that now that you're aware of > Git "A..B" notation, you could replace this part with "origin/master..HEAD" > which is a bit a more understandable IMHO as closer to the standard > interval notation (except in Git intervals are open-closed semi-intervals). Thanks for pointing that out. I had forgotten what the '^' above means, but: https://git-scm.com/docs/gitrevisions | ^r1 r2 means commits reachable from r2 but exclude the ones reachable from r1 That '^'-prefixed syntax does seem unnatural, so I've updated 'gwc/develop2.txt' to use the more comprehensible ".." form. > GC> > (using a more descriptive name) and send the file as an email > GC> > attachment. > GC> > GC> Vadim--This has worked perfectly until about a month ago. Since then, > GC> every time Kim prepares a bundle, permissions on many files get changed. > GC> Please help us figure out how to prevent this. > > Brief answer is to set core.filemode to false. When I started to use Git > with Cygwin (admittedly, this was a long -- was it really 9 years?? -- time > ago), I experimented with different settings/combinations of file > modes/ACLs and this was the only possibility to make things work reliably. > Maybe things have changed since then, but your experience seems to disprove > this and in any case the one thing I'm sure about is that they still work > fine with core.filemode set to false. [...and it's twice as fast...] What are the exact consequences, in a world where: - Kim uses msw, and I do not - Kim sets 'core.filemode' to false, and I do not - Kim adds or modifies nonexecutable files often, but executable ones never ? AFAICT, under those assumptions, any file she touches is mode 644, but all the files she ever touches should be 644, so this really will just work. > GC> Applying a bundle sent yesterday (possibly from a new machine configured > GC> by corporate IT) [...and they're going to re-reconfigure it soon, causing another thousand headaches...] > GC> mode change 100644 => 100755 data/sample.database > > If you really want to debug this, you need to look at MSW ACL for this > file, using cacls or icacls as discussed just recently. Thanks for explaining that. Those commands remind me of the way Dickens named characters--every time I struggle with them, I feel like their inventor is cackling in sick delight at the vexation he's causing me: "I cackles at you, Mr. Greg! Stamps me feet and cackles, I does!" Preferring brute force to being thrown into a "purple leptic fit" by all that cackling, we just obliterated the offending files mentioned in that recent message and recreated them. > Also, I'm not completely sure if the file is actually executable on the > machine where "git bundle" was made, could you please confirm whether it is > the case? I'm pretty sure it does have the executable bit set, from my own experience using cygwin. I can't say that I ever actually tried to execute such a file, but I have seen the 'x' bit set. > GC> [...] yet I'd like to find a way > GC> to prevent such problems from arising. For example, several hundred > GC> of these files are freshly regenerated by msw-native programs (rather > GC> than being migrated from another machine), and it would be helpful to > GC> intercept and reverse permission changes before a git bundle is > GC> created. > > Unfortunately I don't think there are any hooks invoked during git bundle > creation. Oh. Right. I was hoping that if I ran 'chmod' early enough in the hook, it would modify files before they got committed, but by the time the hook begins to execute, it's too late. > And, anyhow, detecting the problem at this moment could be too > late to be helpful. So the only solution I see is to indeed ensure that > commit hooks check for this -- and are executed, of course. Maybe you could > print something from the commit hook even if all checks passed successfully > (of course, I advise this, but I'd hate it for the main lmi repository...) > and ask everybody committing to it to check that this message was given. OTOH, looking for an anticipated "Okay!" message is not as good as full automation; and if it is not observed, then manual cleanup is necessary. Instead, because we really want a cut-and-pastable series of maximally robust commands, I think I'll amend the instructions thus: # When everything is ready to share... cd /opt/lmi/proprietary +printf "forcing correct permissions " + for d in src data test tables; do (\ + printf "$d..." \ + && find ./$d -maxdepth 1 -type f -not -name '*.sh' -not -name '*.sed' | xargs chmod -x \ + )done git bundle create YourBundleName origin/master..HEAD --branches I tested that, and it seems to do the right thing, quickly enough... /opt/lmi/proprietary[0]$time (for d in src data test tables; do (\ printf "$d..." \ && find ./$d -maxdepth 1 -type f -not -name '*.sh' -not -name '*.sed' | xargs chmod -x \ )done) src...data...test...tables...( for d in src data test tables; do; ( printf "$d..." && find ./$d -maxdepth ) 0.00s user 0.00s system 25% cpu 0.031 total ....that it's probably tolerable even on slow magnetic drives. > GC> I hesitate to suggest doing the following (for cygwin only): > GC> git config core.filemode false > GC> because it seems like a kludge, and data files really shouldn't ever > GC> have the executable bit set. > > Honestly, if this solves the problem -- and I think it ought to -- I'd do > it without a second thought. Yes, core.files is a kludge, but then the > entire concept of Cygwin is a kludge anyhow, so I don't think it's worth > fighting for immaculate purity when using it. Okay, that logic seems compelling. > GC> find . -name '*.sh' -o -name '*.sed' -type f | xargs chmod -x [...] > I guess it's just a typo, but the logic of the command above is reversed: Yes, your message arrived just as I was about to correct that. > Other than that the command looks fine to me. Purists would argue that you > should use "find -printf0" and "xargs -0", but as long as you avoid white > space in your file names (which is an excellent idea anyhow), this is not > necessary. None of us is ever going to commit a file with whitespace in its name, but perhaps I should add a test like find -type f -name "* *" to 'make check_concinnity' anyway...someday, when I remove the $(LS) --classify ./* | sed ... horror in 'GNUmakefile'. > And I think the idea of making non-executable all but whitelisted files is > a better one than blacklisting some files because if you add another > category of files that should be executable and their executable bit is > reset by this script, it will get noticed much sooner than if you add some > new type of non-executable files and forget to blacklist it. That seems so obvious when you express it in five lines rather than the hundred or so lines it took me to demonstrate its contrapositive. From MAILER-DAEMON Sat Nov 11 06:00:34 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eDTWc-0005Hn-11 for mharc-lmi@gnu.org; Sat, 11 Nov 2017 06:00:34 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38669) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eDTWa-0005GT-Ac for lmi@nongnu.org; Sat, 11 Nov 2017 06:00:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eDTWX-00080K-7R for lmi@nongnu.org; Sat, 11 Nov 2017 06:00:32 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:45718 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eDTWW-0007zo-Ua for lmi@nongnu.org; Sat, 11 Nov 2017 06:00:29 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eDTWT-0001ou-2e for lmi@nongnu.org; Sat, 11 Nov 2017 12:00:25 +0100 Date: Sat, 11 Nov 2017 12:00:24 +0100 From: Vadim Zeitlin To: "Let me illustrate..." MIME-Version: 1.0 References: <56DDC545.7060506@sbcglobal.net> <56EEFF07.4090506@sbcglobal.net><3544b675-4fda-9b9a-7809-f6ad9679fb3d@sbcglobal.net> <4fedfed7-8e0a-1f98-8163-f103fa1aed80@sbcglobal.net> In-Reply-To: <4fedfed7-8e0a-1f98-8163-f103fa1aed80@sbcglobal.net> X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 82.240.17.225 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: [lmi] Proposed workflow for proprietary repository X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 11:00:33 -0000 On Sat, 11 Nov 2017 00:33:07 +0000 Greg Chicares wrote: GC> First let me ask whether you received the message that you replied GC> to here in normal email, because I did not, not even at my corporate GC> email account that is also subscribed to this mailing list. I received it from the mailing list and I see it in the archives (see http://lists.nongnu.org/archive/html/lmi/2017-11/msg00017.html), so I don't see any problems from here. GC> What are the exact consequences, in a world where: GC> - Kim uses msw, and I do not GC> - Kim sets 'core.filemode' to false, and I do not GC> - Kim adds or modifies nonexecutable files often, but executable ones never GC> ? AFAICT, under those assumptions, any file she touches is mode 644, but all GC> the files she ever touches should be 644, so this really will just work. Yes, this is what I believe too. GC> OTOH, looking for an anticipated "Okay!" message is not as good as full GC> automation; and if it is not observed, then manual cleanup is necessary. GC> Instead, because we really want a cut-and-pastable series of maximally GC> robust commands, I think I'll amend the instructions thus: GC> GC> # When everything is ready to share... GC> GC> cd /opt/lmi/proprietary GC> +printf "forcing correct permissions " GC> + for d in src data test tables; do (\ GC> + printf "$d..." \ GC> + && find ./$d -maxdepth 1 -type f -not -name '*.sh' -not -name '*.sed' | xargs chmod -x \ GC> + )done GC> git bundle create YourBundleName origin/master..HEAD --branches GC> GC> I tested that, and it seems to do the right thing, quickly enough... Looks good to me too. Regards, VZ From MAILER-DAEMON Sun Nov 12 19:07:41 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eE2Ht-0001AR-Nk for mharc-lmi@gnu.org; Sun, 12 Nov 2017 19:07:41 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eE2Hq-0001AK-QN for lmi@nongnu.org; Sun, 12 Nov 2017 19:07:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eE2Hn-0000cA-M1 for lmi@nongnu.org; Sun, 12 Nov 2017 19:07:38 -0500 Received: from sonic303-7.consmr.mail.bf2.yahoo.com ([74.6.131.46]:41957) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eE2Hn-0000bI-Fv for lmi@nongnu.org; Sun, 12 Nov 2017 19:07:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1510531651; bh=IdecrtwIOjeUfzbb1SkcRiHh8lKjJKdKRCO6x4DxRHg=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=PC+KpzFsAQhiNgmTNozspWyGIxQCGJu0bXBpYlpng+VpYh8b79vhOYMpd6x9F59FPKy9mF9qBhBDGat5dVJ1LpTlOAsIB2TKHuqqhwbqMtDxDm3lsgvdnlZwd9RBTklm0rVt4BGgkfxsCEl++2sgTfZs8eWreaGdWamSTDuRdsC1BFDg2JiOo7J8QYxeb7JKgV2WBa/NRBqFBNVSIT+jkLU+uUBm/w7IgFeXbYXZ3lF0X846cbMMQBep2zwZzJUWCADxjO/a9A2UrO1/qpgks3f8Xn/5pDiVHwOp3tqvbmachu7Psidk+FW8wunpKyHjap9Pt1Qw/YL8KDBSqmLMgA== X-YMail-OSG: v8onF9AVM1n314wgk5V_ph65A.KLdXaw4D3UFztj.tkvzCAPXE1C43Mkc6tDMZR nPWGoEO4QrYziFb4h8OPE4P32851wcil2vgWnYdMUWnz.WOPdhWncjtK2vFn5p41nMRAuASokyk1 zpU8pgUvdVpnDXmt_VQAa1fOs3XI9XHIDK.kI_JD_1JmJeUfZQ_oyxSJItpMe.6brrhRi03HFjO5 n1z.CEhTDELe_Q7SGqJPlZ8tHZjDsqqU9ococvLLL.J1.hfslmsEXQJsqYwFkdTMVFiFmzZuEM3L jWobtVhFsY0qExeSIKTttHuuSH_XeWfJ2o06TaJd3AvqjqLyUAcolSOGBS6QezTlhljjnfYcFoJZ nT6wSL6MRmtKTITpi9S_FJfx_RFSil_34LdpfJw.v9paBIJBOWz6ZAxbzdSZo3upQDJzCSR9sdYt 9d.SDNP0wBA7DpqVi9da2f94HPe8_l.rDHD3qiRWF.fgg1lgZIw1w13BtVxl0nKzmCtBnmWlc4cU uA00J47kFKgiIg0ZvkpmYoShPMTU.9HK2IcbdEjQqIAfxdvBTqdu5p3tDr3K6k.U- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Mon, 13 Nov 2017 00:07:31 +0000 Received: from [127.0.0.1] by smtp116.sbc.mail.bf1.yahoo.com with NNFMP; 13 Nov 2017 00:07:31 -0000 X-Yahoo-Newman-Id: 475835.85460.bm@smtp116.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: v8onF9AVM1n314wgk5V_ph65A.KLdXaw4D3UFztj.tkvzCA PXE1C43Mkc6tDMZRnPWGoEO4QrYziFb4h8OPE4P32851wcil2vgWnYdMUWnz .WOPdhWncjtK2vFn5p41nMRAuASokyk1zpU8pgUvdVpnDXmt_VQAa1fOs3XI 9XHIDK.kI_JD_1JmJeUfZQ_oyxSJItpMe.6brrhRi03HFjO5n1z.CEhTDELe _Q7SGqJPlZ8tHZjDsqqU9ococvLLL.J1.hfslmsEXQJsqYwFkdTMVFiFmzZu EM3LjWobtVhFsY0qExeSIKTttHuuSH_XeWfJ2o06TaJd3AvqjqLyUAcolSOG BS6QezTlhljjnfYcFoJZnT6wSL6MRmtKTITpi9S_FJfx_RFSil_34LdpfJw. v9paBIJBOWz6ZAxbzdSZo3upQDJzCSR9sdYt9d.SDNP0wBA7DpqVi9da2f94 HPe8_l.rDHD3qiRWF.fgg1lgZIw1w13BtVxl0nKzmCtBnmWlc4cUuA00J47k FKgiIg0ZvkpmYoShPMTU.9HK2IcbdEjQqIAfxdvBTqdu5p3tDr3K6k.U- X-Yahoo-SMTP: mjD.OBqswBAPbVUxYJaYPvc61jLEnpq8VnBwJGdbEJOPA9xw To: "Let me illustrate..." References: <56DDC545.7060506@sbcglobal.net> <56EEFF07.4090506@sbcglobal.net> <3544b675-4fda-9b9a-7809-f6ad9679fb3d@sbcglobal.net> <4fedfed7-8e0a-1f98-8163-f103fa1aed80@sbcglobal.net> From: Greg Chicares Message-ID: <854701f5-eef4-f4c2-a421-cba9b262ff19@sbcglobal.net> Date: Mon, 13 Nov 2017 00:07:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.6.131.46 Subject: Re: [lmi] Proposed workflow for proprietary repository X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 00:07:39 -0000 On 2017-11-11 11:00, Vadim Zeitlin wrote: > On Sat, 11 Nov 2017 00:33:07 +0000 Greg Chicares wrote: > > GC> First let me ask whether you received the message that you replied > GC> to here in normal email, because I did not, not even at my corporate > GC> email account that is also subscribed to this mailing list. > > I received it from the mailing list and I see it in the archives (see > http://lists.nongnu.org/archive/html/lmi/2017-11/msg00017.html), so I > don't see any problems from here. It did eventually show up on my corporate email account, so my ISP is the problem. > GC> OTOH, looking for an anticipated "Okay!" message is not as good as full > GC> automation OTTH, asking others to run various sets of commands and then, depending on their outcome, to run various other sets of commands, becomes an imposition as the command-sets grow. Therefore, I've moved all that stuff into a script: commit a8e0d0258afe16d334d824226503849645749a6f Author: Gregory W. Chicares Date: 2017-11-12T23:40:22+00:00 Replace complex manual commands with a script check_git_setup.sh | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ gwc/develop2.txt | 37 +++++-------------------------------- 2 files changed, 60 insertions(+), 32 deletions(-) Would you mind taking a look and telling me if that script needs improvement? (You might prefer not to run it yourself because you have your own personal git hooks that you want to keep, but I've run it myself and will ask Kim to also.) From MAILER-DAEMON Mon Nov 13 08:55:37 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eEFD7-00069R-Pd for mharc-lmi@gnu.org; Mon, 13 Nov 2017 08:55:37 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42945) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEFD5-00069H-Bc for lmi@nongnu.org; Mon, 13 Nov 2017 08:55:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eEFD2-0001ci-8p for lmi@nongnu.org; Mon, 13 Nov 2017 08:55:35 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:46220 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eEFD2-0001cD-0H for lmi@nongnu.org; Mon, 13 Nov 2017 08:55:32 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eEFCx-0002Sq-Ly for lmi@nongnu.org; Mon, 13 Nov 2017 14:55:27 +0100 Date: Mon, 13 Nov 2017 14:55:27 +0100 From: Vadim Zeitlin To: "Let me illustrate..." MIME-Version: 1.0 References: <56DDC545.7060506@sbcglobal.net> <56EEFF07.4090506@sbcglobal.net><3544b675-4fda-9b9a-7809-f6ad9679fb3d@sbcglobal.net><4fedfed7-8e0a-1f98-8163-f103fa1aed80@sbcglobal.net> <854701f5-eef4-f4c2-a421-cba9b262ff19@sbcglobal.net> In-Reply-To: <854701f5-eef4-f4c2-a421-cba9b262ff19@sbcglobal.net> X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 82.240.17.225 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: [lmi] Proposed workflow for proprietary repository X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 13:55:36 -0000 On Mon, 13 Nov 2017 00:07:29 +0000 Greg Chicares wrote: GC> Therefore, I've moved all that stuff into a script: GC> GC> commit a8e0d0258afe16d334d824226503849645749a6f GC> Author: Gregory W. Chicares GC> Date: 2017-11-12T23:40:22+00:00 GC> GC> Replace complex manual commands with a script GC> GC> check_git_setup.sh | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ GC> gwc/develop2.txt | 37 +++++-------------------------------- GC> 2 files changed, 60 insertions(+), 32 deletions(-) GC> GC> Would you mind taking a look and telling me if that script GC> needs improvement? Hi, Nothing that I'd characterize as "needing" improvement, but a couple of things that might be improved. The first one is really trivial: I think that case `uname -s` in CYGWIN*) printf "cygwin detected\n" ;; esac is a more idiomatic way of doing things in shell than using the $(expr substr())" expression but, following my own advice not to start battles for purity when the entire war is hopelessly lost, I'm certainly not going to start seriously worrying about the best style of writing shell scripts. The second question is about using "--global" when setting core.filemode to false. This seems questionable because you only care about this for this particular repository, so "--local" (which is the default anyhow) would seem to be more logical, why should this script change things for all the other Git repositories on the same system? Also, if, somehow, there is already a local setting of this option, it's going to take precedence over the global one, while you really want to impose this setting. I realize that both of these things (using other, unrelated, Git repositories and having a local setting of core.filemode) are very unlikely to happen, but by simply not using "--global" we wouldn't have to think about them at all. Next one is about the purpose of "cd $(git rev-parse --show-toplevel)": it seems not to do anything if the script is run from the repository directory and potentially do something quite wrong if it's run (e.g. using its full path) from a directory which just happens to contain another repository. Normally I'd use something like "cd $(dirname $(readlink -f $0))" instead, shouldn't it be done like this here too? Then there is the snippet which does use "readlink" but here I wonder why do we need to do these indirect tests with "readlink -f" instead of just using normal "readlink .git/hooks" and comparing the result with "../hooks", i.e. directly checking for what we want. Again, I can't actually think of any situation in which the current code would fail, so it's not a problem, but it just seems unnecessary roundabout to me compared to (warning, untested shell code ahead): if [ "$(readlink .git/hooks)" = "../hooks" ]; then printf "git hooks directory is properly symlinked\n" else if [ -x .git/hooks ]; then printf "must reconfigure git hooks directory, original saved as hooks-orig\n" mv .git/hooks .git/hooks-orig else printf "must create git hooks directory symlink\n" fi ln --symbolic --no-dereference ../hooks .git fi Final enhancement would be to exit the script with 0 only if all checks passed and some non-zero exit code otherwise. Sorry for a long email about mostly trivial issues, hopefully mentioning at least some of them wasn't useless, VZ From MAILER-DAEMON Mon Nov 13 14:12:08 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eEK9Q-00019Z-Le for mharc-lmi@gnu.org; Mon, 13 Nov 2017 14:12:08 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37999) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEK9O-00019Q-AF for lmi@nongnu.org; Mon, 13 Nov 2017 14:12:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eEK9L-0002p1-4W for lmi@nongnu.org; Mon, 13 Nov 2017 14:12:06 -0500 Received: from sonic301-7.consmr.mail.bf2.yahoo.com ([74.6.129.46]:40718) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eEK9K-0002on-UD for lmi@nongnu.org; Mon, 13 Nov 2017 14:12:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1510600322; bh=WQ5OtGLOx9UUbDOLEHCH9GHry9e3w7u9SYqGiF1/sqY=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=L7pWtVNJNEz7nz3IRk1K6rLxi50iq8ms5NRG3n/hGqh3Pc8dP+Hsfguofy21ApearpPII0zSo/k938zi2QLFvArPm+r+a5C4xx44oX3Q0AtM9gfJb2mkz0i6+quOAkVzJ+OA9jDbTIG/za8/rIoI2AeB3CsZUsLiKTPA4KBZqSKY9U5+NeMeVNlTjwZ8D5h6IdVwPpo2NxoJlxC8lSe/sN2z1PebXndxJJ2n/VVm3fJJLEKT55VD/ZRqfuXa97TlcTxvsHm4Fdjr4M/WmTZSnQUAlkqgBtL6XT7b/Edv8IR10tK+C1x/JupBNtW2Kdy+LMYi/me9Sk9yBhDU1OHiRw== X-YMail-OSG: tR6iBP0VM1lTojc4CrZFTdvlp_UWMcNj2P8ZV3iQlNVNnsNDdXrh9sSauKgu6M7 yNT_qeSe4.GUpwMAzmpS3_I4mw4aPBv82BF9DB.5tm7vVnuN08vfaMUUb_Su.gj8aFK0VSdrYPdU G8yWxrtvlb7sWU0uP0p69cvdXh9_4kQ5V0c4TSGr2_TTZTrk1hdgOQA5hn1Zbl6X17V_8IOINhMd kI3cWghlEoebBqCLXw6XdjMexlRz1pr9IytfJG_KATCWXZDzAg5bI9xwdGWsMYVxpohCasodpzS7 Gmv2s6cjXZbI12Ht5uP4OPMTu.Cb0LNTq5dlQPZy971gs2BjJFVGPitdn3do5CGg90NpU1rSJt8t 2mYhqo8ckYxnuvbNpHIkK1dlnTos.tJFMKb0BCwJLNAk5cwif789AdQDCofNsdJidk4KgdjFNym. 5Jf7eGoxtqvcqGOxsiQwvIAbmeE.5zb87ARwtJitgwGX80qB34JAGbVOfhndeimlD9C7Qm6FPgmY Cs_IVxZMYoPdAQsvGu0ftBywoym8bcrvjfrfegYwKxLbxGB93H8ONPRg8sMGQwuw- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Mon, 13 Nov 2017 19:12:02 +0000 Received: from [127.0.0.1] by smtp115.sbc.mail.bf1.yahoo.com with NNFMP; 13 Nov 2017 19:11:58 -0000 X-Yahoo-Newman-Id: 476411.59478.bm@smtp115.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: tR6iBP0VM1lTojc4CrZFTdvlp_UWMcNj2P8ZV3iQlNVNnsN DdXrh9sSauKgu6M7yNT_qeSe4.GUpwMAzmpS3_I4mw4aPBv82BF9DB.5tm7v VnuN08vfaMUUb_Su.gj8aFK0VSdrYPdUG8yWxrtvlb7sWU0uP0p69cvdXh9_ 4kQ5V0c4TSGr2_TTZTrk1hdgOQA5hn1Zbl6X17V_8IOINhMdkI3cWghlEoeb BqCLXw6XdjMexlRz1pr9IytfJG_KATCWXZDzAg5bI9xwdGWsMYVxpohCasod pzS7Gmv2s6cjXZbI12Ht5uP4OPMTu.Cb0LNTq5dlQPZy971gs2BjJFVGPitd n3do5CGg90NpU1rSJt8t2mYhqo8ckYxnuvbNpHIkK1dlnTos.tJFMKb0BCwJ LNAk5cwif789AdQDCofNsdJidk4KgdjFNym.5Jf7eGoxtqvcqGOxsiQwvIAb meE.5zb87ARwtJitgwGX80qB34JAGbVOfhndeimlD9C7Qm6FPgmYCs_IVxZM YoPdAQsvGu0ftBywoym8bcrvjfrfegYwKxLbxGB93H8ONPRg8sMGQwuw- X-Yahoo-SMTP: mjD.OBqswBAPbVUxYJaYPvc61jLEnpq8VnBwJGdbEJOPA9xw To: "Let me illustrate..." References: <56DDC545.7060506@sbcglobal.net> <56EEFF07.4090506@sbcglobal.net> <3544b675-4fda-9b9a-7809-f6ad9679fb3d@sbcglobal.net> <4fedfed7-8e0a-1f98-8163-f103fa1aed80@sbcglobal.net> <854701f5-eef4-f4c2-a421-cba9b262ff19@sbcglobal.net> From: Greg Chicares Message-ID: Date: Mon, 13 Nov 2017 19:11:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.6.129.46 Subject: Re: [lmi] Proposed workflow for proprietary repository X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 19:12:07 -0000 On 2017-11-13 13:55, Vadim Zeitlin wrote: > On Mon, 13 Nov 2017 00:07:29 +0000 Greg Chicares wrote: [...] > GC> check_git_setup.sh | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ [...] > GC> Would you mind taking a look and telling me if that script > GC> needs improvement? [...] > The first one is really trivial: I think that > > case `uname -s` in > CYGWIN*) > printf "cygwin detected\n" > ;; > esac > > is a more idiomatic way of doing things in shell than using the $(expr > substr())" expression but, following my own advice not to start battles for > purity when the entire war is hopelessly lost, I'm certainly not going to > start seriously worrying about the best style of writing shell scripts. Yes, that's more readable and more robust. The only reason I used if [ "$(expr substr $(uname -s) 1 6)" = "CYGWIN" ] instead is because that 'expr substr' thing was already used elsewhere. But it's used only in one other place, so I think it's better to use the idiom you suggest here now, test it well, and then use it in that one other place too. It's clear that the 'case' variant asks whether one string contains another at its beginning, but the "1 6" indexing requires thought (in origin zero it'd be "0 5"). > The second question is about using "--global" when setting core.filemode > to false. This seems questionable because you only care about this for this > particular repository, so "--local" (which is the default anyhow) would > seem to be more logical, why should this script change things for all the > other Git repositories on the same system? OTOH, this is limited to cygwin systems only, and I think we've concluded that we should use "core.filemode false" always on every cygwin system--i.e., in effect, that this should be a cygwin default. Therefore, forcing that default globally seems like a good idea, except that this command doesn't actually do that: > Also, if, somehow, there is > already a local setting of this option, it's going to take precedence over > the global one, while you really want to impose this setting. Okay, I'll remove '--global' here. > Next one is about the purpose of "cd $(git rev-parse --show-toplevel)": it > seems not to do anything if the script is run from the repository directory Yes. The idea was that, if it's run from a subdirectory, we want to switch to the "toplevel" directory. However, the script should reside in that directory anyway, and I hadn't considered what happens if... > and potentially do something quite wrong if it's run (e.g. using its full > path) from a directory which just happens to contain another repository. > Normally I'd use something like "cd $(dirname $(readlink -f $0))" instead, > shouldn't it be done like this here too? ....so yes, I'll change that, too. > Then there is the snippet which does use "readlink" but here I wonder why > do we need to do these indirect tests with "readlink -f" instead of just > using normal "readlink .git/hooks" and comparing the result with > "../hooks", i.e. directly checking for what we want. Again, I can't > actually think of any situation in which the current code would fail, so > it's not a problem, but it just seems unnecessary roundabout to me compared > to (warning, untested shell code ahead): > > if [ "$(readlink .git/hooks)" = "../hooks" ]; then > printf "git hooks directory is properly symlinked\n" > else > if [ -x .git/hooks ]; then > printf "must reconfigure git hooks directory, original saved as hooks-orig\n" > mv .git/hooks .git/hooks-orig > else > printf "must create git hooks directory symlink\n" > fi > ln --symbolic --no-dereference ../hooks .git > fi There are several changes here. As for readlink's '-f' = '--canonicalize' option, I guess that's just a personal preference. I can compare "2.0000" to "2" more readily if I canonicalize both to "2" first, and the extra labor represents an affordable price. I'm assuming that '--canonicalize' actually performs some similar kind of canonicalization of filepaths, but let's see... okay, it tests validity and returns an abolute filepath. It's not portable to BSD, and GNU suggests that it's not "preferred": http://www.gnu.org/software/coreutils/manual/html_node/readlink-invocation.html#readlink-invocation | Note the realpath command is the preferred command to use for canonicalization. but I'm in no rush to pursue that further. I'll adopt the idea of testing the everything-is-okay case first. It was a mistake to execute (in effect) 'mv ; ln' instead of 'mv && ln', because mv can certainly fail. Yet the logic proposed above doesn't seem simple enough to me, so I'll do something a little different... > Final enhancement would be to exit the script with 0 only if all checks > passed and some non-zero exit code otherwise. ....also adopting that excellent idea. > Sorry for a long email about mostly trivial issues, hopefully mentioning > at least some of them wasn't useless, Thanks for a careful review that helped me remove serious defects. From MAILER-DAEMON Tue Nov 14 11:13:30 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eEdq6-0003Q4-JI for mharc-lmi@gnu.org; Tue, 14 Nov 2017 11:13:30 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54414) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEdpz-0003Ma-TP for lmi@nongnu.org; Tue, 14 Nov 2017 11:13:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eEdpv-00037N-Ts for lmi@nongnu.org; Tue, 14 Nov 2017 11:13:23 -0500 Received: from sonic311.consmr.mail.bf2.yahoo.com ([74.6.131.253]:40199 helo=sonic311-17.consmr.mail.bf2.yahoo.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eEdpv-00033a-MW for lmi@nongnu.org; Tue, 14 Nov 2017 11:13:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1510675997; bh=O2ISWE1md8NjpK1UWverH/pVcy+pVjz5cMIGktlvNz0=; h=To:From:Subject:Date:From:Subject; b=K6vT2ygmw7fP1y0I9LQM+jNOny68LnwHTUwvqirnW7bJKuQD3RZU7UUW4xk32LQi1xuiTYwww4HYLJnz05BHOKxq/fVAliqstYlTGecIt5aVuC/7BDZyAeYOxGtNHbP2vqalL9cb37L5jxrEjZgSYfUqCjGqrRQ3mgTp+C9anIMOR3s3chxYXT6YLJ2Shmzv2aSXQ3f5900INCjajb5UYsvxkmrTamWfudxEo/olRYVjxcWgcIcqKs+3/Cy3k396xkeshrwoFUlNVv8bsRuJOwLDV4O7TPyhJQbqgTFvbAGkrxLKA2F80AXVvoVycrc/D93y4QlL/d1GbFGp++vbZw== X-YMail-OSG: KBITihMVM1m2TUClBGNctudN0V5p3r52ekz0pwjAHZuBaepHLN3BghYQcTQEc6N X0lCxRqVUTgvLd4IoW.N1g1wVvUPWCJmeGOgGhJfBjP_HIvnE7f4loN8jlem52Cn8zTmoHIgUf4p 0YeFBcarWVfWSVImvGTE2GPqql2l9ztw3C1VmsdZTId.e8mcraAkLydXcl8fKnNtrJtMDhEwkWdx i8f9J_Qp_KNXP6OQHScaV.k077XnwjE_avsdyfv0Nr_QYeSSIP60EOFvv_Oh5Ys0IHTyHDMv3lY2 4.8uViC7ydLm1x0KdGjhEQ9mTD0SSVWm3.dIhspcizAxkpriVh2VX_RvhC8hVtOJwY1Wy3tZ3hxb D.2dKoAJQ5MP2WiN5AlVa7X4um8usrXnZWbgkjmfttZHzJiuUNxVsbUF8U5KzIoA8A5MkEosDG0n .TEB6KGQG_DXe55LLNcvCF0XRB3rdRWU7g9uRnlN5dOiuh2o4GPTMXm4OzUrLg8ohwEhwPfxgqaT eVPm0PwZkKMYjkUvOWQElbGhiSkldLaI9kT5zRh41Vj0VClSkPB7reGRFHgQLEQhlIau3xrb5EA- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Tue, 14 Nov 2017 16:13:17 +0000 Received: from [127.0.0.1] by smtp118.sbc.mail.bf1.yahoo.com with NNFMP; 14 Nov 2017 16:13:15 -0000 X-Yahoo-Newman-Id: 331739.76446.bm@smtp118.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: KBITihMVM1m2TUClBGNctudN0V5p3r52ekz0pwjAHZuBaep HLN3BghYQcTQEc6NX0lCxRqVUTgvLd4IoW.N1g1wVvUPWCJmeGOgGhJfBjP_ HIvnE7f4loN8jlem52Cn8zTmoHIgUf4p0YeFBcarWVfWSVImvGTE2GPqql2l 9ztw3C1VmsdZTId.e8mcraAkLydXcl8fKnNtrJtMDhEwkWdxi8f9J_Qp_KNX P6OQHScaV.k077XnwjE_avsdyfv0Nr_QYeSSIP60EOFvv_Oh5Ys0IHTyHDMv 3lY24.8uViC7ydLm1x0KdGjhEQ9mTD0SSVWm3.dIhspcizAxkpriVh2VX_Rv hC8hVtOJwY1Wy3tZ3hxbD.2dKoAJQ5MP2WiN5AlVa7X4um8usrXnZWbgkjmf ttZHzJiuUNxVsbUF8U5KzIoA8A5MkEosDG0n.TEB6KGQG_DXe55LLNcvCF0X RB3rdRWU7g9uRnlN5dOiuh2o4GPTMXm4OzUrLg8ohwEhwPfxgqaTeVPm0PwZ kKMYjkUvOWQElbGhiSkldLaI9kT5zRh41Vj0VClSkPB7reGRFHgQLEQhlIau 3xrb5EA-- X-Yahoo-SMTP: mjD.OBqswBAPbVUxYJaYPvc61jLEnpq8VnBwJGdbEJOPA9xw To: "Let me illustrate..." From: Greg Chicares Message-ID: Date: Tue, 14 Nov 2017 16:13:12 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.6.131.253 Subject: [lmi] 'wine' anomalies X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 16:13:29 -0000 Vadim--Off the list, on Thu, 19 Oct 2017 15:52:52 +0000, I wrote to you about this 'wine' anomaly: | - wxSpinCtrl text is right-aligned in an area that includes the | up and down arrows: in the screenshot, e.g., "Retirement Age" | is "65", but the "5" is mostly obscured (would it be weird to | force the "wxALIGN_LEFT" style upon end users?) (you thought that was either a 'wine' or a DPI defect). I'm repeating this here just so we have a complete public record, to which I have a new observation to add: In lmi's tabbed input dialog, text seems to be inaccessible. IIRC, in native msw there's a '?' button in the dialog's title bar that's used to access this context-sensitive help. With 'wine', I see three buttons there: - the button that "rolls up" the contents like a windowshade: https://en.wikipedia.org/wiki/WindowShade which I have on most or all windows managed by X (or xfce) - maximize or restore - close but no '?' button. BTW, the icon on this dialog is a wine bottle, whereas other lmi windows have lmi icons. The text isn't accessible by right-clicking or hovering the mouse, either; I don't recall whether either of those methods showed in native msw. From MAILER-DAEMON Wed Nov 15 16:30:48 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eF5Gi-0000Sk-Hb for mharc-lmi@gnu.org; Wed, 15 Nov 2017 16:30:48 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57155) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eF5Gg-0000RH-B8 for lmi@nongnu.org; Wed, 15 Nov 2017 16:30:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eF5Gc-0005aJ-2j for lmi@nongnu.org; Wed, 15 Nov 2017 16:30:46 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:49964 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eF5Gb-0005XC-JO for lmi@nongnu.org; Wed, 15 Nov 2017 16:30:42 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eF5GX-0008VH-59 for lmi@nongnu.org; Wed, 15 Nov 2017 22:30:37 +0100 Date: Wed, 15 Nov 2017 22:30:36 +0100 From: Vadim Zeitlin To: "Let me illustrate..." MIME-Version: 1.0 References: In-Reply-To: X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 82.240.17.225 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: [lmi] 'wine' anomalies X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 21:30:48 -0000 On Tue, 14 Nov 2017 16:13:12 +0000 Greg Chicares wrote: GC> Vadim--Off the list, on Thu, 19 Oct 2017 15:52:52 +0000, I wrote to you GC> about this 'wine' anomaly: GC> GC> | - wxSpinCtrl text is right-aligned in an area that includes the GC> | up and down arrows: in the screenshot, e.g., "Retirement Age" GC> | is "65", but the "5" is mostly obscured (would it be weird to GC> | force the "wxALIGN_LEFT" style upon end users?) GC> GC> (you thought that was either a 'wine' or a DPI defect). Hello and sorry for the delay with replying, I had some troubles because apparently I forgot to rebuild something when trying to test it yesterday and so I was getting mysterious crashes that went away after I rebuilt everything from scratch -- but not before wasting quite some time :-( Anyhow, I'd just like to confirm that I do see the problem with wxSpinCtrl here too, running it under Wine 2.0-3 with 200 DPI. And it really looks like a Wine bug because I also see it in the widgets wx sample and even at DPI 96, while the same binary works fine in a VM with DPI 200. So what to do about this? The first thing I'd do would probably be to try with a more recent Wine version, Debian Buster (current "testing") has 2.20 which is not quite the latest 2.21, but is much closer, so it's worth trying it in case something has already changed as it won't cost much. If the bug is still there, we could try to fix it in Wine which would, of course, be ideal in the long term, but might be not simple (I've never tried fixing bugs in Wine before) and won't get into a Debian version of Wine for quite some time, or we could try to work around it somehow in wxMSW itself. FWIW I also see the 2 other bugs, with black-and-white disabled bitmaps and long date problem, but I don't have the fixes for them neither, yet. I'll try to return to these issues soon. [...] GC> I have a new observation to add: GC> GC> In lmi's tabbed input dialog, text seems to be inaccessible. GC> IIRC, in native msw there's a '?' button in the dialog's title bar GC> that's used to access this context-sensitive help. With 'wine', I GC> see three buttons there: [...] but no '?' button. It looks like you use the default (checked) value of the "Allow the window manager to decorate the windows" option in the "Graphics" tab of winecfg (see https://wiki.winehq.org/Winecfg). With this option, Wine doesn't draw the window title bars at all, so it's not surprising that it uses standard XFCE buttons and doesn't have the "?" one. Unfortunately, even after clearing this option -- and seeing suitably ugly MSW title bar in the main window now -- I still don't see the "?" button, so apparently it's just something that's not implemented by Wine. And searching for WS_EX_CONTEXTHELP in Wine sources seems to confirm it, there just doesn't seem to be any code for handling it anywhere (although it could be hidden in some macros, of course...). I'll recheck this when/if I update to 2.20 to test the other bug, but I don't see anything about this being recently implemented in the change log, so I don't think it's going to change anything and, again, the best we can do is probably just open a Wine bug for this and hope that it gets addressed, because I don't think we really want to spend time on working on Wine ourselves (not that I wouldn't want to help another open source project, but there is simply not enough time for everything...), especially on a relatively unimportant bug like this. GC> BTW, the icon on this dialog is a wine bottle, whereas other lmi GC> windows have lmi icons. Well, at least I can fix this one: ---------------------------------- >8 -------------------------------------- diff --git a/mvc_controller.cpp b/mvc_controller.cpp index 59b83e27f..575d29381 100644 --- a/mvc_controller.cpp +++ b/mvc_controller.cpp @@ -28,6 +28,7 @@ #include "assert_lmi.hpp" #include "calendar_date.hpp" #include "contains.hpp" +#include "data_directory.hpp" #include "global_settings.hpp" #include "map_lookup.hpp" #include "mc_enum.hpp" @@ -44,6 +45,7 @@ #include #include #include +#include #include #include #include @@ -111,6 +113,8 @@ MvcController::MvcController alarum() << "Unable to load dialog." << LMI_FLUSH; } + SetIcons(wxIconBundle(AddDataDir("lmi.ico"), wxBITMAP_TYPE_ICO)); + BookControl().ChangeSelection(last_selected_page[view_.ResourceFileName()]); // This assignment must follow the call to LoadDialog(). ---------------------------------- >8 -------------------------------------- I'm pretty sure it shouldn't be _necessary_ to set the icon explicitly like this because the dialog is supposed to inherit the icon from its parent frame, but it probably doesn't hurt to do it neither. Perhaps we could even do it in wxMSW itself... GC> The text isn't accessible by right-clicking or hovering GC> the mouse, either; I don't recall whether either of those methods GC> showed in native msw. No, it was never accessible by hovering (this just shows "normal" tooltips, which are different from the context help tooltips) and while I think that it was indeed possible to show popup menu with "Show help" item by right clicking on the control, it must have been in some ancient MSW version (if ever at all). So without the "?" title bar button there is indeed no way to show it. At wxWidgets level, there is wxContextHelpButton which can be used instead of this button on non-MSW platforms and, in principle, we could use it in the dialog itself and show it only when running under Wine. But I don't know if it's really worth the effort, so I won't do this unless you tell me that it is. Thanks, VZ From MAILER-DAEMON Wed Nov 15 16:56:03 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eF5f9-0001tv-HO for mharc-lmi@gnu.org; Wed, 15 Nov 2017 16:56:03 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37825) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eF5f7-0001si-Sy for lmi@nongnu.org; Wed, 15 Nov 2017 16:56:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eF5f4-0001OK-VI for lmi@nongnu.org; Wed, 15 Nov 2017 16:56:01 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:50114 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eF5f4-0001L4-L3 for lmi@nongnu.org; Wed, 15 Nov 2017 16:55:58 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eF5ez-0000sH-UP for lmi@nongnu.org; Wed, 15 Nov 2017 22:55:54 +0100 Date: Wed, 15 Nov 2017 22:55:53 +0100 From: Vadim Zeitlin To: "Let me illustrate..." MIME-Version: 1.0 References: In-Reply-To: X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 82.240.17.225 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: [lmi] 'wine' anomalies X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 21:56:03 -0000 On Wed, 15 Nov 2017 22:30:36 +0100 I wrote: Me> On Tue, 14 Nov 2017 16:13:12 +0000 Greg Chicares wrote: Me> Me> GC> Vadim--Off the list, on Thu, 19 Oct 2017 15:52:52 +0000, I wrote to you Me> GC> about this 'wine' anomaly: Me> GC> Me> GC> | - wxSpinCtrl text is right-aligned in an area that includes the Me> GC> | up and down arrows: in the screenshot, e.g., "Retirement Age" Me> GC> | is "65", but the "5" is mostly obscured (would it be weird to Me> GC> | force the "wxALIGN_LEFT" style upon end users?) Me> GC> Me> GC> (you thought that was either a 'wine' or a DPI defect). Me> Me> Hello and sorry for the delay with replying (but now you get two replies in a span of half an hour to compensate!) Me> Anyhow, I'd just like to confirm that I do see the problem with wxSpinCtrl Me> here too, running it under Wine 2.0-3 with 200 DPI. And it really looks Me> like a Wine bug because I also see it in the widgets wx sample and even at Me> DPI 96, while the same binary works fine in a VM with DPI 200. Me> Me> So what to do about this? The first thing I'd do would probably be to try Me> with a more recent Wine version, Debian Buster (current "testing") has 2.20 Me> which is not quite the latest 2.21, but is much closer, so it's worth Me> trying it in case something has already changed as it won't cost much. In fact, it costed so little that I could upgrade my chroot to Buster and Wine to 2.20 completely on autopilot while writing another email, so by the time I finished I could rerun lmi using the new Wine version. Unfortunately, even if not unexpectedly, it changed absolutely nothing and all the same bugs are still there. So now we have to decide whether it's worth trying to fix them in Wine, working around them in wx or continuing to live with these ugly problems. In any case, I really think you must have a "real" VM to do some testing in it, even if most of routine tests can be done in Wine, it's clearly not quite 100% compatible with the native MSW behaviour. Regards, VZ