เริ่มคอมไพล์ข้อความคอมไพล์ด้วย hashmark (#)

283

Git ปฏิบัติต่อบรรทัดที่เริ่มต้นด้วย#บรรทัดความคิดเห็นเมื่อส่งข้อมูล มันน่ารำคาญมากเมื่อทำงานกับระบบติดตามตั๋วและพยายามเขียนหมายเลขตั๋วที่จุดเริ่มต้นของบรรทัดเช่น

#123 salt hashed passwords

git จะลบบรรทัดออกจากข้อความคอมมิท มีวิธีใดบ้างที่จะหนีความยุ่งเหยิงนี้ได้? ฉันพยายาม\และ!แต่ไม่มีอะไรทำงาน ช่องว่างก่อนหน้า#นั้นได้รับการเก็บรักษาไว้ดังนั้นจึงไม่ใช่วิธีการแก้ปัญหาที่ใช้งานได้

— knittl
แหล่งที่มา

8

@AlexBudovski เพราะมีค่าในระยะสั้น ๆ

— Xavi

8

ตั้งแต่ git 1.8.2 (กุมภาพันธ์ 2013) git config core.commentcharอนุญาตให้กำหนดค่าอักขระความคิดเห็นนั้น ดูคำตอบของฉันด้านล่าง

— VonC

3

ตั้งแต่ Git v2.0.0 (2014.05.21) git commit --cleanup=scissorsจะมีความยืดหยุ่นมากกว่า ดูรายละเอียดในคำตอบของฉัน

— Sungam

4

ฉันต้องบอกว่าฉันประหลาดใจที่คน GitHub ไม่ได้คิดถึงปัญหานี้เมื่อพวกเขาตัดสินใจทำเครื่องหมายหมายเลขปัญหาด้วยแฮช!

— Michael Scheper

1

@Michael เพื่อให้เป็นธรรมการประชุมครั้งนี้ถูกใช้โดย Mantis, Trac, Redmine และคนอื่น ๆ ฉันคิดว่า GitHub เพิ่งตัดสินใจติดตามแทนที่จะสร้างล้อ ดูstackoverflow.com/questions/40495/…

— kelvin

235

พฤติกรรมนี้เป็นส่วนหนึ่งของพฤติกรรมการgit commitล้างข้อมูลเริ่มต้นของ หากคุณต้องการให้บรรทัดที่ขึ้นต้นด้วย#คุณสามารถใช้โหมดการทำความสะอาดทางเลือก

เช่น

git commit --cleanup=whitespace

หากคุณทำเช่นนี้คุณจะต้องระมัดระวังในการลบทุก#บรรทัดที่คุณไม่ต้องการให้ปรากฏในการส่ง

— CB Bailey
แหล่งที่มา

คำถามต่อไปคือ: ฉันจะแก้ไขความคิดเห็นข้อความคอมมิชชันที่ git แนะนำให้เริ่มต้นด้วย # โดยค่าเริ่มต้น

— อเล็กซ์

2

@Alex: มันถูกควบคุมโดยcommit.templateตัวแปรการกำหนดค่า git

— CB Bailey

23

วิธีนี้ใช้งานได้ดีในการแก้ไขการกระทำที่มีอยู่ เช่น:git commit --amend --cleanup=whitespace

— James Andres

@CharlesBailey: ฉันคาดว่าจะกำจัดข้อความที่กำหนดไว้ล่วงหน้าด้วยคอมไพล์คอมไพล์ -t / dev / null แต่ก็ยังคงแสดงให้เห็นว่า

— อเล็กซ์

ในขณะที่คุณสามารถมีข้อความส่งข้อความ "# 123 Commit message" รวมถึงความคิดเห็นของลูกค้าเช่น GitHub สำหรับ Mac และ SourceTree ฉันเดาว่าลูกค้าเหล่านี้ทำอะไรใช่หรือไม่

— Phil Ostler

134

โปรดทราบว่าตั้งแต่git1.8.2 (กุมภาพันธ์ 2013)คุณสามารถใช้อักขระอื่นนอกเหนือจาก ' #' สำหรับบรรทัดที่คอมเม้นต์ในข้อความคอมมิท

ที่ช่วยให้คุณใช้ ' #' สำหรับการอ้างอิงหมายเลขบั๊กของคุณ

บรรทัด "คำใบ้" ต่างๆที่ Git ให้ไว้เมื่อขอให้ผู้ใช้แก้ไขข้อความในเครื่องมือแก้ไขจะแสดงความคิดเห็นด้วย ' #' โดยค่าเริ่มต้น

core.commentCharตัวแปรการตั้งค่าสามารถนำมาใช้ในการปรับแต่ง 'นี้#' จะเป็นตัวละครที่แตกต่างกัน

ในทางทฤษฎีคุณสามารถใส่core.commentCharคำ (หลายตัวละคร) แต่ git 2.0.x / 2.1 จะเข้มงวดขึ้น (ไตรมาสที่ 3 ปี 2014)

ดูการกระทำ 50b54fdโดยNguyễnTháiNgọc Duy ( pclouds) :

config: เข้มงวดใน core.commentChar

เรายังไม่สนับสนุนสตริงความคิดเห็น(อย่างน้อยยังไม่ได้) และการเข้ารหัสอักขระแบบหลายไบต์อาจตีความผิดได้เช่นกัน

มีการอัปเดตการทดสอบด้วยเครื่องหมายจุลภาคสองตัวเนื่องจากละเมิดข้อนี้ มันมาพร้อมกับแพทช์ที่แนะนำcore.commentCharใน eff80a9 (อนุญาตให้ "ความคิดเห็นถ่าน" ที่กำหนดเอง - 2013-01-16) ไม่ชัดเจนสำหรับฉันว่าทำไมถึงต้องการมีพฤติกรรมดังกล่าว

git 2.0.x / 2.1 (ไตรมาสที่ 3 ปี 2014) จะเพิ่มตัวเลือกอัตโนมัติสำหรับcore.commentChar:
ดูการยอมรับ 84c9dc2

เมื่อcore.commentCharเป็น " auto" ถ่านความคิดเห็นเริ่มต้นด้วย ' #' ตามค่าเริ่มต้น แต่ถ้าอยู่ในข้อความที่เตรียมไว้ให้ค้นหาถ่านตัวอื่นในชุดย่อยขนาดเล็ก สิ่งนี้ควรหยุดความประหลาดใจเพราะคอมไพล์ตัดบางบรรทัดโดยไม่คาดคิด

โปรดทราบว่าคอมไพล์ไม่ฉลาดพอที่จะรับรู้ ' #' เป็นถ่านความคิดเห็นในเทมเพลตที่กำหนดเองและแปลงถ้าถ่านความคิดเห็นสุดท้ายแตกต่างกัน
มันคิดว่าบรรทัด '#' ในเทมเพลตที่กำหนดเองเป็นส่วนหนึ่งของข้อความยืนยัน ดังนั้นอย่าใช้สิ่งนี้กับเทมเพลตที่กำหนดเอง

รายการตัวละครของผู้สมัครสำหรับ "auto" คือ:

# ; @ ! $ % ^ & | :

นั่นหมายความว่าคำสั่งที่ต้องการgit commit -m '#1 fixed issue'จะเปลี่ยน commentChar เป็น ' ;' โดยอัตโนมัติเนื่องจาก ' #' ถูกใช้ในข้อความยืนยัน

— VonC
แหล่งที่มา

1

หากต้องการแก้ไขไวยากรณ์ HL หลังจากนี้ให้ดูคำถามที่เกี่ยวข้องนี้: stackoverflow.com/questions/16164624/…

— Alois Mahdal

@ กูรูทรูฉันได้กล่าวคำตอบซ้ำเพื่อสะท้อนให้เห็นว่า

— VonC

1

@newbyca กับ git เวอร์ชันใดที่คุณเห็นว่าไม่รองรับในระหว่างการรีบูตแบบโต้ตอบ?

— VonC

2

ดังนั้นในการตั้งค่านี้คุณสามารถทำได้เช่น:$ git config --global core.commentchar ';'

— davetapley

6

ฉันรักคำตอบนี้ Oneliner สำหรับวิธีแก้ปัญหาที่แนะนำใหม่:git config --global core.commentChar auto

— aross

81

คำตอบที่นี่ดีและมีรายละเอียด แต่สำหรับ noob git อย่างฉันการปรับแต่งตัวเลือก config git นั้นไม่ชัดเจนนัก นี่คือตัวอย่างที่จะเปลี่ยนจาก#เป็น;ตัวอักษรแสดงความคิดเห็น:

git config core.commentChar ";"

นั่นคือทั้งหมดที่คุณต้องทำ

— Matthieu Napoli
แหล่งที่มา

3

สิ่งนี้จะเปลี่ยนข้อความความเห็นเริ่มต้นที่ git เพิ่มไปยังข้อความยืนยันเมื่อมีผู้ใช้git commitเปิดโปรแกรมแก้ไขที่กำหนดค่าไว้เพื่อแก้ไขข้อความยืนยัน!

— Michael Trouw

1

สำหรับการแก้ไขครั้งเดียวใช้สิ่งนี้: git -c core.commentChar="|" commit --amend(แทนที่|ด้วยสิ่งที่คุณต้องการ)

— Droogans

62

คุณสามารถใช้ตัวเลือกบรรทัดคำสั่ง-m:

git commit -m "#123 fixed"

— Olivier Verdier
แหล่งที่มา

35

แต่นี่เป็นข้อความยืนยันที่น่ากลัว ตรวจสอบให้แน่ใจว่าได้รวมข้อบกพร่องที่เกิดขึ้นและวิธีการแก้ไข

— บุคคลที่ดี

3

ข้อความคอมมิชชันนั้นตกลงตราบเท่าที่มีข้อผิดพลาดจำนวนมาก

— Trident D'Gao

6

ไม่ใช่ถ้าระบบติดตามบั๊กเกิดความเสียหายกะทันหันและคุณไม่มีข้อมูลสำรอง! :)

