Re: master has switched from Automake to GNU Make

[martin rudalics <rudalics@gmx.at>]

 > 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