Closed sourcedelica closed 5 years ago
Hi, yes, it's expected behavior for all the git hooks, you can check githooks manual page: https://mirrors.edge.kernel.org/pub/software/scm/git/docs/githooks.html
where <old-value> is the old object name stored in the ref, <new-value> is the new object name to be stored in the ref and <ref-name> is the full name of the ref. When creating a new ref, <old-value> is 40 0.
So if you have from_ref which is equals to 40 0
it means that this is a new branch (ref) and it doesn't exist yet.
Here is how people often catch that: https://stackoverflow.com/a/20047273
If there is a new branch with a few commits before the push, how can I find the commits since the from_ref
is all zeros?
From https://github.com/reconquest/atlassian-external-hooks/issues/112 I was able to get it working in most cases like:
if [[ ${from_ref} =~ ${new_branch_re} ]]; then # all zeros
from_ref=$(git rev-list --simplify-by-decoration -1 "${to_ref}")
fi
But it seems like this is a heuristic that may not work if there are any other decorations added by the developer (tags, etc) before the push.
Hey,
Check this example, it addresses the issue: https://external-hooks.reconquest.io/docs/example.bitbucket-require-commits-to-be-associated-with-a-jira-issue/
Specifically this piece:
if [[ "$from_ref" == "$z40" ]]; then
# if it is a new branch then check all branch related commits
boundaries=($(git rev-list --simplify-by-decoration -2 "$to_ref"))
commits=($(git rev-list "${boundaries[0]}".."$to_ref"))
Thanks. Since that logic is using the first (boundaries[0]
) hash of two (-2
) would it also be accurate to simplify to this?
if [[ "$from_ref" == "$z40" ]]; then
# if it is a new branch then check all branch related commits
from_ref=$(git rev-list --simplify-by-decoration -1 "$to_ref")
commits=($(git rev-list $from_ref..$to_ref))
@sourcedelica right, I think it would be even better :+1:
Thanks for the confirmation and the solution. —simplify-by-decoration
is a clever approach to the problem.
It appears that --simplify-by-decoration
is a heuristic but not perfect. It will walk back to the first decorated commit which would be a tag, a merge commit or a branch head. In many cases it walks back further than needed because the parent branch head is probably move ahead of the fork point. So it hits the most recent merge commit.
In our pre-receive script sometimes we get a
from_ref
that is all zeros. For exampleShould this be expected? If we pass this to
git log
it complains. Should we just ignore these rows?