{"thread":{"id":"59019","subject":"is this data corruption?","startedAt":"2022-12-31T00:18:02Z","lastAt":"2023-01-01T04:48:59Z","messageCount":9,"participants":["Samuel Wales","rsbecker@nexbridge.com","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"469699","messageId":"CAJcAo8tjMLFisK5_13iD_JGo2xVQDJRX3wAC7wRD_V2GKFGevQ@mail.gmail.com","threadId":"59019","inReplyTo":null,"subject":"is this data corruption?","fromName":"Samuel Wales","fromEmail":"samologist@gmail.com","sentAt":"2022-12-31T00:17:51Z","receivedAt":"2022-12-31T00:18:02Z","isPatch":false,"sender":{"key":"samologist@gmail.com","avatar":null},"body":"i am not subscribed, but am of the impression that's ok.  please copy\nme directly.\n\n\ntldr: git diff is showing differences that do not exist in the files themselves.\n\ni have nothing staged, nothing fancy like stashing, etc.  this is a\nrepo of mostly emacs org mode files.  mostly ascii text.\n\ngit status and these commands show nothing unusual:\n\n    git fsck --strict --no-dangling\n    git gc --prune=\"0 days\"\n\n\nthe problem that seems like data corruption is that a few lines appear\ntwice as - and once as +.  but in the current version of the files,\nthose lines exist only once.  here are the lines.  there are 2 -\nversions and one + version:\n\n+***************** REF bigpart is a partition\n+biglike and homelike are distracting nonsense i think except\n+to describe inferior filesets.  anomalous subset of home\n+might be called homelike or so.\n\n\nemacs magit shows the same problem.  however, it shows a slightly\ndifferent diff.  i did a meta-diff on git diff vs. magit, and there\nare about 800 + real-content lines that magit shows but git diff does\nnot.  i do not know what this means.  wc -l is like\n\n  62540 aaa.diff\n  62965 bbb--magit.txt\n\nidk why a diff would be different with only + lines being different?\n\n\nin summary, what is wrong with my repo, if anything, and what can i do\nabout it?  nothing on the web for git corruption seems to say much,\nother than pull from github or whatever.  this is my own repo, the\noriginal repo, so i cannot do that.  org annex has an uncorrupt tool\nof some kind, but it did not seem relevant.  i do have rsnapshot\n[basically rsync] backups of the repo and the most significant files\nand dirs, but i do not know what one does to use that to repair any\nissues.  i won't get into why, but changes were made over months.\n\nis there a protocol for this?\n\nwould git fsck have balked?\n\nthank you!\n\n\np.s.\n\ni have no reason to believe this is related, but git diff has\nintermingled emacs org mode entries.  but i don't have to talk about\nit in org terms; in generic text terms, it has intermingled parts of\ndifferent paragraphs.  as a user, i'd prefer that completely unrelated\nparagraphs not be mingled, regardless of minimality.  if possible.\n\nwith respect to the intermingling only, unless this is related to the\npossible corruption, i will presume the diff is correct, in that a\npatch from it would produce the same result as a patch that does not\nintermingle.  i believe this intermingling is because diff does not\nunderstand org, or paragraphs for that matter.  in org, an entry\nstarts with \"^[*]+ \" and ends at the beginning of another entry or at\neof.  they consist in my case mostly of ascii text paragraphs.  just\nas with paragraphs, if you move an entry, you don't expect it to be\nmingled with a different one in the diff.\n\ni have been told that this cannot be fixed by merely telling a\nslightly improved differ that stuff between stars is worth preserving,\nbut that a parser, not merely a couple of regexps, is needed to reduce\nthis intermingling.  i have also been told that difftastic uses\ntree-sitter, which might get such a syntax for emacs org mode.  and so\nmaybe at some point git diff can use that.  idk.\n\nidk if any of this is related but i include it for completeness.\n\nalso, please don't laugh, but i am using git version 2.11.0.  i will\nupgrade pending various library and os stuff but my main concern is\nnot for git, but for possible corruption in the repo and what is\npossible to do, at least given rsnapshot, to fix it.\n"},{"id":"469700","messageId":"000701d91cae$6c8cbbf0$45a633d0$@nexbridge.com","threadId":"59019","inReplyTo":"CAJcAo8tjMLFisK5_13iD_JGo2xVQDJRX3wAC7wRD_V2GKFGevQ@mail.gmail.com","subject":"RE: is this data corruption?","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-12-31T00:25:39Z","receivedAt":"2022-12-31T00:25:50Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On December 30, 2022 7:18 PM, Samuel Wales wrote:\n>i am not subscribed, but am of the impression that's ok.  please copy me directly.\n>\n>\n>tldr: git diff is showing differences that do not exist in the files themselves.\n>\n>i have nothing staged, nothing fancy like stashing, etc.  this is a repo of mostly\n>emacs org mode files.  mostly ascii text.\n>\n>git status and these commands show nothing unusual:\n>\n>    git fsck --strict --no-dangling\n>    git gc --prune=\"0 days\"\n>\n>\n>the problem that seems like data corruption is that a few lines appear twice as -\n>and once as +.  but in the current version of the files, those lines exist only once.\n>here are the lines.  there are 2 - versions and one + version:\n>\n>+***************** REF bigpart is a partition biglike and homelike are\n>+distracting nonsense i think except to describe inferior filesets.\n>+anomalous subset of home might be called homelike or so.\n>\n>\n>emacs magit shows the same problem.  however, it shows a slightly different diff.\n>i did a meta-diff on git diff vs. magit, and there are about 800 + real-content lines\n>that magit shows but git diff does not.  i do not know what this means.  wc -l is like\n>\n>  62540 aaa.diff\n>  62965 bbb--magit.txt\n>\n>idk why a diff would be different with only + lines being different?\n>\n>\n>in summary, what is wrong with my repo, if anything, and what can i do about it?\n>nothing on the web for git corruption seems to say much, other than pull from\n>github or whatever.  this is my own repo, the original repo, so i cannot do that.  org\n>annex has an uncorrupt tool of some kind, but it did not seem relevant.  i do have\n>rsnapshot [basically rsync] backups of the repo and the most significant files and\n>dirs, but i do not know what one does to use that to repair any issues.  i won't get\n>into why, but changes were made over months.\n>\n>is there a protocol for this?\n>\n>would git fsck have balked?\n>\n>thank you!\n>\n>\n>p.s.\n>\n>i have no reason to believe this is related, but git diff has intermingled emacs org\n>mode entries.  but i don't have to talk about it in org terms; in generic text terms, it\n>has intermingled parts of different paragraphs.  as a user, i'd prefer that\n>completely unrelated paragraphs not be mingled, regardless of minimality.  if\n>possible.\n>\n>with respect to the intermingling only, unless this is related to the possible\n>corruption, i will presume the diff is correct, in that a patch from it would produce\n>the same result as a patch that does not intermingle.  i believe this intermingling is\n>because diff does not understand org, or paragraphs for that matter.  in org, an\n>entry starts with \"^[*]+ \" and ends at the beginning of another entry or at eof.\n>they consist in my case mostly of ascii text paragraphs.  just as with paragraphs, if\n>you move an entry, you don't expect it to be mingled with a different one in the\n>diff.\n>\n>i have been told that this cannot be fixed by merely telling a slightly improved\n>differ that stuff between stars is worth preserving, but that a parser, not merely a\n>couple of regexps, is needed to reduce this intermingling.  i have also been told\n>that difftastic uses tree-sitter, which might get such a syntax for emacs org mode.\n>and so maybe at some point git diff can use that.  idk.\n>\n>idk if any of this is related but i include it for completeness.\n>\n>also, please don't laugh, but i am using git version 2.11.0.  i will upgrade pending\n>various library and os stuff but my main concern is not for git, but for possible\n>corruption in the repo and what is possible to do, at least given rsnapshot, to fix it.\n\nI cannot account for your emacs issues, but have a question. Have you done any git add operations? Git diff is subject to what specifically is staged. So you might be comparing your file with partially staged content that could account for partial diffs. See if diff --cached makes a difference. Also try different algorithms, like --patience or --diff-algorithm=histogram.\n\n--Randall\n\n"},{"id":"469701","messageId":"CAJcAo8smwU2ddB96J+G2SOAP+FU2p4ejB2JX9+5QHdQEn43htQ@mail.gmail.com","threadId":"59019","inReplyTo":"CAJcAo8tjMLFisK5_13iD_JGo2xVQDJRX3wAC7wRD_V2GKFGevQ@mail.gmail.com","subject":"Re: is this data corruption?","fromName":"Samuel Wales","fromEmail":"samologist@gmail.com","sentAt":"2022-12-31T00:33:20Z","receivedAt":"2022-12-31T00:33:29Z","isPatch":false,"sender":{"key":"samologist@gmail.com","avatar":null},"body":"p.p.s.  git 2.20 has the same problem.\n\nOn 12/30/22, Samuel Wales <samologist@gmail.com> wrote:\n> i am not subscribed, but am of the impression that's ok.  please copy\n> me directly.\n>\n>\n> tldr: git diff is showing differences that do not exist in the files\n> themselves.\n>\n> i have nothing staged, nothing fancy like stashing, etc.  this is a\n> repo of mostly emacs org mode files.  mostly ascii text.\n>\n> git status and these commands show nothing unusual:\n>\n>     git fsck --strict --no-dangling\n>     git gc --prune=\"0 days\"\n>\n>\n> the problem that seems like data corruption is that a few lines appear\n> twice as - and once as +.  but in the current version of the files,\n> those lines exist only once.  here are the lines.  there are 2 -\n> versions and one + version:\n>\n> +***************** REF bigpart is a partition\n> +biglike and homelike are distracting nonsense i think except\n> +to describe inferior filesets.  anomalous subset of home\n> +might be called homelike or so.\n>\n>\n> emacs magit shows the same problem.  however, it shows a slightly\n> different diff.  i did a meta-diff on git diff vs. magit, and there\n> are about 800 + real-content lines that magit shows but git diff does\n> not.  i do not know what this means.  wc -l is like\n>\n>   62540 aaa.diff\n>   62965 bbb--magit.txt\n>\n> idk why a diff would be different with only + lines being different?\n>\n>\n> in summary, what is wrong with my repo, if anything, and what can i do\n> about it?  nothing on the web for git corruption seems to say much,\n> other than pull from github or whatever.  this is my own repo, the\n> original repo, so i cannot do that.  org annex has an uncorrupt tool\n> of some kind, but it did not seem relevant.  i do have rsnapshot\n> [basically rsync] backups of the repo and the most significant files\n> and dirs, but i do not know what one does to use that to repair any\n> issues.  i won't get into why, but changes were made over months.\n>\n> is there a protocol for this?\n>\n> would git fsck have balked?\n>\n> thank you!\n>\n>\n> p.s.\n>\n> i have no reason to believe this is related, but git diff has\n> intermingled emacs org mode entries.  but i don't have to talk about\n> it in org terms; in generic text terms, it has intermingled parts of\n> different paragraphs.  as a user, i'd prefer that completely unrelated\n> paragraphs not be mingled, regardless of minimality.  if possible.\n>\n> with respect to the intermingling only, unless this is related to the\n> possible corruption, i will presume the diff is correct, in that a\n> patch from it would produce the same result as a patch that does not\n> intermingle.  i believe this intermingling is because diff does not\n> understand org, or paragraphs for that matter.  in org, an entry\n> starts with \"^[*]+ \" and ends at the beginning of another entry or at\n> eof.  they consist in my case mostly of ascii text paragraphs.  just\n> as with paragraphs, if you move an entry, you don't expect it to be\n> mingled with a different one in the diff.\n>\n> i have been told that this cannot be fixed by merely telling a\n> slightly improved differ that stuff between stars is worth preserving,\n> but that a parser, not merely a couple of regexps, is needed to reduce\n> this intermingling.  i have also been told that difftastic uses\n> tree-sitter, which might get such a syntax for emacs org mode.  and so\n> maybe at some point git diff can use that.  idk.\n>\n> idk if any of this is related but i include it for completeness.\n>\n> also, please don't laugh, but i am using git version 2.11.0.  i will\n> upgrade pending various library and os stuff but my main concern is\n> not for git, but for possible corruption in the repo and what is\n> possible to do, at least given rsnapshot, to fix it.\n>\n\n\n-- \nThe Kafka Pandemic\n\nA blog about science, health, human rights, and misopathy:\nhttps://thekafkapandemic.blogspot.com\n"},{"id":"469702","messageId":"CAJcAo8tY55sUNr=HX9-tVPYDoSOx-xkH0WtZuXuLqs0S3sXu-A@mail.gmail.com","threadId":"59019","inReplyTo":"000701d91cae$6c8cbbf0$45a633d0$@nexbridge.com","subject":"Re: is this data corruption?","fromName":"Samuel Wales","fromEmail":"samologist@gmail.com","sentAt":"2022-12-31T00:57:06Z","receivedAt":"2022-12-31T00:57:12Z","isPatch":false,"sender":{"key":"samologist@gmail.com","avatar":null},"body":"more below.\n\nOn 12/30/22, rsbecker@nexbridge.com <rsbecker@nexbridge.com> wrote:\n> On December 30, 2022 7:18 PM, Samuel Wales wrote:\n>>i am not subscribed, but am of the impression that's ok.  please copy me\n>> directly.\n\n...\n\n> I cannot account for your emacs issues, but have a question. Have you done\n> any git add operations? Git diff is subject to what specifically is staged.\n\nidk what this means.  there is nothing in the staging area at this\ntime, if that is relevant.\n\n> So you might be comparing your file with partially staged content that could\n> account for partial diffs. See if diff --cached makes a difference. Also try\n\ndiff --cached produces nothing.  0 bytes.\n\n> different algorithms, like --patience or --diff-algorithm=histogram.\n\ni tried both with git 2.20.  they produce different output from\nregular git diff.  i looked for the paragraph i mentioned.  in regular\ngit diff, the problem is the same as i described, with - - +.  in both\npatience and histogram, it is -.\n\nit occurs to me that, although unlikely, i might have in principle had\na duplicate copy of those lines in A, and deleted one, and moved the\nother, when i created the current version, B. thus, i /think/ both\nregular and patience/histogram could be /in principle/ correct on that\none point.  to confirm, i will check rsnapshot using grep -c to count\nthe matches in all versions of the original files.  unless i report\nback, the number will be 1 in all of them, i.e. git diff and magit\nstatus buffer are both producing an incorrect diff.\n\nhowever, even if this is user error, i.e., i deleted a duplicate and\nmoved it, the patience/histogram - result seems still incorrect:\n\n The next few commands work with both grub> and grub rescue>.\n-***************** REF bigpart is a partition\n-biglike and homelike are distracting nonsense i think except\n-to describe inferior filesets.  anomalous subset of home\n-might be called homelike or so.\n\n 1) The first command you should run invokes the pager, for\n\nyou can see here that the context lines are from a different org\nentry.  it is intermingling a live - line with a context line that is\nnot adjacent to it.  that seems corrupt unless i, even more\nimprobably, moved an entry from inside another entry.\n\n>\n> --Randall\n\n\n\n>\n>\n\n\n-- \nThe Kafka Pandemic\n\nA blog about science, health, human rights, and misopathy:\nhttps://thekafkapandemic.blogspot.com\n"},{"id":"469718","messageId":"CAJcAo8syzh3-R2RQVQJtv+eZiwLjmdKm7+MUYqt1BcX2Jz7XZA@mail.gmail.com","threadId":"59019","inReplyTo":"000701d91cae$6c8cbbf0$45a633d0$@nexbridge.com","subject":"Re: is this data corruption?","fromName":"Samuel Wales","fromEmail":"samologist@gmail.com","sentAt":"2023-01-01T01:14:38Z","receivedAt":"2023-01-01T01:14:45Z","isPatch":false,"sender":{"key":"samologist@gmail.com","avatar":null},"body":"r> Have you done any git add operations?\n\ni presume this is staging.  i do staging in magit all the time.  but\nright now the staging area is empty and so is diff --cached.\n\nOn 12/30/22, rsbecker@nexbridge.com <rsbecker@nexbridge.com> wrote:\n> On December 30, 2022 7:18 PM, Samuel Wales wrote:\n>>i am not subscribed, but am of the impression that's ok.  please copy me\n>> directly.\n>>\n>>\n>>tldr: git diff is showing differences that do not exist in the files\n>> themselves.\n>>\n>>i have nothing staged, nothing fancy like stashing, etc.  this is a repo of\n>> mostly\n>>emacs org mode files.  mostly ascii text.\n>>\n>>git status and these commands show nothing unusual:\n>>\n>>    git fsck --strict --no-dangling\n>>    git gc --prune=\"0 days\"\n>>\n>>\n>>the problem that seems like data corruption is that a few lines appear\n>> twice as -\n>>and once as +.  but in the current version of the files, those lines exist\n>> only once.\n>>here are the lines.  there are 2 - versions and one + version:\n>>\n>>+***************** REF bigpart is a partition biglike and homelike are\n>>+distracting nonsense i think except to describe inferior filesets.\n>>+anomalous subset of home might be called homelike or so.\n>>\n>>\n>>emacs magit shows the same problem.  however, it shows a slightly different\n>> diff.\n>>i did a meta-diff on git diff vs. magit, and there are about 800 +\n>> real-content lines\n>>that magit shows but git diff does not.  i do not know what this means.  wc\n>> -l is like\n>>\n>>  62540 aaa.diff\n>>  62965 bbb--magit.txt\n>>\n>>idk why a diff would be different with only + lines being different?\n>>\n>>\n>>in summary, what is wrong with my repo, if anything, and what can i do\n>> about it?\n>>nothing on the web for git corruption seems to say much, other than pull\n>> from\n>>github or whatever.  this is my own repo, the original repo, so i cannot do\n>> that.  org\n>>annex has an uncorrupt tool of some kind, but it did not seem relevant.  i\n>> do have\n>>rsnapshot [basically rsync] backups of the repo and the most significant\n>> files and\n>>dirs, but i do not know what one does to use that to repair any issues.  i\n>> won't get\n>>into why, but changes were made over months.\n>>\n>>is there a protocol for this?\n>>\n>>would git fsck have balked?\n>>\n>>thank you!\n>>\n>>\n>>p.s.\n>>\n>>i have no reason to believe this is related, but git diff has intermingled\n>> emacs org\n>>mode entries.  but i don't have to talk about it in org terms; in generic\n>> text terms, it\n>>has intermingled parts of different paragraphs.  as a user, i'd prefer\n>> that\n>>completely unrelated paragraphs not be mingled, regardless of minimality.\n>> if\n>>possible.\n>>\n>>with respect to the intermingling only, unless this is related to the\n>> possible\n>>corruption, i will presume the diff is correct, in that a patch from it\n>> would produce\n>>the same result as a patch that does not intermingle.  i believe this\n>> intermingling is\n>>because diff does not understand org, or paragraphs for that matter.  in\n>> org, an\n>>entry starts with \"^[*]+ \" and ends at the beginning of another entry or at\n>> eof.\n>>they consist in my case mostly of ascii text paragraphs.  just as with\n>> paragraphs, if\n>>you move an entry, you don't expect it to be mingled with a different one\n>> in the\n>>diff.\n>>\n>>i have been told that this cannot be fixed by merely telling a slightly\n>> improved\n>>differ that stuff between stars is worth preserving, but that a parser, not\n>> merely a\n>>couple of regexps, is needed to reduce this intermingling.  i have also\n>> been told\n>>that difftastic uses tree-sitter, which might get such a syntax for emacs\n>> org mode.\n>>and so maybe at some point git diff can use that.  idk.\n>>\n>>idk if any of this is related but i include it for completeness.\n>>\n>>also, please don't laugh, but i am using git version 2.11.0.  i will\n>> upgrade pending\n>>various library and os stuff but my main concern is not for git, but for\n>> possible\n>>corruption in the repo and what is possible to do, at least given\n>> rsnapshot, to fix it.\n>\n> I cannot account for your emacs issues, but have a question. Have you done\n> any git add operations? Git diff is subject to what specifically is staged.\n> So you might be comparing your file with partially staged content that could\n> account for partial diffs. See if diff --cached makes a difference. Also try\n> different algorithms, like --patience or --diff-algorithm=histogram.\n>\n> --Randall\n>\n>\n\n\n-- \nThe Kafka Pandemic\n\nA blog about science, health, human rights, and misopathy:\nhttps://thekafkapandemic.blogspot.com\n"},{"id":"469719","messageId":"CAJcAo8scjTMqUGsJ8BDp95avmmv1vEvEUx-iqNvN14f9VkkTGg@mail.gmail.com","threadId":"59019","inReplyTo":"CAJcAo8tY55sUNr=HX9-tVPYDoSOx-xkH0WtZuXuLqs0S3sXu-A@mail.gmail.com","subject":"Re: is this data corruption?","fromName":"Samuel Wales","fromEmail":"samologist@gmail.com","sentAt":"2023-01-01T01:15:08Z","receivedAt":"2023-01-01T01:15:14Z","isPatch":false,"sender":{"key":"samologist@gmail.com","avatar":null},"body":"as expected, there is only one copy of bigpart is a partition in all\nof my rsnapshot files and all of my emacs backup files.\n\ntherefore, the diff in git and magit are incorrect.  it was not a\nquestion of me removing a duplicate.\n\nfor future reference, is this mailing list correct for this question\nor should i use the git help list which i discovered just now?\n\n\nOn 12/30/22, Samuel Wales <samologist@gmail.com> wrote:\n> more below.\n>\n> On 12/30/22, rsbecker@nexbridge.com <rsbecker@nexbridge.com> wrote:\n>> On December 30, 2022 7:18 PM, Samuel Wales wrote:\n>>>i am not subscribed, but am of the impression that's ok.  please copy me\n>>> directly.\n>\n> ...\n>\n>> I cannot account for your emacs issues, but have a question. Have you\n>> done\n>> any git add operations? Git diff is subject to what specifically is\n>> staged.\n>\n> idk what this means.  there is nothing in the staging area at this\n> time, if that is relevant.\n>\n>> So you might be comparing your file with partially staged content that\n>> could\n>> account for partial diffs. See if diff --cached makes a difference. Also\n>> try\n>\n> diff --cached produces nothing.  0 bytes.\n>\n>> different algorithms, like --patience or --diff-algorithm=histogram.\n>\n> i tried both with git 2.20.  they produce different output from\n> regular git diff.  i looked for the paragraph i mentioned.  in regular\n> git diff, the problem is the same as i described, with - - +.  in both\n> patience and histogram, it is -.\n>\n> it occurs to me that, although unlikely, i might have in principle had\n> a duplicate copy of those lines in A, and deleted one, and moved the\n> other, when i created the current version, B. thus, i /think/ both\n> regular and patience/histogram could be /in principle/ correct on that\n> one point.  to confirm, i will check rsnapshot using grep -c to count\n> the matches in all versions of the original files.  unless i report\n> back, the number will be 1 in all of them, i.e. git diff and magit\n> status buffer are both producing an incorrect diff.\n>\n> however, even if this is user error, i.e., i deleted a duplicate and\n> moved it, the patience/histogram - result seems still incorrect:\n>\n>  The next few commands work with both grub> and grub rescue>.\n> -***************** REF bigpart is a partition\n> -biglike and homelike are distracting nonsense i think except\n> -to describe inferior filesets.  anomalous subset of home\n> -might be called homelike or so.\n>\n>  1) The first command you should run invokes the pager, for\n>\n> you can see here that the context lines are from a different org\n> entry.  it is intermingling a live - line with a context line that is\n> not adjacent to it.  that seems corrupt unless i, even more\n> improbably, moved an entry from inside another entry.\n>\n>>\n>> --Randall\n>\n>\n>\n>>\n>>\n>\n>\n> --\n> The Kafka Pandemic\n>\n> A blog about science, health, human rights, and misopathy:\n> https://thekafkapandemic.blogspot.com\n>\n\n\n-- \nThe Kafka Pandemic\n\nA blog about science, health, human rights, and misopathy:\nhttps://thekafkapandemic.blogspot.com\n"},{"id":"469723","messageId":"xmqqlemmhp97.fsf@gitster.g","threadId":"59019","inReplyTo":"CAJcAo8tjMLFisK5_13iD_JGo2xVQDJRX3wAC7wRD_V2GKFGevQ@mail.gmail.com","subject":"Re: is this data corruption?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-01-01T04:07:00Z","receivedAt":"2023-01-01T04:07:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Samuel Wales <samologist@gmail.com> writes:\n\n> the problem that seems like data corruption is that a few lines appear\n> twice as - and once as +.  but in the current version of the files,\n> those lines exist only once.  here are the lines.  there are 2 -\n> versions and one + version:\n>\n> +***************** REF bigpart is a partition\n> +biglike and homelike are distracting nonsense i think except\n> +to describe inferior filesets.  anomalous subset of home\n> +might be called homelike or so.\n\nSorry, but I do not see any \"-\" versions in the above.  Simple and\nminimum reproduction recipe would be useful for the list to help.\n\nhttps://www.chiark.greenend.org.uk/~sgtatham/bugs.html\n\nThanks.\n"},{"id":"469726","messageId":"CAJcAo8sJo8mE5V8_3eGj3miirNOJfQGsDH+=7HmSrwvLC=Ch3w@mail.gmail.com","threadId":"59019","inReplyTo":"xmqqlemmhp97.fsf@gitster.g","subject":"Re: is this data corruption?","fromName":"Samuel Wales","fromEmail":"samologist@gmail.com","sentAt":"2023-01-01T04:46:29Z","receivedAt":"2023-01-01T04:46:36Z","isPatch":false,"sender":{"key":"samologist@gmail.com","avatar":null},"body":"hi,\n\nthanks for reading/thinking.\n\n> Sorry, but I do not see any \"-\" versions in the above.  Simple and\nminimum reproduction recipe would be useful for the list to help.\n\nthe - versions are identical.  as i wrote, there are 2 - versions in\naddition.  i didn't want to make a pointlessly long email.\n\nit would be great if i could provide a reproduction recipe.  i don't\nknow how i couold do that in this case.  for example, when i try to\npare down the repo and make private things obscured, i run into the\nproble that when i do staging, things change around, thus erasing that\nparticular bug.  and other stuff like my limited knowledge of git.\n\ni'm afraid i am stuck with hoping for other types of solutions like\n\"i've seen this before\" or \"that's not possuble unless...\"or something\na priori like that.  but if you have an idea of how to create a\nminimal repro in less than a week, let me know.\n\n\nOn 12/31/22, Junio C Hamano <gitster@pobox.com> wrote:\n> Samuel Wales <samologist@gmail.com> writes:\n>\n>> the problem that seems like data corruption is that a few lines appear\n>> twice as - and once as +.  but in the current version of the files,\n>> those lines exist only once.  here are the lines.  there are 2 -\n>> versions and one + version:\n>>\n>> +***************** REF bigpart is a partition\n>> +biglike and homelike are distracting nonsense i think except\n>> +to describe inferior filesets.  anomalous subset of home\n>> +might be called homelike or so.\n>\n> Sorry, but I do not see any \"-\" versions in the above.  Simple and\n> minimum reproduction recipe would be useful for the list to help.\n>\n> https://www.chiark.greenend.org.uk/~sgtatham/bugs.html\n>\n> Thanks.\n>\n\n\n-- \nThe Kafka Pandemic\n\nA blog about science, health, human rights, and misopathy:\nhttps://thekafkapandemic.blogspot.com\n"},{"id":"469727","messageId":"CAJcAo8sBT26BNg4j9EPCqwxpFF36QVMEqQnUDhqXQ3UH3AOPjA@mail.gmail.com","threadId":"59019","inReplyTo":"CAJcAo8sJo8mE5V8_3eGj3miirNOJfQGsDH+=7HmSrwvLC=Ch3w@mail.gmail.com","subject":"Re: is this data corruption?","fromName":"Samuel Wales","fromEmail":"samologist@gmail.com","sentAt":"2023-01-01T04:48:51Z","receivedAt":"2023-01-01T04:48:59Z","isPatch":false,"sender":{"key":"samologist@gmail.com","avatar":null},"body":"of course i am still hoping, if possible,for generic adice on\nrepairing a repo, detecting a bug, whether it is a bug, what looks\ncuriously strange, maybe some more questions like the previous one\nabout what does --cached say, what does --histogram and --patience do,\netc., any of this whether or not a repro is possible.  will repro if\npossible just seems impossible.\n\nOn 12/31/22, Samuel Wales <samologist@gmail.com> wrote:\n> hi,\n>\n> thanks for reading/thinking.\n>\n>> Sorry, but I do not see any \"-\" versions in the above.  Simple and\n> minimum reproduction recipe would be useful for the list to help.\n>\n> the - versions are identical.  as i wrote, there are 2 - versions in\n> addition.  i didn't want to make a pointlessly long email.\n>\n> it would be great if i could provide a reproduction recipe.  i don't\n> know how i couold do that in this case.  for example, when i try to\n> pare down the repo and make private things obscured, i run into the\n> proble that when i do staging, things change around, thus erasing that\n> particular bug.  and other stuff like my limited knowledge of git.\n>\n> i'm afraid i am stuck with hoping for other types of solutions like\n> \"i've seen this before\" or \"that's not possuble unless...\"or something\n> a priori like that.  but if you have an idea of how to create a\n> minimal repro in less than a week, let me know.\n>\n>\n> On 12/31/22, Junio C Hamano <gitster@pobox.com> wrote:\n>> Samuel Wales <samologist@gmail.com> writes:\n>>\n>>> the problem that seems like data corruption is that a few lines appear\n>>> twice as - and once as +.  but in the current version of the files,\n>>> those lines exist only once.  here are the lines.  there are 2 -\n>>> versions and one + version:\n>>>\n>>> +***************** REF bigpart is a partition\n>>> +biglike and homelike are distracting nonsense i think except\n>>> +to describe inferior filesets.  anomalous subset of home\n>>> +might be called homelike or so.\n>>\n>> Sorry, but I do not see any \"-\" versions in the above.  Simple and\n>> minimum reproduction recipe would be useful for the list to help.\n>>\n>> https://www.chiark.greenend.org.uk/~sgtatham/bugs.html\n>>\n>> Thanks.\n>>\n>\n>\n> --\n> The Kafka Pandemic\n>\n> A blog about science, health, human rights, and misopathy:\n> https://thekafkapandemic.blogspot.com\n>\n\n\n-- \nThe Kafka Pandemic\n\nA blog about science, health, human rights, and misopathy:\nhttps://thekafkapandemic.blogspot.com\n"}]}