emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: emacs-orgmode@gnu.org
Subject: [OT] org and diff
Date: Sat, 12 Nov 2022 22:15:51 -0700	[thread overview]
Message-ID: <CAJcAo8vJ8DXDgJzr15ESXQ3s0ifZja3vJ7wTFDu9x-TguWOiMg@mail.gmail.com> (raw)

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


             reply	other threads:[~2022-11-13  5:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-13  5:15 Samuel Wales [this message]
2022-11-13  5:32 ` [OT] org and diff 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
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=CAJcAo8vJ8DXDgJzr15ESXQ3s0ifZja3vJ7wTFDu9x-TguWOiMg@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).