Re: master has switched from Automake to GNU Make

[martin rudalics]

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

Aha.. thanks in advance for your attention.

>> 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

OK.  That looks like a good idea.  I suppose this could also help me
with git's help which currently always redirects me to my browsers.  I
have never tried to delve into git's options because I usually get lost
in its documentation.

> 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.

OK.

> 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.)

No.  It just happens on a branch where occasionally conflicts may occur.
In the particular case there were no uncommitted and no stashed changes
(to my knowledge).

> (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.)

I always want a merge.  So what do you recommend?  In particular what do
you recommend when there are conflicts?  IIUC in that case git does not
merge anything but waits till I have resolved the conflicts and tells me
to commit them when I'm done.  If, at that moment, I do commit I'm in
the same situation with SpecialCasing.txt as before.  Or is there any
difference?

martin