— caveman_dick

38

หากคุณกำลังทำ rebase เชิงโต้ตอบจากนั้นเมื่อคุณบันทึกข้อความการกระทำของคุณโดยไม่มีอะไรในมัน (เพราะ#ที่จุดเริ่มต้นทำให้มันเป็นความคิดเห็นและดังนั้นจึงถูกละเว้น) git จะแสดงสิ่งที่ต้องทำ:

Aborting commit due to empty commit message.
Could not amend commit after successfully picking 5e9159d9ce3a5c3c87a4fb7932fda4e53c7891db... 123 salt hashed passwords
This is most likely due to an empty commit message, or the pre-commit hook
failed. If the pre-commit hook failed, you may need to resolve the issue before
you are able to reword the commit.
You can amend the commit now, with

        git commit --amend

Once you are satisfied with your changes, run

        git rebase --continue

ดังนั้นเพียงแค่แก้ไขข้อความ:

git commit --amend -m "#123 salt hashed passwords"

และดำเนินการ rebase ต่อ:

git rebase --continue

— โอเวนวิลเลียมส์
แหล่งที่มา

สิ่งนี้ถูกต้องสำหรับผู้ที่ผลักดันการกระทำแล้ว แต่ต้องการเปลี่ยนข้อความ

— Hoang Trinh

นอกจากนี้ยังนำไปใช้กับคอมมิทใหม่หากคุณป้อนข้อความโดยใช้โปรแกรมแก้ไขและมีแฮชที่จุดเริ่มต้น

— โอเวนวิลเลียมส์

29

git commit --cleanup=scissorsควรใช้ มันถูกเพิ่มไปยังGit v2.0.0เมื่อ 2014.05.21

จาก git commit --help

--cleanup=<mode>
  scissors
    Same as whitespace, except that everything from (and including) the line
    "# ------------------------ >8 ------------------------" is truncated if the message
    is to be edited. "#" can be customized with core.commentChar.

— Sungam
แหล่งที่มา

ฉันไม่เข้าใจว่าสิ่งนี้ดีกว่าการใช้commit.cleanup = whitespaceและการลบ# …ความเห็นด้วยมืออย่างไร @CharlesBailey ได้แนะนำแล้ว scissors- โหมดเพียงแค่ล้างทำความสะอาดกรรไกร - ไวยากรณ์ที่ใช้โดยgit format-patch/ mailinfo/ am; มันไม่ได้ใช้…-- >8 --…ไวยากรณ์เมื่อมีการเพิ่มความเห็นที่จะกระทำข้อความ

— Slipp D. Thompson

1. ฉันคิดว่ามันจะดีกว่าเพราะฉันไม่จำเป็นต้อง "ลบ# ...ความเห็นออกโดยยาก 2. ฉันไม่แน่ใจเกี่ยวกับส่วนที่สองของความคิดเห็นของคุณscissorsโหมดอยู่ในแน่นอนคุณใช้git commit --helpเวอร์ชันgitอะไร @ SlippD.Thompson

— Sungam

ฮะ? whitespaceโหมดนำเสนอการลอก 1. นำและลากบรรทัดว่าง, 2. ตามช่องว่าง, 3. ยุบบรรทัดว่างต่อเนื่อง scissorsข้อเสนอปอก 1. ชั้นนำและต่อท้ายบรรทัดว่าง 2. ช่องว่างต่อท้าย 3. การล่มสลายบรรทัดว่างติดต่อกัน 4. ทุกอย่างจาก (และรวม) # -…- >8 -…-บรรทัด อย่างไรก็ตามกรรไกรเส้น ( # -…- >8 -…-) จะถูกแทรกเฉพาะเมื่อใช้git-format-patch/ /mailinfo amดังนั้นสำหรับปกติgit-commit/ merge/ rebase/ cherry-pickเวิร์กโฟลว์scissorsโหมดการปอกจะมีประโยชน์มากกว่าwhitespaceโหมดศูนย์ v2.11.0

— Slipp D. Thompson

@ SlippD.Thompson คุณใช้คอมไพล์รุ่นใด ผมใช้ 2.8.3 และgit commit --cleanup=scissors ไม่ย่อหน้า# ------------------------ >8 ------------------------เส้นก่อนที่จะมีgit statusข้อมูล ชอบด้านล่าง: `# ------------------------> 8 ------------------- ----- # อย่าแตะที่บรรทัดด้านบน # ทุกอย่างด้านล่างจะถูกลบออก # ในสาขาหลัก # # เริ่มต้นยอมรับ # # การเปลี่ยนแปลงที่จะเกิดขึ้น: # ไฟล์ใหม่:

— .gitignore

1

ฉันเชื่อว่าฉันได้รับที่ด้านล่างของนี้ Git ทำการแทรก# ------------------------ >8 ------------------------ก่อนสถานะ txt“ ดูเหมือนว่าคุณอาจจะ…” _ เมื่อใช้scissors; แต่มันแทรกบรรทัดกรรไกรหลังจาก# Conflicts: …ข้อความ ฉันcommit.status = falseตั้งค่าไว้.gitconfigแล้วดังนั้นฉันจึงไม่เห็นข้อความสถานะใด ๆ มี แต่ข้อความขัดแย้งเท่านั้น ฉันยืนแก้ไข; เปลี่ยนเป็น upvote

— Slipp D. Thompson

3

ใช้คำนำหน้าอื่นสำหรับหมายเลขตั๋ว หรือเติมคำลงในหมายเลขตั๋วเช่น "Bug # 42" หรือเพิ่มอักขระเว้นวรรคหนึ่งตัวต่อบรรทัด หากคุณต้องการลบช่องว่างนั้นคุณสามารถเพิ่มการผูกเบ็ดสำหรับสิ่งนั้นได้

โดยส่วนตัวแล้วฉันไม่ต้องการให้มีการจัดการข้อความที่ส่งโดย hook เพราะมันอาจทำให้เกิดการระคายเคืองเมื่อมันเริ่มต้นเมื่อคุณไม่ต้องการ ทางออกที่ง่ายที่สุดน่าจะเป็นปัญหาที่คิดใหม่

— wilhelmtell
แหล่งที่มา

1

ถ้อยคำที่แตกต่างกันเป็นเพียงวิธีแก้ปัญหาสำหรับปัญหา หากแนวทางโครงการระบุว่าข้อความยืนยันจะต้องเริ่มต้นด้วยรหัสตั๋วจากนั้นจะไม่สามารถใช้งานได้ และตะขอหลังการโพสต์น่าเกลียดมาก ฉันคิดว่าฉันควรจะรายงานเรื่องนี้ "ข้อผิดพลาด" เพื่อพัฒนาคอมไพล์

— knittl

ไม่ต้องกังวลนั่นเป็นสิ่งที่ผิด อย่าขอให้ผู้พัฒนาคอมไพล์ทำงานตามคำแนะนำของคุณ คุณจะไม่ขอให้ Dennis Ritchie เปลี่ยนภาษา C ดังนั้นจึงรองรับการตั้งชื่อตัวแปรของการเริ่มต้นด้วยอักขระแฮชใช่ไหม เช่นเดียวกับที่นี่ หากข้อความคอมมิชชันอนุญาตให้แสดงความคิดเห็นสิ่งนี้จะเพิ่มการสนับสนุนสิ่งที่น่าสนใจเช่นการเปิดตัวแก้ไขคอมมิชชันด้วย diff ที่เพิ่มเข้ามาและแสดงความคิดเห็นดังนั้นคุณไม่จำเป็นต้องจำการเปลี่ยนแปลงที่แน่นอนของคุณ มีอะไรผิดปกติกับการรักษาตัวละครในอวกาศ

— wilhelmtell

1

สนับสนุนตัวหนีในคอมไพล์กระทำข้อความจะไม่เป็นเช่นเรื่องใหญ่

— knittl

5

มันเป็นคำขอคุณสมบัติที่เหมาะสมอย่างสมบูรณ์แบบ โดยเฉพาะอย่างยิ่งในแง่ของความจริงที่ว่า Trac, AFAICT ไม่เชื่อมโยงคอมมิชชันกับสลิปผิดพลาดหากข้อความคอมมิชชันเริ่มต้นด้วยหมายเลขสลิปเริ่มต้นด้วยแฮช ดังนั้นมันจึงไม่ใช่แค่มาตรฐานของใครบางคน แต่เป็นไวยากรณ์ที่ต้องการของเครื่องมือ ปล่อยให้ Git devs ตัดสินใจว่ามันคุ้มค่าหรือไม่ (และใช่ Trac อาจยังแก้ไขปัญหาได้มีอะไรผิดปกติกับขอให้ Git ทำสิ่งที่มันสามารถเกินไป..)

— ลุค Maurer

“ โดยเฉพาะอย่างยิ่งในแง่ของความจริงที่ว่า Trac, AFAICT ไม่ได้เชื่อมโยงคอมมิชชันกับบั๊กสลิปหากข้อความคอมมิชชันเริ่มต้นด้วยหมายเลขสลิปเริ่มต้นด้วยแฮช” - จากประสบการณ์ที่ จำกัด ของฉันกับ Trac สิ่งที่#xxxเกิดขึ้นที่ใดก็ได้ในข้อความยืนยันจะเชื่อมโยงกับปัญหา มันไม่จำเป็นต้องเป็นการเริ่มต้นของความมุ่งมั่น บางทีนี่อาจเป็นสิ่งที่เปลี่ยนแปลงไปในช่วงห้าปีที่ผ่านมา?

— Guildenstern

1

ทั้งหมดกระทำของฉันเริ่มต้นด้วย#issueNumberดังนั้นฉันใส่สำเร็จรูปนี้เพื่อของฉันvim .git/hooks/commit-msg:

NAME=$(git branch | grep '*' | sed 's/* //') 
echo "$NAME"' '$(cat "$1") > "$1"

ดังนั้นขอสมมติว่าเรามีสาขาและเราจะทำให้การกระทำข้อความ#15 ด้วยวิธีการนี้สุดท้ายกระทำข้อความจะadd new awesome feature#15 add new awesome feature

— valignatev
แหล่งที่มา