My reply for git mailing list about the bug and more for brian is here forwarded because the reply button reply's to the sender and not the mailing list. See more for brian after the reply. from A_bughunter@xxxxxxxxx Sent with Proton Mail secure email. ------- Forwarded Message ------- From: A bughunter <A_bughunter@xxxxxxxxx> Date: On Friday, November 15th, 2024 at 04:31 Subject: Re: [bug] user may be cornered into delete files #9901 To: brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> > My reply to brian m. carlson. > > No, you brian seem to be missing what the bug is my complaint is this: > if the initial push fails (for any reason) then the user must reset thus deleting files. My capacity is new to git as you would see on my github.com/freedom-foundation profile. You can run the problem again and see if a --soft reset would evade having to delete files. Help resources instructed hard reset when asking how to undo a commit because push fails. Can a --soft reset undo add without deleting the files which initially have no backup. Bear in mind the files could be anything, text, tiff is not part of the bugreport. Any initial files would have to be deleted if push fails for any reason is the bugreport. > brian, I was not impressed that you could not gather what my bugreport was before I rephrased it. brian, For years my files have been the victim of vandalism and hex editors, and likely everybody's files are because I have yet to meet anybody whome can describe how to perfectly checksum text. I get what you say brian about a text file instead of TIFF but the conversion to text from TIFF is a long drawn out process which may take a while so I have stored the original TIFF which is further necesarry to authenticate the sources of The Book. Unicode is a problem see here github.com/freedom-foundation/unicode-map . Can you help to build an ANSI ASCII only Linux kernel because the Unicode is a problem and Unicode is in the Linux kernel. In order to convert The Book to text I need 7-bit ASCII ( see here https://github.com/freedom-foundation/ASCII-format-for-Network-Interchange ) and for checksums to remain stable either BOM or a BOM notation along with the checksum. Unicode is a problem because you cannot checksum text while fighting against vandalism and binary/hex editors.You may know also calibrating OCR such as tesseract is not a snap and may need about ten percent of total size to be corrected which is effectually dilligently re-reading The Book that being the case it is about as easy to type it by hand instead of using OCR such as tesseract while fighting vandalism and binary/hex editors which impeade the process. The process cannot be verified without checksums while protecting against corruption. While. > > from A_bughunter@xxxxxxxxx > > Sent with Proton Mail secure email. > > > On Thursday, November 14th, 2024 at 23:37, brian m. carlson sandals@xxxxxxxxxxxxxxxxxxxx wrote: > > > On 2024-11-14 at 17:53:15, A bughunter wrote: > > > > > [bug] user may be cornered into delete files #9901 pls see https://github.com/cli/cli/issues/9901 and look into all of the links. > > > > What you're describing sounds like a network problem of some sort. I > > don't believe this is a bug in Git because Git handles this kind of > > thing on a regular basis without a problem. > > > > The only thing which might potentially be a problem on the Git side is > > that I don't know if we try to hold the connection open without sending > > a sideband during pack generation, in which case if the client side > > doesn't send anything at all, then the connection might be closed by the > > server. I'll point out that GitHub sends SSH keepalives, so typically > > the connection should not be reset unless the connection actually > > drops. > > > > However, you could try pushing over HTTPS instead, which won't try to > > make the connection until the pack is generated, so even if we do what I > > suggested might be a problem above, that wouldn't affect HTTPS. > > > > I will mention that the repository you mentioned there contains a large > > number of TIFF images about 1–2 MB in size. These TIFFs appear to be > > using JPEG compression, so when Git tries to deltify them (during the > > "Compressing objects" stage), that step is just going to waste a lot of > > CPU and take a long time, since trying to deltify compressed objects > > doesn't work and is just slow. That's contributing to the slow push > > performance. > > > > In general, Git is not a great way to store large numbers of compressed > > images. If you're going to store images in your repository, you should > > make them uncompressed (which you can do with TIFFs) so that Git can > > store them more efficiently. What would be even better, since your data > > appears to be effectively a book, is to store the data as text, possibly > > with a small set of images for illustrations, instead of storing the > > book as a set of images. That would be much more searchable and > > accessible as well. The Git FAQ[0] mentions this and makes > > recommendations on approach. > > > > Overall, I would not say this is a bug in Git. Pushing over HTTPS may > > help you get your pushes working in a more robust way, but in general, > > I'd recommend storing the data in your repository differently. > > > > [0] https://git-scm.com/docs/gitfaq#recommended-storage-settings > > -- > > brian m. carlson (they/them or he/him) > > Toronto, Ontario, CA
Attachment:
publickey - A_bughunter@proton.me - 0x66540805.asc
Description: application/pgp-keys
