Glenn Morris <address@hidden> writes:
> Kyle Meyer wrote:
>> The issue is that, if we backport to Org's master branch, the changes in
>> Emacs's master branch will be reverted when synced with the release from
>> Org's maint branch.
I believe that that reverting is OK as long as that is a new-feature commit. That revert will be "reverted" the next time Org major release (cut from org master) is merged into emacs master. I made the above diagram to clarify this.
> That's only true if an Org "sync" is yet again going to be just a dump
> of the files from Org on top of the ones in Emacs. As has been explained
> before, this is not how to do it. In relevant branch of the Org repo,
> construct the diff between the current revision and the last revision
> that was synced with Emacs. Then apply that diff to Emacs.
No, you face the same problem either way. You have commit X in Emacs's
master branch and in Org's master branch, but not Org's maint branch.
Because the goal is to update Emacs to the latest Org release from Org's
maint [*], commit X would be reverted in the sync. Sure, you could
selectively ignore the hunk that reverts back to maint's state
(i.e. keep the changes from commit X),
but then you create a situation
where Emacs's Org files are a weird mix between the released version of
Org (maint) and the developmental version (Org's master).
And thus to prevent this mix, Org related commits should not happen directly to emacs master. They must go to either org maint or org master. If they go to org maint (bug/doc fix), emacs master will see those commits merged sooner. If they go to org master (new feature), emacs master will eventually see them but only when an org major release is cut out.
Nutshell: Use org master to get bug/doc fixes + new org features at the soonest.
PS: Please point out any error with the above diagram.