ນີ້ແມ່ນຄໍາສັ່ງ git-receive-pack ທີ່ສາມາດດໍາເນີນການໄດ້ໃນ OnWorks ຜູ້ໃຫ້ບໍລິການໂຮດຕິ້ງຟຣີໂດຍໃຊ້ຫນຶ່ງໃນຫຼາຍໆບ່ອນເຮັດວຽກອອນໄລນ໌ຂອງພວກເຮົາເຊັ່ນ Ubuntu Online, Fedora Online, Windows online emulator ຫຼື MAC OS online emulator
ໂຄງການ:
NAME
git-receive-pack - ຮັບສິ່ງທີ່ຖືກ pushed ເຂົ້າໄປໃນ repository
ສະຫຼຸບສັງລວມ
git-receive-pack
ລາຍລະອຽດ
ຮຽກຮ້ອງໂດຍ ໄປ ສົ່ງຊຸດ ແລະປັບປຸງ repository ດ້ວຍຂໍ້ມູນທີ່ປ້ອນຈາກ
ປາຍຫ່າງໄກສອກຫຼີກ.
ຄໍາສັ່ງນີ້ມັກຈະບໍ່ຖືກເອີ້ນໂດຍກົງໂດຍຜູ້ໃຊ້ສຸດທ້າຍ. UI ສໍາລັບໂປໂຕຄອນແມ່ນ
ກ່ຽວກັບ ໄປ ສົ່ງຊຸດ ຂ້າງ, ແລະຄູ່ໂຄງການແມ່ນຫມາຍຄວາມວ່າຈະຖືກນໍາໃຊ້ເພື່ອຊຸກຍູ້ການປັບປຸງ
repository ຫ່າງໄກສອກຫຼີກ. ສໍາລັບການດໍາເນີນງານດຶງ, ເບິ່ງ git-fetch-pack(1).
ຄໍາສັ່ງອະນຸຍາດໃຫ້ສ້າງແລະສົ່ງຕໍ່ໄວຂອງ sha1 refs (heads / tags) ໃນ
ຫ່າງໄກສອກຫຼີກ (ເວົ້າຢ່າງເຂັ້ມງວດ, ມັນແມ່ນການສິ້ນສຸດທ້ອງຖິ່ນ git-receive-pack ແລ່ນ, ແຕ່ກັບຜູ້ໃຊ້
ຜູ້ທີ່ນັ່ງຢູ່ທ້າຍຊຸດສົ່ງ, ມັນກໍາລັງອັບເດດຣີໂໝດ. ສັບສົນ?)
ມີຕົວຢ່າງອື່ນໆໃນໂລກທີ່ແທ້ຈິງຂອງການນໍາໃຊ້ hooks ການປັບປຸງແລະຫລັງການປັບປຸງທີ່ພົບເຫັນຢູ່ໃນ
ເອກະສານ/ວິທີການ.
git-receive-pack ໃຫ້ກຽດແກ່ຕົວເລືອກ config receive.denyNonFastForwards, ເຊິ່ງບອກມັນຖ້າ
ການປັບປຸງການອ້າງອີງຄວນຖືກປະຕິເສດຖ້າພວກມັນບໍ່ໄວ.
OPTIONS
repository ທີ່ຈະ sync ເຂົ້າໄປໃນ.
ຮັບກ່ອນ ຂໍ
ກ່ອນທີ່ຈະມີການອັບເດດການອ້າງອີງໃດໆ, ຖ້າໄຟລ໌ $GIT_DIR/hooks/pre-receive ມີຢູ່ ແລະສາມາດປະຕິບັດໄດ້, ມັນ
ຈະຖືກເອີ້ນຄັ້ງດຽວໂດຍບໍ່ມີພາລາມິເຕີ. ການປ້ອນຂໍ້ມູນມາດຕະຖານຂອງ hook ຈະເປັນເສັ້ນຫນຶ່ງ
ຕໍ່ການອ້າງອີງທີ່ຈະປັບປຸງ:
sha1-old SP sha1-ໃໝ່ SP refname LF
ມູນຄ່າການປ່ຽນຊື່ແມ່ນກ່ຽວຂ້ອງກັບ $GIT_DIR; e.g. ສໍາລັບຫົວຫນ້າຕົ້ນສະບັບນີ້ແມ່ນ
"refs/heads/master". ສອງຄ່າ sha1 ກ່ອນແຕ່ລະ refname ແມ່ນຊື່ວັດຖຸສໍາລັບ
ປ່ຽນຊື່ກ່ອນ ແລະຫຼັງການປັບປຸງ. Refs ທີ່ຈະສ້າງຈະມີ sha1-old ເທົ່າກັບ 0{40},
ໃນຂະນະທີ່ refs ທີ່ຈະລຶບຈະມີ sha1-new ເທົ່າກັບ 0{40}, ຖ້າບໍ່ດັ່ງນັ້ນ sha1-old ແລະ
sha1-new ຄວນເປັນວັດຖຸທີ່ຖືກຕ້ອງຢູ່ໃນບ່ອນເກັບມ້ຽນ.
ເມື່ອຍອມຮັບການຊຸກຍູ້ການລົງນາມ (ເບິ່ງ git-push(1)), ໃບຢັ້ງຢືນການຊຸກຍູ້ທີ່ຖືກເຊັນຖືກເກັບໄວ້ໃນ a
blob ແລະຕົວແປສະພາບແວດລ້ອມ GIT_PUSH_CERT ສາມາດປຶກສາສໍາລັບຊື່ວັດຖຸຂອງມັນ. ເບິ່ງ
ຄໍາອະທິບາຍຂອງ hook ຫລັງຮັບສໍາລັບຕົວຢ່າງ. ນອກຈາກນັ້ນ, ໃບຢັ້ງຢືນແມ່ນ
ກວດສອບໂດຍໃຊ້ GPG ແລະຜົນໄດ້ຮັບຈະຖືກສົ່ງອອກດ້ວຍຕົວແປສະພາບແວດລ້ອມຕໍ່ໄປນີ້:
GIT_PUSH_CERT_SIGNER
ຊື່ແລະທີ່ຢູ່ອີເມລຂອງເຈົ້າຂອງກະແຈທີ່ໄດ້ເຊັນການຊຸກຍູ້
ໃບຢັ້ງຢືນ.
GIT_PUSH_CERT_KEY
ID ລະຫັດ GPG ຂອງກະແຈທີ່ເຊັນໃບຢັ້ງຢືນການຊຸກຍູ້.
GIT_PUSH_CERT_STATUS
ສະຖານະຂອງການກວດສອບ GPG ຂອງໃບຢັ້ງຢືນການຊຸກຍູ້, ການນໍາໃຊ້ mnemonic ດຽວກັນກັບ
ໃຊ້ໃນ %G ບໍ? ຮູບແບບຂອງ git log ຄອບຄົວຂອງຄໍາສັ່ງ (ເບິ່ງ git-log(1)).
GIT_PUSH_CERT_NONCE
ຂໍ້ຄວາມ nonce ຂະບວນການຮ້ອງຂໍໃຫ້ຜູ້ລົງນາມລວມຢູ່ໃນໃບຢັ້ງຢືນການຊຸກຍູ້. ຖ້າ
ອັນນີ້ບໍ່ກົງກັບຄ່າທີ່ບັນທຶກໄວ້ໃນຫົວຂໍ້ "nonce" ໃນໃບຢັ້ງຢືນການຊຸກຍູ້,
ມັນອາດຈະຊີ້ບອກວ່າໃບຢັ້ງຢືນການເປັນຫນຶ່ງທີ່ຖືກຕ້ອງທີ່ໄດ້ຖືກຫຼິ້ນຄືນຈາກ a
ກອງປະຊຸມ "git push" ແຍກຕ່າງຫາກ.
GIT_PUSH_CERT_NONCE_STATUS
ບໍ່ໄດ້ຮຽກຮ້ອງ
"git push --signed" ສົ່ງ nonce ເມື່ອພວກເຮົາບໍ່ໄດ້ຂໍໃຫ້ມັນສົ່ງຫນຶ່ງ.
ຫາຍ
"git push --signed" ບໍ່ໄດ້ສົ່ງ header nonce ໃດ.
BAD
"git push --signed" ສົ່ງຂໍ້ຄວາມປອມ.
OK
"git push --signed" ສົ່ງ nonce ພວກເຮົາຂໍໃຫ້ມັນສົ່ງ.
SLOP
"git push --signed" ສົ່ງຂໍ້ຄວາມທີ່ບໍ່ແຕກຕ່າງຈາກສິ່ງທີ່ພວກເຮົາຂໍໃຫ້ມັນສົ່ງໃນປັດຈຸບັນ, ແຕ່
ໃນກອງປະຊຸມທີ່ຜ່ານມາ. ເບິ່ງຕົວແປສະພາບແວດລ້ອມ GIT_PUSH_CERT_NONCE_SLOP.
GIT_PUSH_CERT_NONCE_SLOP
"git push --signed" ສົ່ງຂໍ້ຄວາມທີ່ບໍ່ແຕກຕ່າງຈາກສິ່ງທີ່ພວກເຮົາຂໍໃຫ້ມັນສົ່ງໃນປັດຈຸບັນ, ແຕ່ໃນ a
ກອງ ປະ ຊຸມ ທີ່ ແຕກ ຕ່າງ ກັນ ທີ່ ໃຊ້ ເວ ລາ ເລີ່ມ ຕົ້ນ ແມ່ນ ແຕກ ຕ່າງ ກັນ ໂດຍ ນີ້ ຫຼາຍ ວິ ນາ ທີ ຈາກ
ຊ່ວງເວລາປະຈຸບັນ. ມີຄວາມໝາຍພຽງແຕ່ເມື່ອ GIT_PUSH_CERT_NONCE_STATUS ເວົ້າວ່າ SLOP. ອ່ານຄືກັນ
ກ່ຽວກັບ receive.certNonceSlop ຕົວແປໃນ git-config(1).
hook ນີ້ຖືກເອີ້ນກ່ອນທີ່ຈະປັບປຸງຊື່ໃຫມ່ແລະກ່ອນທີ່ຈະມີການກວດສອບໄວ
ປະຕິບັດ.
ຖ້າຮູຮັບກ່ອນອອກດ້ວຍສະຖານະອອກທີ່ບໍ່ແມ່ນສູນຈະບໍ່ມີການອັບເດດ,
ແລະການອັບເດດ, ຫຼັງການຮັບ ແລະຫຼັງການອັບເດດ hooks ຈະບໍ່ຖືກເອີ້ນ. ນີ້ສາມາດເປັນ
ເປັນປະໂຫຍດທີ່ຈະປະກັນຕົວຢ່າງໄວວາຖ້າການປັບປຸງບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນ.
UPDATE ຂໍ
ກ່ອນທີ່ແຕ່ລະການອ້າງອີງຈະຖືກປັບປຸງ, ຖ້າໄຟລ໌ $GIT_DIR/hooks/update ມີຢູ່ ແລະສາມາດປະຕິບັດໄດ້, ມັນແມ່ນ
ຮຽກຮ້ອງຄັ້ງດຽວຕໍ່ການອ້າງອີງ, ມີສາມຕົວກໍານົດການ:
$GIT_DIR/hooks/ອັບເດດຊື່ປ່ຽນຊື່ sha1-ເກົ່າ sha1-ໃໝ່
ພາລາມິເຕີການປ່ຽນຊື່ແມ່ນກ່ຽວຂ້ອງກັບ $GIT_DIR; e.g. ສໍາລັບຫົວຫນ້າຕົ້ນສະບັບນີ້ແມ່ນ
"refs/heads/master". ສອງ sha1 argument ແມ່ນຊື່ວັດຖຸສໍາລັບການປ່ຽນຊື່ກ່ອນ
ແລະຫຼັງຈາກການປັບປຸງ. ໃຫ້ສັງເກດວ່າ hook ຖືກເອີ້ນວ່າກ່ອນທີ່ຈະ refname ປັບປຸງ, ດັ່ງນັ້ນ
ທັງ sha1-old ແມ່ນ 0{40} (ຫມາຍຄວາມວ່າຍັງບໍ່ມີການອ້າງອິງແບບນັ້ນເທື່ອ), ຫຼືມັນຄວນຈະກົງກັບສິ່ງທີ່ເປັນ.
ບັນທຶກໃນ refname.
Hook ຄວນອອກດ້ວຍສະຖານະທີ່ບໍ່ແມ່ນສູນ ຖ້າມັນຕ້ອງການບໍ່ອະນຸຍາດໃຫ້ອັບເດດເອກະສານອ້າງອີງທີ່ມີຊື່.
ຖ້າບໍ່ດັ່ງນັ້ນມັນຄວນຈະອອກຈາກສູນ.
ການປະຕິບັດສົບຜົນສໍາເລັດ (ສະຖານະພາບການອອກສູນ) ຂອງ hook ນີ້ບໍ່ໄດ້ຮັບປະກັນການອ້າງອີງ
ຕົວຈິງແລ້ວຈະໄດ້ຮັບການປັບປຸງ, ມັນເປັນພຽງແຕ່ prerequisite. ດັ່ງນັ້ນ, ມັນບໍ່ແມ່ນຄວາມຄິດທີ່ດີທີ່ຈະສົ່ງ
ແຈ້ງການ (ຕົວຢ່າງອີເມລ໌) ຈາກ hook ນີ້. ພິຈາລະນາໃຊ້ hook ຕອບຮັບແທນ.
ຫຼັງຮັບ ຂໍ
ຫຼັງຈາກ refs ທັງຫມົດໄດ້ຖືກປັບປຸງ (ຫຼືພະຍາຍາມທີ່ຈະປັບປຸງ), ຖ້າຫາກວ່າການປັບປຸງການອ້າງອີງໃດໆ
ສຳເລັດແລ້ວ, ແລະຖ້າໄຟລ໌ $GIT_DIR/hooks/post-receive ມີຢູ່ ແລະສາມາດດຳເນີນການໄດ້, ມັນຈະເປັນ
ຮຽກຮ້ອງຄັ້ງດຽວໂດຍບໍ່ມີພາລາມິເຕີ. ການປ້ອນຂໍ້ມູນມາດຕະຖານຂອງ hook ຈະເປັນເສັ້ນຫນຶ່ງສໍາລັບແຕ່ລະຄົນ
ປັບປຸງສົບຜົນສໍາເລັດ ref:
sha1-old SP sha1-ໃໝ່ SP refname LF
ມູນຄ່າການປ່ຽນຊື່ແມ່ນກ່ຽວຂ້ອງກັບ $GIT_DIR; e.g. ສໍາລັບຫົວຫນ້າຕົ້ນສະບັບນີ້ແມ່ນ
"refs/heads/master". ສອງຄ່າ sha1 ກ່ອນແຕ່ລະ refname ແມ່ນຊື່ວັດຖຸສໍາລັບ
ປ່ຽນຊື່ກ່ອນ ແລະຫຼັງການປັບປຸງ. Refs ທີ່ຖືກສ້າງຂຶ້ນຈະມີ sha1-old ເທົ່າກັບ
0{40}, ໃນຂະນະທີ່ refs ທີ່ຖືກລຶບໄປແລ້ວຈະມີ sha1-new ເທົ່າກັບ 0{40}, ຖ້າບໍ່ດັ່ງນັ້ນ sha1-old
ແລະ sha1-new ຄວນເປັນວັດຖຸທີ່ຖືກຕ້ອງຢູ່ໃນບ່ອນເກັບມ້ຽນ.
ຕົວແປສະພາບແວດລ້ອມ GIT_PUSH_CERT* ສາມາດຖືກກວດສອບໄດ້, ຄືກັນກັບຢູ່ໃນ hook ກ່ອນຮັບ,
ຫຼັງຈາກທີ່ໄດ້ຮັບການຊຸກຍູ້ການລົງນາມ.
ການນໍາໃຊ້ hook ນີ້, ມັນເປັນເລື່ອງງ່າຍທີ່ຈະສ້າງ mails ອະທິບາຍການປັບປຸງກັບ repository ໄດ້.
script ຕົວຢ່າງນີ້ຈະສົ່ງຫນຶ່ງຂໍ້ຄວາມເມລຕໍ່ ref ລາຍຊື່ຄໍາຫມັ້ນສັນຍາ pushed ກັບ
repository, ແລະບັນທຶກໃບຢັ້ງຢືນການຊຸກຍູ້ຂອງ pushes ທີ່ມີລາຍເຊັນທີ່ດີກັບ a
ບໍລິການຕັດໄມ້:
#!/ ຖັງ / sh
# mail out commit ຂໍ້ມູນການປັບປຸງ.
ໃນຂະນະທີ່ອ່ານ oval nval ref
do
ຖ້າ expr "$ oval" : '0*$' >/dev/null
ຫຼັງຈາກນັ້ນ
echo "ສ້າງການອ້າງອີງໃຫມ່, ມີຄໍາຫມັ້ນສັນຍາດັ່ງຕໍ່ໄປນີ້:"
git rev-list --pretty "$nval"
ອື່ນ
ສຽງສະທ້ອນ "ຄໍາຫມັ້ນສັນຍາໃຫມ່:"
git rev-list --pretty "$nval" "^$oval"
fi |
mail -s "ການປ່ຽນແປງການອ້າງອີງ $ref" commit-list@mydomain
ເຮັດ
# ເຊັນບົດບັນທຶກການຊຸກຍູ້, ຖ້າມີ
ຖ້າທົດສອບ -n "${GIT_PUSH_CERT-}" && ທົດສອບ ${GIT_PUSH_CERT_STATUS} = G
ຫຼັງຈາກນັ້ນ
(
ສຽງສະທ້ອນທີ່ຄາດໄວ້ບໍ່ແມ່ນ ${GIT_PUSH_NONCE}
git cat-file blob ${GIT_PUSH_CERT}
) | mail -s "ໃບຢັ້ງຢືນການຊຸກຍູ້ຈາກ $GIT_PUSH_CERT_SIGNER" push-log@mydomain
fi
ທາງອອກ 0
ລະຫັດອອກຈາກຄໍາຮ້ອງສະຫມັກ hook ນີ້ແມ່ນຖືກລະເລີຍ, ແນວໃດກໍຕາມຈະເປັນລະຫັດອອກທີ່ບໍ່ແມ່ນສູນ
ສ້າງຂໍ້ຄວາມຜິດພາດ.
ໃຫ້ສັງເກດວ່າມັນເປັນໄປໄດ້ສໍາລັບການປ່ຽນຊື່ທີ່ຈະບໍ່ມີ sha1-new ເມື່ອ hook ນີ້ແລ່ນ. ນີ້ສາມາດ
ເກີດຂຶ້ນໄດ້ຢ່າງງ່າຍດາຍຖ້າຜູ້ໃຊ້ອື່ນແກ້ໄຂການອ້າງອີງຫຼັງຈາກມັນຖືກປັບປຸງໂດຍ git-receive-pack,
ແຕ່ກ່ອນ hook ສາມາດປະເມີນມັນໄດ້. ມັນແນະນໍາໃຫ້ hooks ອີງໃສ່ sha1-new
ແທນທີ່ຈະເປັນມູນຄ່າປັດຈຸບັນຂອງການປ່ຽນຊື່.
POST-UPDATE ຂໍ
ຫຼັງຈາກການປຸງແຕ່ງອື່ນໆທັງຫມົດ, ຖ້າຫາກວ່າຢ່າງຫນ້ອຍຫນຶ່ງ ref ໄດ້ຖືກປັບປຸງ, ແລະຖ້າຫາກວ່າ
$GIT_DIR/hooks/post-update file ມີຢູ່ ແລະສາມາດດຳເນີນການໄດ້, ຈາກນັ້ນຫຼັງການອັບເດດຈະຖືກເອີ້ນ
ກັບບັນຊີລາຍຊື່ຂອງ refs ທີ່ໄດ້ຮັບການປັບປຸງ. ນີ້ສາມາດຖືກນໍາໃຊ້ເພື່ອປະຕິບັດ repository ໃດ
ວຽກງານອະນາໄມກວ້າງ.
ລະຫັດອອກຈາກຄໍາຮ້ອງສະຫມັກ hook ນີ້ແມ່ນຖືກລະເລີຍ; ສິ່ງດຽວທີ່ປະໄວ້ສໍາລັບ
git-receive-pack ທີ່ຈະເຮັດໃນຈຸດນັ້ນແມ່ນເພື່ອອອກຈາກຕົວຂອງມັນເອງຢ່າງໃດກໍ່ຕາມ.
hook ນີ້ສາມາດໃຊ້, ສໍາລັບການຍົກຕົວຢ່າງ, ເພື່ອດໍາເນີນການ git update-server-info ຖ້າ repository ແມ່ນ
packed ແລະໃຫ້ບໍລິການຜ່ານການຂົນສົ່ງ dumb.
#!/ ຖັງ / sh
exec git update-server-info
ໃຊ້ git-receive-pack ອອນໄລນ໌ໂດຍໃຊ້ບໍລິການ onworks.net
