Re: master e714b31 3/6: Merge from origin/emacs-28

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I tried to point out the downsides: the change is not really trivial,
> and therefore will have fallout, as always happens with such changes.
> And we will have to deal with that fallout.  Of course, since we are
> always overly optimistic and hope there will be no unintended
> consequences, we always tend to underestimate the downsides.

I understand your general concern, as with any code change, but I don't
agree with the conclusion that we must not make this particular change.

I expect that there will be fallout only in code that assumes that an
etc/NEWS file exists.  (Creating the symlink on GNU/Linux is mostly just
convenience and not a proper solution, IMO.)

I think I covered most such cases in my patch, but of course I might
have missed a few.  Having reviewed many (most? all?) such cases in our
tree though, I very seriously doubt that any of it will be hard to
change.  It is a trivial case of: point it to NEWS.NN if NEWS doesn't
exist.  You can see some examples in my latest patch.  Any such changes
should be small and localized.

Once we cut the emacs-29 branch, gitmerge.el may or may not need more
changes.  I think there is plenty of time to test it though, and I
intend to do so if and when this lands on master.  From my cursory
reading, this will take at most a small amount of effort, as it just
involves skipping some special handling that is no longer needed.

> For non-problems such as this one, changes like this are just waste of
> time and energy.  VCS is a tool, a means to an end; let's not make
> changes in our code and create opportunity for subtle bugs just
> because people rarely make VCS-related mistakes.

This is just one thread of many that we have had about the issues this
has caused over the years.  We would arrive at the exact same conclusion
whether or not this latest incident had happened or not.  In fact, we
discussed it just the other week as well, in the thread where Glenn said
he won't be doing the merges.  Sweeping it under the rug by calling it a
"non-problem" is no solution at all.

The real reasons for wanting to fix this real problem are:

- It destroys our git history for the NEWS.NN file every time we cut a
  release branch.

- It makes merging hard and error-prone.

- It really is an abuse of git when we could instead use it to our
  advantage.  (There is no need to maintain custom code for a "merge"
  that still leaves history broken when we could just let git do it.)

I propose that instead of fixing bugs in a fundamentally broken and
wrong solution, we just do the right thing.  We will have fewer bugs to
fix in the long run, and there are important advantages.