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

ugh.  i left out a probably significant fact that means i'd have to
rework the whole post which i can't do atm.

in /this particular example/ the file will actually still be there
after staging.  i forgot there are other changes in this concrete
example.  i am trying to clean up a set of magit changes that has this
kind of mingling, but not in the plain list.  as part of doing so, i
had the idea of getting this plain list out of the file entirely.
merely because i edit the plain list and don't want to make the diff
more complex by doing so.  the plain list is not part of the diff, and
i wanted to have it not re-enter the diff when i edit it.

when refiling the plain list entry created the same kind of chaos i
was trying to reduce, i thought to move it /within/ the file.  chaos.
so i moved it to near the beg.  chaos.  then at the end.  chaos.

so you can take the post as, not a specific example, but what causes
mingling in org with diff?  or something like that.

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


  parent reply	other threads:[~2022-11-13  5:39 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 [this message]
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=CAJcAo8t8fFRTq4LL43BHZ8_+kKo4jS7LMhX8dbKg+4KXyYKF4w@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).