Understanding the change_type field in the STA_REPO_PUSH_REF table
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Purpose
When you review the STA_REPO_PUSH_REF
table the change_type
field has three possible values. 1 is for new, 2 is for deleted, and 3 is for changed. The purpose of this KB is to outline examples of how to see each of these three possible states.
Solution
To see the different change_type
values in the database follow the steps provided below.
change_type=1
- Using the DB tool of your choice you can view all of the data in the
STA_REPO_PUSH_REF
table. This will provide the baseline for this table. - In Bitbucket Server create a brand new repository called BranchTest - refresh your database view and note that this did not change the
STA_REPO_PUSH_REF
table - On your local system create a new local folder called BranchTest
git init
echo "this is a test" > test.sh
git add --all
git commit -m "Initial Commit"
git remote add origin ... (where ... is the correct path to your repository)
git push -u origin master
4. in your cmd prompt or terminal window you can see the SHA1 that was generated from this first commit
git log
commit 5cc4be0f99d9f24e59c61ffdeca1696e9deede2f
5. In the database, refresh the table view and note that there has been a row added
activity_id | ref_id | change_type | from_hash | to_hash |
---|---|---|---|---|
1298 | refs/heads/master | 1 | 0000000000000000000000000000000000000000 | 5cc4be0f99d9f24e59c61ffdeca1696e9deede2f |
As you can see the to_hash matches and the change_type is "1".
change_type=3
- Edit the
test.sh
file in the repo and save the change. Add, Commit, and Cush the change to the Bitbucket repository and the result is
git log
commit dc32054fe7fd858b87c6141eeb44e1126386893f
2. In the database, refresh the table view and note that there has been a row added
activity_id | ref_id | change_type | from_hash | to_hash |
---|---|---|---|---|
1299 | refs/heads/master | 3 | 5cc4be0f99d9f24e59c61ffdeca1696e9deede2f | dc32054fe7fd858b87c6141eeb44e1126386893f |
As you can see the change_type
is "3", the from_hash
has the initial commit hash, and the to_hash
has the new commit hash
change_type=3 even when you perform a commit delete
- Next delete the commit you just made
git reset --hard 5cc4be0f99d9f24e59c61ffdeca1696e9deede2f (takes us back to the initial commit)
git push origin HEAD --force (forces the reset on the server, this step can not be performed if the block force push hook is enabled on the repository)
2. git log at this point should show you only one, the initial commit
git log
commit 5cc4be0f99d9f24e59c61ffdeca1696e9deede2f
3. In the database, refresh the table view and note that there has been a row added
activity_id | ref_id | change_type | from_hash | to_hash |
---|---|---|---|---|
1300 | refs/heads/master | 3 | dc32054fe7fd858b87c6141eeb44e1126386893f | 5cc4be0f99d9f24e59c61ffdeca1696e9deede2f |
As you can see the change type is "3" and the from_hash
and to_hash
have swapped places
change_type=2
To get the change_type
2 you will need to do the following:
- In your local repository perform the following steps:
git checkout -b NewBranchToDelete
vi test.sh (then changed some text, save and exit)
git add test.sh
git commit -m "NewBranchToDelete Text"
git push origin NewBranchToDelete
2. git log at this point will show
git log
commit 6246e9350872d2b7dd7c90d94aa0960c1d49d2bb
3. In the database, refresh the table view and note that there has been a row added
activity_id | ref_id | change_type | from_hash | to_hash |
---|---|---|---|---|
1301 | refs/heads/NewBranchToDelete | 1 | 0000000000000000000000000000000000000000 | 6246e9350872d2b7dd7c90d94aa0960c1d49d2bb |
As you can see the change_type is "1", the ref_id
is the new branch, and the new to_hash
matches
4. Back at your terminal window run
git push origin :NewBanchToDelete (note the colon before the branch name)
5. In the database, refresh the table view and note that there has been a row added
activity_id | ref_id | change_type | from_hash | to_hash |
---|---|---|---|---|
13012 | refs/heads/NewBranchToDelete | 2 | 6246e9350872d2b7dd7c90d94aa0960c1d49d2bb | 0000000000000000000000000000000000000000 |
As you can see the change_type
is "2", and the from_hash
and the to_hash
switched positions again.
Please note that this did not require the branch to be deleted on the local side and did not require a force push to accomplish. To protect branches from being accidentally deleted using this method, use branch permissions and select the "Prevent Branch Delete" checkbox.
The key point to understand is that the STA_REPO_PUSH_REF
table is only modified on pushes. This table is not modified based on pull request merges and the occurrence of change_type=2 should be very rare. change_type=3 will be the most common, and change_type=1 will only occur whenever you push a new branch to the server.