From: Samuel Wales <samologist@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [OT] org and diff
Date: Fri, 16 Dec 2022 19:06:46 -0700 [thread overview]
Message-ID: <CAJcAo8ti6MmUtZyY8zFOvAGSVp40Yzop2yFB30EOZEdONyFWEA@mail.gmail.com> (raw)
In-Reply-To: <CAJcAo8vtunPwFATaorDEOALC_PzLm3vgHfB7VmvKYDnTVJ5oAQ@mail.gmail.com>
marcin> One question I'd ask is: how important a legible diff is to
you? I keep my Org files in Git, too, but if /I/ know what was
changed, I just don't care about diff going nuts and I treat it as
(more or less) Git's internal implementation detail.
for org, i mostly use git for reviewing changes. it is only one step
more sophisticated than saving old and diffing.
i have lots of tools for improving diff, but this intermingling
problem is a showstopper in some cases, like right now where i have
spent months trying to make sense of months of changes to org files
that have not been entered into git. i.e. i did not enter every few
days as normal. i find reviewing changes to be valuable. every once
in a while i discover data corruption or something that i forgot etc.
i wonder if diff, or difftastic, could be taught or postprocessed to
do merely one thing: try to preserve stuff between "^\\*+ ". that is
probably too optimistic, but imagine a --preserve-between option.
On 11/21/22, Samuel Wales <samologist@gmail.com> wrote:
> incidentally, if you want empty hunk headers, you can do this at least
> in my version of git:
>
> xfuncname = " "
>
> but idk why it works and i had had it commented out.
>
>
> On 11/21/22, Samuel Wales <samologist@gmail.com> wrote:
>> p.s. hunk header munging does not unmingle [i.e. group changes by org
>> header in magit status buffer diffs] :(. but it is true that what i
>> want is some kind of preference given by magit to org entries as
>> demarcated by org headings.
>>
>> idk if what i want is in principle possible or not in standard diff or
>> git diff. that is, idk if they could be patched to accept an arg that
>> would allow you to specify that org entries should be preserved if
>> possible or something like that.
>>
>> great to know difftastic can in principle be coded to do what i want,
>> however. so maybe soetime you could tell git to use.
>>
>> org hunk headers are rather nice looking. on the other hand, it gets
>> the previous header, even if not the parent header. i think this is
>> why i had the impression that git was in principle incapable of org
>> hunk header text of the type i wanted. but hunk header text is not
>> something i use a lot. it's rather nice looking, but in some cases i
>> prefer empty hunk headers.
>>
>> On 11/12/22, Samuel Wales <samologist@gmail.com> wrote:
>>> i have a very old version of Magit, for reasons I won't get into.
>>> Fancier diff settings might be differnet or not available.
>>>
>>> But something drives me crazy. Probably not too Org-related, but it
>>> might be. I just want to know why, is all.
>>>
>>> I have a 24k line org file, and it's not that complex wrt levels. 2
>>> or 3 levels with odd stars only. various types of content.
>>>
>>> someplace in it, is an entry with a 234-item plain list. if i try to
>>> move this entry, and make no other changes, diff goes insane. if i
>>> try to refile this entry to a different org file, diff similarly goes
>>> insane, with the - part. only that change.
>>>
>>> ok, what it does is, intersperse or mingle entries. so suppose i want
>>> to stage this one tiny little change, namely moving one entry [the one
>>> with the large plain list] to a different location in the same file.
>>> even if i move it really distantly.
>>>
>>> i.e. i want to put the - and the + of the move to the staging area in
>>> magit. unstaged changes should then not have this file in it at all
>>> after the staging operations.
>>>
>>> then, basically, staged changes will have this move.
>>>
>>> as a user, i want diff to make this two hunks, a big - and a big +.
>>> but diff mingles parts of another entry or entries with this list, so
>>> that it is scattered all over the diff. to get the result i want
>>> requires tons of intra-hunk stage operations. at best.
>>>
>>> so, what aspect of diff or org is triggering this kind of behavior?
>>> what is it that diff needs to understand about org, or what minimality
>>> etc. settings does it want to create a better diff?
>>>
>>> i know org has lots of similar lines [e.g. planning headers with
>>> scheduled dates that are identical]. but still, this is a nontrivial
>>> size org file, with no other changes that i made. diff's insanity
>>> still occurs even if i move the entry distantly.
>>>
>>> i am of course aware of histogram, patience, etc. and that git diff
>>> has a few experimental choices of options. also long ago i read diff
>>> manual with its discussion of end of file beg of file and minimality
>>> with --minimal and all that stuff.
>>>
>>> however, here, though, i am mostly interested in specifically what
>>> diff's, or git diff's, or magit's, /deal/ is. in /this/ case.
>>>
>>> where does it get off doing that? everything else is the same, so why
>>> is it keying on the wrong thing?
>>>
>>> does it think i made the changes as it presents them, or does it go
>>> for some other goal like minimality or speed and not really care what
>>> i did? is it because it e.g. ignores end or beg of file or so? or is
>>> it getting confused by some line?
>>>
>>> i have of course heard of merge something or others. which presumably
>>> tell diff about the structure of files or so. like, the fact that the
>>> planning line always follows the header. or perhaps i am imagining
>>> this kind of tool.
>>>
>>> now, whether i can mitigte it is interesting /after/ that. my
>>> paleolithic magit version might not be capable, but still.
>>>
>>> --
>>> 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
>
--
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com
next prev parent reply other threads:[~2022-12-17 2:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-13 5:15 [OT] org and diff Samuel Wales
2022-11-13 5:32 ` Ihor Radchenko
2022-11-13 6:06 ` Samuel Wales
2022-11-15 16:58 ` Max Nikulin
2022-11-13 5:38 ` Samuel Wales
2022-11-13 9:32 ` Marcin Borkowski
2022-11-22 3:06 ` Samuel Wales
2022-11-22 3:17 ` Samuel Wales
2022-12-17 2:06 ` Samuel Wales [this message]
2022-12-17 8:36 ` Marcin Borkowski
2022-12-17 8:41 ` Ihor Radchenko
2022-12-28 2:30 ` Samuel Wales
2022-12-28 2:32 ` Samuel Wales
2022-12-28 6:35 ` Marcin Borkowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJcAo8ti6MmUtZyY8zFOvAGSVp40Yzop2yFB30EOZEdONyFWEA@mail.gmail.com \
--to=samologist@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).