Nginx Question posted in
The official documentation can be found here.

Why is git describe picking out the tag that it does – Nginx

I am developing an internal web application for a company I am doing some work for. It is hosted on a private github repository, but most of my development is done on my linux desktop at home, and the web server for this is hosted in the companies office on a small raspberry pi. It is essentially nginx front end proxying the /api url to a nodejs application supported by pm2.

I deploy by git pushing to the github repository from my home and git pulling the production branch in the server. A git hook post-commit script runs a npm install in a build directory before temporarily stopping the production api server, copying over the node_modules directory and running a script which in essence does git describe --abbrev=0 --tags to get and store the version number in a .env file for the production server to announce its version to clients.

If I run git describe at home it gives version v4.2.2, but in the clinic I get v4.1.17 and I cannot see why

In the image below the left hand part is the output of gitk --all on my home repository and with only terminal access in the clinic, you can see from the right hand part pretty much the same graph using git log – with commits missing that are not relevant to either the master or production branch. v4.2.2 is only two commits away, whereas v4.1.17 is at least 10 away.

Why is git describe behaving the way it is?

EDIT: I sort of know the answer – on the server there is a post-commit hook that ended up making a commit on the branch, even though it wasn’t supposed to – it was only supposed to be doing it on the development machine.

Composite gitk graph from my git repo

Tags:

2

Answers


  1. 0

    answered by @TTT in his comment :

    maybe the cause of the problem is that you intended the server local production branch to be the same as your home branch, but it isn’t. So every time it does a pull it’s making a new merge commit. Maybe the server should push out its version (if you want to keep that), or, maybe the server should get the latest with a git fetch && git reset --hard @{u} instead of with git pull. (If the server shouldn’t be making it’s own commits.)

    Login or Signup to reply.
  2. 0

    Git 2.40 (Q1 2023), clarifies what you must do for environment variables set when hooks are invoked.
    That would help git describe to behave as expected in a hook.

    See commit 772f8ff (09 Jan 2023) by Eric Sunshine (sunshineco).
    (Merged by Junio C Hamano — gitster — in commit fc2735f, 21 Jan 2023)

    githooks: discuss Git operations in foreign repositories

    Signed-off-by: Eric Sunshine
    Acked-by: Jeff King

    Hook authors are periodically caught off-guard by difficult-to-diagnose errors when their hook invokes Git commands in a repository other than the local one.
    In particular, Git environment variables, such as GIT_DIR and GIT_WORK_TREE, which reference the local repository cause the Git commands to operate on the local repository rather than on the repository which the author intended.
    This is true whether the environment variables have been set manually by the user or automatically by Git itself.
    The same problem crops up when a hook invokes Git commands in a different worktree of the same repository, as well.

    Recommended best-practice$ for avoiding this problem is for the hook to ensure that Git variables are unset before invoking Git commands in foreign repositories or other worktrees:

    unset $(git rev-parse --local-env-vars)

    However, this advice is not documented anywhere.
    Rectify this shortcoming by mentioning it in githooks.txt documentation.

    See also:

    githooks now includes in its man page:

    Environment variables, such as GIT_DIR, GIT_WORK_TREE, etc., are exported
    so that Git commands run by the hook can correctly locate the repository.

    If
    your hook needs to invoke Git commands in a foreign repository or in a
    different working tree of the same repository, then it should clear these
    environment variables so they do not interfere with Git operations at the
    foreign location.

    For example:

    local_desc=$(git describe)
foreign_desc=$(unset $(git rev-parse --local-env-vars); git -C ../foreign-repo describe)
    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search