Emacs 26: Emacs not response when press Enter in shell mode

.gitattributes

@@ -1,6 +1,6 @@
 # Attributes of Emacs files in the Git repository.
 
-# Copyright 2015-2018 Free Software Foundation, Inc.
+# Copyright 2015-2019 Free Software Foundation, Inc.
 
 # This file is part of GNU Emacs.
 

.gitignore

@@ -1,6 +1,6 @@
 # Files that Git should ignore in the Emacs source directory.
 
-# Copyright 2009-2018 Free Software Foundation, Inc.
+# Copyright 2009-2019 Free Software Foundation, Inc.
 
 # This file is part of GNU Emacs.
 

.gitlab-ci.yml

@@ -1,4 +1,4 @@
-# Copyright (C) 2017-2018 Free Software Foundation, Inc.
+# Copyright (C) 2017-2019 Free Software Foundation, Inc.
 #
 #  This file is part of GNU Emacs.
 #
@@ -35,6 +35,8 @@ stages:
 
 test:
   stage: test
+  variables:
+    EMACS_EMBA_CI: 1
   script:
     - ./autogen.sh autoconf
     - ./configure --without-makeinfo

CONTRIBUTE

@@ -54,6 +54,12 @@ packages the patch's commit message and changes.  To send just one
 such patch without additional remarks, you can use a command like
 'git send-email --to=bug-gnu-emacs@gnu.org 0001-DESCRIPTION.patch'.
 
+Once the cumulative amount of your submissions exceeds about 15 lines
+of non-trivial changes, we will need you to assign to the FSF the
+copyright for your contributions.  Ask on emacs-devel@gnu.org, and we
+will send you the necessary form together with the instructions to
+fill and email it, in order to start this legal paperwork.
+
 ** Issue tracker (a.k.a. "bug tracker")
 
 The Emacs issue tracker at https://debbugs.gnu.org lets you view bug
@@ -287,15 +293,23 @@ the current release branch.  Periodically, the current release branch
 is merged into the master, using the gitmerge function described in
 admin/notes/git-workflow.
 
-If you are fixing a bug that exists in the current release, be sure to
-commit it to the release branch; it will be merged to the master
-branch later by the gitmerge function.
-
-Documentation fixes (in doc strings, in manuals, and in comments)
-should always go to the release branch, if the documentation to be
-fixed exists and is relevant to the release-branch codebase.  Doc
-fixes are always considered "safe" -- even when a release branch is in
-feature freeze, it can still receive doc fixes.
+If you are fixing a bug that exists in the current release, you should
+generally commit it to the release branch; it will be merged to the
+master branch later by the gitmerge function.  However, when the
+release branch is for Emacs version NN.2 and later, or when it is for
+Emacs version NN.1 that is in the very last stages of its pretest,
+that branch is considered to be in a feature freeze: only bug fixes
+that are "safe" or are fixing major problems should go to the release
+branch, the rest should be committed to the master branch.  This is so
+to avoid destabilizing the next Emacs release.  If you are unsure
+whether your bug fix is "safe" enough for the release branch, ask on
+the emacs-devel mailing list.
+
+Documentation fixes (in doc strings, in manuals, in NEWS, and in
+comments) should always go to the release branch, if the documentation
+to be fixed exists and is relevant to the release-branch codebase.
+Doc fixes are always considered "safe" -- even when a release branch
+is in feature freeze, it can still receive doc fixes.
 
 When you know that the change will be difficult to merge to the
 master (e.g., because the code on master has changed a lot), you can

ChangeLog.1

@@ -14700,7 +14700,7 @@
 ;; coding: utf-8
 ;; End:
 
-  Copyright (C) 1993-1999, 2001-2018 Free Software Foundation, Inc.
+  Copyright (C) 1993-1999, 2001-2019 Free Software Foundation, Inc.
 
   This file is part of GNU Emacs.
 

ChangeLog.2

@@ -35787,7 +35787,7 @@ See ChangeLog.1 for earlier changes.
 ;; coding: utf-8
 ;; End:
 
-  Copyright (C) 2015-2018 Free Software Foundation, Inc.
+  Copyright (C) 2015-2019 Free Software Foundation, Inc.
 
   This file is part of GNU Emacs.