为什么 git 描述挑选它做的标签

Question

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 push ing to the github repository from my home and git pull ing 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.

Answer 1

answered by @TTT in his comment :<\/em>

Answer 2

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:

• " Pass or not to pass config environment down "
• " GIT_DIR in aliases "
• " Running ' git worktree add ' in ' pre-commit ' hook "
• " Unable to read after commit - deeper analysis "
• " rev-parse --show-toplevel broken during exec'ed rebase? "
• " Weird output of git status in pre-commit hook when providing a pathspec on commit "

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)