[lmi] Unexpected git (mis)behavior

[Greg Chicares]

Usually, if some git operation fails, there's a helpful error message
that describes what's wrong and clearly suggests what to do about it.
Here's a situation that occurred today, where that was not the case.

On our corporate redhat server, not in any chroot (with git-1.8.3.1,
provided by EPEL), I had cloned the lmi repository some time ago,
into /opt/lmi/src/lmi as usual. Today, Kim tried to update it, and
git-pull failed:

/opt/lmi/src/lmi[0]$git pull
remote: Enumerating objects: 117, done.
remote: Counting objects: 100% (117/117), done.
remote: Compressing objects: 100% (32/32), done.
remote: Total 86 (delta 57), reused 77 (delta 48), pack-reused 0
Unpacking objects: 100% (86/86), done.
>From https://github.com/let-me-illustrate/lmi
   5724e39..b03a344  master     -> origin/master
Updating 5724e39..b03a344
error: unable to unlink old '.github/workflows/ci.yml' (Permission denied)

The file that couldn't be unlinked had permissions "-rw-r--r--",
which Kim used 'sudo' to reset to "-rw-rw-r--", also repairing
undesired permissions on other files, thus:
  sudo chgrp -R lmi /opt/lmi
  sudo find /opt/lmi -type d -exec chmod g+s {} +
  sudo chmod -R g=u /opt/lmi
When she then repeated the git-pull command, it failed:

/opt/lmi/src/lmi[0]$git pull
Updating 5724e39..b03a344
error: Your local changes to the following files would be overwritten by merge:
        GNUmakefile
        Makefile.am
        configurable_settings.cpp
        generate_product_files.cpp
        gui_test.sh
        gwc/develop1.txt
        gwc/develop2.txt
        install_msw.sh
        install_xml_libraries.sh
        main_wx_test.cpp
        my_prod.cpp
        nychthemeral_test.sh
        objects.make
        path_utility.cpp
        path_utility.hpp
        path_utility_test.cpp
        policy_document.cpp
        policy_view.xrc
        preferences_model.cpp
        product_data.cpp
        product_data.hpp
        product_file_test.cpp
        skeleton.cpp
        test_coding_rules.cpp
        workhorse.make
        xml_serialize.hpp
Please, commit your changes or stash them before you can merge.
error: The following untracked working tree files would be overwritten by merge:
        ellipsis.png
        lingo.cpp
        lingo.hpp
        my_lingo.cpp
        sample.hpp
        sequence_editor.png
Please move or remove them before you can merge.
Aborting

Those files cannot have been there previously: for instance, 'ellipsis.png'
was added to the repository only yesterday. Apparently the first git-pull
attempt brought those files up to date in the local tree, but didn't
recognize that it had introduced or modified them: git seems to treat them
as local modifications that we had made manually, although we surely didn't.

We've recovered now, by removing all the offending files:
  rm `git diff --name-only`
  rm `git ls-files --others`
after which 'git pull' succeeded.

What surprised me is that git modified the local tree, then aborted but
left the local modifications in place, and git-status didn't tell us about
the problem that running git-pull had created, or give a clearer suggestion
about how we should recover. "Please, commit your changes" is misleading
because those weren't "our" changes--they were git's changes. It looks like
there was a merge in progress that was terminated abruptly (the "Aborting"
message above), whereas in my prior experience git-status would have told
us that a merge had failed, and suggested that we either resolve conflicts
and git-add them and continue, or else run an '--abort' command that would
have cleaned up the local modifications.

I don't think this can have been caused by my customized hooks/post-checkout
script, because it does nothing if $(whoami) isn't "greg", and there's no
"greg" account on the corporate server. That file should already have been
at the latest version, because today's first git-pull said:
  Updating 5724e39..b03a344
and 5724e39 was 2020-10-26, whereas hooks/post-checkout was last modified
on 2020-10-20, six days before.

I'm guessing that this is a git QoI issue: git would normally either clean
up better after a failed pull, or give more helpful suggestions, but maybe
it stumbles because of the (hidden) .github subdirectory. I would have
thought that that subdirectory would have had group=user permissions
because
  $git config --get-all core.sharedrepository
  1
but clearly it didn't.

Should I make some appropriate hook (post-checkout, perhaps) do this:
  sudo chgrp -R lmi /opt/lmi
  sudo find /opt/lmi -type d -exec chmod g+s {} +
  sudo chmod -R g=u /opt/lmi
in order to enforce those rules after every pull, so that this problem
can't occur again?