i just remembered 2 more questions that prompted me to make the previous query.
1. is it possible to track corruption by keeping a copy of the working tree or so, such that a program or script will detect corruption of any type? 2. does such a script or program exist? 3. is there a stress tester for magit or git that would work on real repos? or perhaps at least on fake ones? intra-hunk? On 1/14/23, Samuel Wales <samolog...@gmail.com> wrote: > in my /old/ version of magit, i have positively found at least one, > probably two, cases where intra-hunk operations cause corruption. i > doubt anybody uses this version, and i don't know if i have notes that > say what to do to repro it. > > it is not clear to me whether staging and unstaging alone can cause > the corruption, or whether killing is necessary. i have a note saying > that it doesn't really make sense for staging and unstaging alone to > do it, but i am not sure if that is so. > > and there is the question of what kinds of git corruption are > possible. i do not know. i have seen that the actual working tree > data get corrupted. in one bug, individual line sequences can change. > > in the other, i get duplication and strange errors in magit > operations, the only one i remember of which is that git is still > running. i think it is possible in principle that i have seen > corruption in git and not in git. i.e. in the latter case, the > corruption shows up in git diff or git log as you would expect, but it > isn't really a git issue. in the former, i am not sure. > > i did find a bug report related to corruption at > https://github.com/magit/magit/issues/3182 and iirc they concluded > that it didn't exist, or if it did, it was a git bug. or similar. > idk if this is related to either bug that i found. > > the first bug, line sequences, concerns e.g. marking a single line, > and staging and unstaging, and idk if killing or even resetting is > necessary to repro, but after these operations, sequence is incorrect. > it takes maybe 3 actions to do. > > > although i am not ready to upgrade to modern org yet for a few > reasons, one of which is my need for --- +++ headers, i am curious > about a few things. i guess i will try to make a list of my > questions: > > 1. what does modern org do against corruption of any type? is it > possible without e.g. fs corruption or user error? > > 2. what kinds of /git/ corruption are possible? > > 3. which ones do not show up in git-fsck? > > 4. have there ever been any other concerns about intra-hunk > operations causing corruption? > > at some point i will likely upgrade, but i will not do so for some > time probably. these questions, if desired to answer, will give me an > idea of what to expect, or at least, help me understand magit and git > and their interaction a little better. > > for reference, my source files are org-mode. the second set of buggy > behavior relates to a previous commit containing an org file with an > entry strangely inside another entry. different diff algorithms show > up later with different strange results. > > > On 11/20/22, Samuel Wales <samolog...@gmail.com> wrote: >> great answer, thank you. >> >> for clarity, the REASON i use a paleolithic version of magit is that i >> need those headers. :) i'll try to stick with old magit for the time >> being; dunno if emacs upgrades will allow that. >> >> >> On 11/20/22, Jonas Bernoulli <jo...@bernoul.li> wrote: >>> Samuel Wales <samolog...@gmail.com> writes: >>> >>>> i am currently using a version of emacs that is probably not supported >>>> by modern magit. i tried it, anyway. >>> >>> You'll need at least Emacs 25.1. >>> >>>> in any case, however, i have been using a paleolithic version of >>>> magit, because it shows --- +++ headers in the status buffer. >>> >>> Very old indeed. >>> >>>> at some >>>> point, magit stopped showing those. but i have searched recently, and >>>> maybe it can show them? >>> >>> No, that's not possible anymore. The information in those lines is >>> quite redundant. In the future it be become possible to show those >>> lines again, for the sake of doing the same as other tools (okay and >>> also to be able to copy-paste into those other tools). But this is >>> a very low priority, i.e., this might become possible again as a >>> side-effect of large changes, not because it is a goal in itself. >>> >>>> i found magit-insert-status-headers in what look like remarkably >>>> comprehensive online docs, but also a report that it is/was slow >>>> [which doesn't really make sense if it is for --- +++ headers]. >>> >>> This function is unrelated. It is responsible for showing the >>> information at the very top of the status buffer, such as the current >>> branch and its upstream. And the latest tag--that's the part that can >>> be very slow in some repositories. >>> >>>> does modern magit support --- +++ headers? >>>> >>>> anything else i might like to know about modern magit? it seems a lot >>>> of development has occurred. >>> >>> Err...yes. Tons of new stuff. It generally dwims more. >>> >>>> it seems the package is still well received. >>>> >>>> thanks! :). >>> >>> Cheers, >>> Jonas >>> >> >> >> -- >> The Kafka Pandemic >> >> A blog about science, health, human rights, and misopathy: >> https://thekafkapandemic.blogspot.com >> > > > -- > The Kafka Pandemic > > A blog about science, health, human rights, and misopathy: > https://thekafkapandemic.blogspot.com > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com -- You received this message because you are subscribed to the Google Groups "magit" group. To unsubscribe from this group and stop receiving emails from it, send an email to magit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/magit/CAJcAo8sa3rcM4YxWdWD_xioJYSGPwaOJZ5ja0s0pJ15-%3DoqbuQ%40mail.gmail.com.
