Re: [External] : emacs-28 windows binaries available from alpha

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
> Date: Thu, 10 Feb 2022 18:34:22 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> PS I tried to merge emacs-28 into master using gitmerge.el as suggested
> >> in git-workflow as I suspected a conflict there that I wanted to solve
> >> myself, but it says "nothing to merge".  Not sure if I'm doing something
> >> wrong.
> >
> > I merged that change, but for the future: what exactly did you do, and
> > in particular did you remember to switch to the master branch and do a
> > "git pull" in master, before invoking "gitmerge"?
> 
> I did what's described in git-workflow, so yes I had master checked out
> and I pulled before trying.  The only difference is that haven't started
> a fresh emacs but loaded gitmerge.el in my current session.  Next time
> I'll try with a fresh session and maybe with -Q.

What was the default-directory when you invoked "M-x gitmerge"?  It
should be the Emacs repository, and Emacs should know that the current
branch in that directory is "master".

Starting a new Emacs session is indeed better.  (I also have separate
directories for master and the release branch, so for me changing the
default-directory ("M-x cd") also means I'm sure gitmerge will use the
correct branch.)

> Anyway I was thinking if it wouldn't be correct to emit also a warning
> if libgccjit is not available.  This condition could prevent some
> package to work as expected (ex evil-mode IIRC) so might be worth to
> inform the user that and emacs compiled with native-comp is being run
> without libgccjit being available.

I'm not sure I see the usefulness of such a warning.  If Emacs works
correctly regardless, the warning could annoy.  So I tend to think we
should introduce the warning only if enough users complain that Emacs
silently does something they'd prefer to know about.

Thanks.