Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    GOLDED    |    GoldED Public Release discussion.    |    2,690 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 2,181 of 2,690    |
|    Nicholas Boel to Vitaliy Aksyonov    |
|    Latest sources..    |
|    16 Feb 24 17:26:22    |
      MSGID: 1:154/10 65cfef1c       REPLY: 1:104/117 65cf71b5       PID: SmapiNNTPd/Linux 2.0 b20240117       CHRS: UTF-8 4       TZUTC: -0600       TID: hpt/lnx 1.9 2024-02-05       On Fri, 16 Feb 2024 13:10:24 -0700, Vitaliy Aksyonov -> Nicholas Boel wrote:               NB>> My terminal during that session is already 160 wide, so that's not the        NB>> issue with the random wrapping of those characters, then.               VA> So do you have terminal 160 chars wide, but message displayed narrower?              Yes, the message itself was created by a script and was only 78 characters       wide to begin with when it was created, and is posted to the message base with       'hpt post'.              I just think that my utf-8 hackery may be moving some of those line drawing       characters to the next line when it shouldn't be doing so. Maybe there are       some soft CRs in there I should be looking for (I don't know how to spot       those)?               NB>> So am I actually able to specify which commit I would like to go back        NB>> to with 'git bisect' or should I use 'git checkout'? If checkout is        NB>> the answer, I won't be able to keep track of good or bad commits any        NB>> more.               VA> So how bisect works.        VA> You start process with git bisect start as you already did.        VA> First you mark some commit which is good for sure with git bisect good.        VA> Then mark "bad" commit with git bisect bad. That will be last commit in       repo.        VA> git will checkout commit in the middle of those two for you. Then you       build        VA> it and test. If it's good, run git bisect good, if it's bad, git bisect        VA> bad. Build it and test again.              That's how I understand it. However, you asked me to roll back to a specific       version, and git bisect is not able to do that.              So without going that route, I can say ever since you've started updating       Golded I haven't had any display issues, until this latest version. What you       seemed to have fixed for Wilfred, did the opposite for me. :)              Regards,       Nick              ... "Take my advice, I don't use it anyway."       --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb        * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)       SEEN-BY: 15/0 18/200 90/1 103/705 105/81 106/201 120/616 123/10 124/5016       SEEN-BY: 128/260 129/305 135/225 153/757 7715 154/10 30 40 50 700       SEEN-BY: 203/0 218/700 220/90 221/0 6 226/18 30 227/114 229/110 112       SEEN-BY: 229/113 206 307 317 400 426 428 470 664 700 240/1120 5832       SEEN-BY: 266/512 280/464 5003 5555 282/1038 291/111 292/854 8125 301/1       SEEN-BY: 310/31 320/219 322/757 341/66 234 342/200 396/45 423/120       SEEN-BY: 460/16 58 256 1124 5858 467/888 633/280 712/848 770/1 2320/105       SEEN-BY: 3634/12 5020/400 1042 5054/30       PATH: 154/10 280/464 460/58 229/426           |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca