From: Ihor Radchenko <yantar92@posteo.net>
To: Kyle Meyer <kyle@kyleam.com>
Cc: Bastien Guerry <bzg@gnu.org>, emacs-orgmode@gnu.org
Subject: Re: Syncing orgcard.tex with upstream Emacs (was: bug#64578: orgcard.tex fixes to allow PDF rendering to be used as a triptych.)
Date: Thu, 07 Dec 2023 10:42:41 +0000 [thread overview]
Message-ID: <875y1a47ku.fsf@localhost> (raw)
In-Reply-To: <87r0jytxz9.fsf@kyleam.com>
Kyle Meyer <kyle@kyleam.com> writes:
>> Maybe we should even have that file in the main repo as a part of
>> emacs-sync branch?
>
> I prefer not to. I intended that branch to track the state of Org files
> that are synced, not to store auxiliary logs.
> ...
> The emacs-sync branch provides a transparent way to keep track of the
> limited set of Emacs-specific modifications needed for the sync. We're
> not talking about an ever-growing set of changes.
> ...
> The emacs-sync branch has other Emacs-specific modifications, yes.
> Again, keeping track of those is the reason it exists.
>
> $ git diff --stat bugfix...emacs-sync
> .gitignore | 1 -
> doc/{doc-setup.org => org-setup.org} | 2 +-
> doc/{org-manual.org => org.org} | 4 ++--
> doc/orgcard.tex | 7 ++++++-
> etc/schema/schemas.xml | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> lisp/org-version.el | 24 ++++++++++++++++++++++++
> 6 files changed, 90 insertions(+), 5 deletions(-)
I see now. I guess I did not really have a full understanding of the
purpose of emacs-sync. So, it might be helpful to add a similar
explanation to worg/org-maintenance.org.
>> I can see the point. Although, I feel like accumulating such divergence
>> may backfire after some time.
>
> How do you see this particular spot backfiring? If Emacs changes the
> Emacs-specific text (as they did once in 2016), I port that to the
> emacs-sync branch. Or if Org changes neighboring text, I resolve the
> conflict on merge into emacs-sync (very likely just taking both sides).
> The resolution is recorded for anyone to look back on.
I was mainly concerned about complex conflicts that might
(theoretically) occur. But it indeed does not matter if the conflicts
are limited and manageable.
>> May we possibly resolve the conflict properly using something like the
>> attached patch? Then, we can use the same orgcard source but have
>> orgcardemacsnotice.tex empty in Org repository.
>
> I don't see what problem it solves. It's moving the divergence to a
> different file (that would still be tracked in emacs-sync), and it adds
> one more Org-specific wrinkle to the Emacs tree. (Also, the orgcard
> source would still be different given the upstream hunk in the diff I
> posted in my last message.)
My idea was not to sync that another extra file at all and leave it in
Emacs repo only. But the same will not work for xml and other diverging
files. I now don't see any reason to change the existing state of affairs.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
next prev parent reply other threads:[~2023-12-07 10:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAGQFwfgr-=jqC_SKLnsHxXgABhoZRTGL_ZYwuu0EgJ7YAG0wPw@mail.gmail.com>
[not found] ` <874jm8ythh.fsf@localhost>
[not found] ` <875y4bbz13.fsf@localhost>
[not found] ` <87r0kr9xke.fsf@localhost>
[not found] ` <871qcl33o2.fsf@gnu.org>
[not found] ` <CAGQFwfhFV97eAwWYN_P6EoVEHeS+sH2oOM0_0Qwac8zzspSnjg@mail.gmail.com>
[not found] ` <87ttoym8qu.fsf@localhost>
[not found] ` <CAGQFwfii4m8_i9Y-4GdUNMggzmYuc2uMu9aT7Zmg8x5oUi6-uQ@mail.gmail.com>
[not found] ` <CAGQFwfifY_rNYLBwNz0prQVE2YHiekciAVp6JHTtHi0ZwoGKEw@mail.gmail.com>
[not found] ` <87wmttti1k.fsf@kyleam.com>
2023-12-05 12:37 ` Syncing orgcard.tex with upstream Emacs (was: bug#64578: orgcard.tex fixes to allow PDF rendering to be used as a triptych.) Ihor Radchenko
2023-12-06 1:44 ` Kyle Meyer
2023-12-06 14:13 ` Ihor Radchenko
2023-12-07 4:53 ` Kyle Meyer
2023-12-07 10:42 ` Ihor Radchenko [this message]
2023-12-08 3:14 ` Kyle Meyer
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=875y1a47ku.fsf@localhost \
--to=yantar92@posteo.net \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=kyle@kyleam.com \
/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).