Re: master has switched from Automake to GNU Make

[Yuri Khan <yuri.v.khan@gmail.com>]

On Tue, Apr 11, 2017 at 8:23 PM, martin rudalics <rudalics@gmx.at> wrote:

> IIRC it tells me that
>
> error: Terminal is dumb, but EDITOR unset
> Not committing merge; use 'git commit' to complete the merge.

Aha! Error messages are important.

In a capable terminal, Git would start a text editor in which you
could compose a commit message for the merge. Under an Emacs shell
buffer, it can’t, so it defers to you to provide a commit message via
-m or -F.

It tries first the $GIT_EDITOR variable;
if that is not set, then the core.editor configuration setting;
if that is not set either, then $VISUAL but only if the terminal is not dumb;
if it has not yet found anything, then $EDITOR;
and if nothing yet, then it ultimately falls back to "vi", but again
only if the terminal is not dumb.

(And it detects terminal dumbness by the fact that the $TERM variable
is not set or is set to the string "dumb".)

As an Emacs user you’d probably want this:

$ git config --global core.editor emacsclient

or possibly 'emacsclient -t'.


On Tue, Apr 11, 2017 at 8:53 PM, martin rudalics <rudalics@gmx.at> wrote:

> I suppose this could also help me
> with git's help which currently always redirects me to my browsers.

Browsers? Oh, you’re on Windows. On other systems, git-help uses
man(1) by default. (Seriously, I should configure my Git to show
manuals in the browser.)

> I have never tried to delve into git's options because I usually get lost
> in its documentation.

Git’s manual is like that, yes, unfortunately. The change of viewing
tool is unlikely to help much with that.

But seriously, find some time to read the ‘git help config’ page once.
It’s full of useful options and less useful defaults (core.pager,
core.editor, and merge.conflictstyle to name just a few).


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

Well, I would recommend rebasing, which would solve the
SpecialCasing.txt problem because your rebased branch would start
after the problematic file has been committed.

But if you insist on merging, it’s doable, too. Then I guess you
get a merge conflict,
resolve it,
stage the resolved files,
attempt to commit,
get a whitespace policy violation,
say an expletive of your choice,
see that the violation was not your doing,
optionally confirm that by looking at the history of the problematic
file in the branch you’re merging,
then say “Oh well” and commit bypassing the check.
(You can bypass the check by temporarily commenting out the last line
in .git/hooks/pre-commit or uninstalling that hook altogether.)