emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master has switched from Automake to GNU Make


From: Yuri Khan
Subject: Re: master has switched from Automake to GNU Make
Date: Tue, 11 Apr 2017 20:17:47 +0700

On Tue, Apr 11, 2017 at 7:13 PM, Andreas Schwab <address@hidden> wrote:
> On Apr 11 2017, martin rudalics <address@hidden> wrote:
>
>> Today again git complained about my dumb terminal

Martin, you’re trying to solve three problems at once.


> What does that mean?

Normally, Git pipes its output through ‘less -FRX’, so that the user
can scroll through long logs or diffs at his or her pace. However,
that requires a terminal that supports cursor addressing, so that
less(1) could erase the previous screen and re-draw the new one.

In my Emacs, less(1) invoked from ‘shell’ says “WARNING: terminal is
not fully functional”. It then sort-of works but is ugly and a bit
pointless within Emacs which implements its own scrolling.

To tell Git not to use paging:

$ git config --global core.pager cat

or:

$ export GIT_PAGER=cat

The latter would be a good configuration for ‘shell’ buffers in Emacs.

See ‘git help config’ for more technical details.


Paging is, however, entirely independent of trailing whitespace
checking. Git by default does not treat trailing whitespace as errors,
but provides an easy way to enable that as a sample pre-commit hook.
In the Emacs repository, running ‘autogen.sh git’ installs a
pre-commit hook from build-aux/git-hooks that actually invokes the
check in its last line. The file admin/unidata/SpecialCasing.txt does
in fact fail this check. But that’s okay because it has been committed
once and you’re not likely to need to commit it again unless you’re
upgrading Emacs to a newer version of the Unicode standard.


Why you are getting in the situation where you need to commit
SpecialCasing.txt when pulling is a different issue.

What is your workflow, starting with a checkout and up to pulling? Do
you by any chance try to pull while your working tree has uncommitted
changes? (That has a high confusion potential. Commit first, pull
later.)

(Also, I always suggest to ‘git fetch’ first, see if your local branch
and the upstream have diverged, and then decide consciously whether
you want a merge, a rebase, or something else entirely. ‘git pull’
makes the decision for you.)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]