Re: master has switched from Automake to GNU Make

[martin rudalics]

> In a capable terminal, Git would start a text editor in which you
> could compose a commit message for the merge.

But this would not have helped me in the case at hand, I suppose.  The
whitespace complaint would not have vanished.  Right?

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

Which might confuse me totally because the Emacs I'm just using for
pulling might be another Emacs than the one specified as emacsclient.
That's the reason why I have no set $GIT_EDITOR.

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

I forgot.  On GNU/Linux it indeed tells me that my terminal is not fully
functional and starts paging unless I used tee.

> (Seriously, I should configure my Git to show
> manuals in the browser.)

It's a serious pain for me.

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

I'll do that in the next days and when there are still issues I'll get
back to you (if you don't mind).

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

If and when I'm convinced that rebasing doesn't do any harm, I might
follow that path.  So far the opinions about rebasing are too
contradictory for my humble mind.

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

In one out of 100 cases fixing a conflict will then introduce another
trailing whitespace which passes by undetected.

martin