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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 10 Nov 2021 11:19:51 -0800
> Cc: rpluim@gmail.com, emacs-devel@gnu.org
> 
> >> https://lists.gnu.org/r/emacs-devel/2017-12/msg00340.html
> >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29366
> >
> > I guess we read different discussions, then.
> 
> I read the above.  Which discussions are you reading?
> 
> Let's count heads: Robert Pluim, Michael Albinus, Stefan Monnier, Stefan
> Kangas, Glenn Morris, Juri Linkov have AFAICT all come out in support of
> this change.  Some more forcefully than others.
> 
> I don't see anyone against the change.

Look closer, please.

> > How can a simple bug in gitmerge be a proof of anything (except that
> > bugs happen)?
> 
> The existence of the special code for this in gitmerge is already proof
> that this is suboptimal.  If it is buggy, that makes it worse of course.

Nonsense.  It just means we haven't yet got the full solution for
that.  Any code has bugs, and they tend to pop up when people other
than the person who wrote it start using it more intensively.  This
always happens in development, and is not proof of anything.

> But even if there are no bugs in gitmerge.el, today or in the future, we
> still lose the ability to use "git blame" in etc/NEWS.NN for the
> previous release on master.

"git annotate" on NEWS is pretty meaningless anyway.  Stuff gets moved
there too much for that to be useful.

> And what's the upside?  None, AFAICT.

You are biased, so you only see the side that suits you.  The upside
is that we are using this for a long time, and any problems we see now
are minor.  You propose a revolution where a simple bugfix should be
enough.

> Instead of working against fundamental limitations in git, it is easy or
> even trivial to completely side-step the issue.  AFAICT, the attached
> patch fixes this on GNU/Linux, but I think you would need to do more on
> operating systems without symlink support.  (There is obviously also
> more stuff to do in gitmerge.el and the install step.  I didn't bother
> for this quick proof-of-concept though.)

Thanks, but I'm not interested in doing this.  Let's move on to more
important stuff.