> Those extra 8 bytes of hash on 256 versus 224 are starting to push the > limits of what you can display with an 80-column tty window.
You're already at 80 columns on the checkout and parent lines. Current SHA1 - Max line length 79 13:12:09 $ fo stat repository: c:\fossil\fossil-scm.fossil local-root: C:/Users/abc123/Desktop/Projects/fossil/ config-db: C:/Users/abc123/AppData/Roaming/_fossil checkout: 5ed8477b9fd2fe5e71796b3bd9f1d88f5f90e8e4 2017-02-27 14:46:01 UTC parent: ccdafa2a93e7bcefa1b4d0ea7474f9ce84c690f2 2017-02-26 16:30:44 UTC tags: trunk comment: The smallest SHA3 hash size is 224 bits, not 228 bits. (user: drh) SHA3-224 - Max line length 94 SHA3-256 - Max line length 102 However, the 224 output would fit into exactly 80 if you started the line immediately with the hash value. Eric Dillon -----Original Message----- From: drhsql...@gmail.com [mailto:drhsql...@gmail.com] On Behalf Of Richard Hipp Sent: Tuesday, February 28, 2017 1:09 PM To: Dillon, Eric W - Norman, OK - Contractor Cc: fossil-dev Subject: Re: [fossil-dev] Proposed roadmap for Fossil 2.0 On 2/28/17, Dillon, Eric W - Norman, OK - Contractor <eric.w.dil...@usps.gov> wrote: > > Consider that you're primarily only going to be displaying / typing > the first several hex values anyway. If it were just the case of showing prefixes, I agree that we might as well go with 256. But there are situations where the full hash is shown. One example is the "fossil status" command. There are many others. Those extra 8 bytes of hash on 256 versus 224 are starting to push the limits of what you can display with an 80-column tty window. -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
