Запустіть повідомлення git commit з хешмак (#)


283

Git розглядає рядки, починаючи з #рядків коментарів під час вчинення. це дуже дратує при роботі з системою відстеження квитків і намагається написати номер квитка на початку рядка, наприклад

#123 salt hashed passwords

git просто видалить рядок із повідомлення фіксації. чи є спосіб уникнути хешу? Я спробував \і !, але нічого не працює. пробіли раніше #зберігаються, тому вони також не є робочим рішенням проблеми.


8
@AlexBudovski тому, що є цінність у стислість
Хаві

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 не замислювалися над цією проблемою, коли вирішили позначити номер випуску хешами!
Майкл Шепер

1
@Michael Для справедливості цю конвенцію вже використовували Mantis, Trac, Redmine та, ймовірно, інші. Я гадаю, що GitHub просто вирішив дотримуватися цього, а не винаходити колесо. Дивіться stackoverflow.com/questions/40495/…
kelvin

Відповіді:


235

Така поведінка є частиною git commit"очищення" за замовчуванням. Якщо ви хочете продовжувати рядки, #ви можете скористатися альтернативним режимом очищення.

Напр

git commit --cleanup=whitespace

Якщо ви це зробите, ви повинні бути обережними, щоб видалити всі #рядки, які ви не хочете відображати у коміті.


Наступне питання: Де я можу редагувати коментарі до повідомлення про фіксацію, що git вводить, які починаються за замовчуванням із знаком #?
Олексій

2
@Alex: Це контролюється commit.templateзмінною конфігурації git.
CB Bailey

23
Це чудово підходить і для внесення змін до існуючих комісій. Напр .:git commit --amend --cleanup=whitespace
Джеймс Андрес

@CharlesBailey: Я очікував позбутися попередньо визначеного тексту за допомогою git commit -t / dev / null, але це все ще показує
Alex

Оскільки ви можете мати повідомлення про "# 123 повідомлення про прихильність", а також коментарі клієнтів, таких як GitHub для Mac та SourceTree, я думаю, що ці клієнти роблять так?
Філ Остлер

134

Зауважте, що, починаючи з git1.8.2 (лютий 2013 р.) , Ви можете використовувати інший символ, ніж " #" для коментованого рядка у повідомленні "виконувати".

Це дозволяє використовувати " #" для посилання на номер вашої помилки.

Різні рядки "підказки", які дає Git, коли він просить користувача редагувати повідомлення в редакторі, #за замовчуванням коментується " ".

core.commentCharМінлива конфігурації може використовуватися для настройки цього « #» на інший символ.


Теоретично ви можете ввести core.commentCharслово (кілька символів), але git 2.0.x / 2.1 буде суворішим (Q3 2014).

Див. Комісію 50b54fd від Nguyễn Thái Ngọc Duy ( pclouds) :

config: бути суворим у core.commentChar

Ми не підтримуємо рядки коментарів (принаймні, поки що). І багатобайтове кодування символів також може бути неправильно трактовано.

Тест з двома комами оновлюється, оскільки це порушує це. Він додається з патчем, який вводиться core.commentCharв eff80a9 (Дозволити спеціальний "char char" - 2013-01-16). Мені незрозуміло, чому така поведінка потрібна.


git 2.0.x / 2.1 (Q3 2014) додасть автоматичний вибір для core.commentChar:
Див. команду 84c9dc2

Коли core.commentChar" auto", "char char" починається з " #", як за замовчуванням, але якщо це вже в підготовленому повідомленні, знайдіть інший знак у невеликому підмножині. Це повинно зупинити сюрпризи, оскільки git знімає деякі рядки несподівано.

Зауважте, що git недостатньо розумний, щоб розпізнати " #" як знак коментарів у користувацьких шаблонах та перетворити його, якщо кінцевий графік коментарів відрізняється.
Він вважає, що рядки "#" у власних шаблонах є частиною повідомлення про фіксацію. Тому не використовуйте це для користувацьких шаблонів.

Список кандидатських символів для "авто":

# ; @ ! $ % ^ & | :

Це означає, що така команда, як git commit -m '#1 fixed issue'автоматично, переключить коментарChar на ' ;', тому що ' #' було використано у повідомленні фіксації.


1
Для того, щоб виправити синтаксис HL після цього побачити цей родинний питання: stackoverflow.com/questions/16164624 / ...
Alois Mahdal

@ Гутен Правда, я переформулював відповідь, щоб це відобразити.
VonC

1
@newbyca, з якою версією git ви бачите, що не підтримується під час інтерактивної бази даних?
VonC

2
Отже, встановити це ви можете, наприклад:$ git config --global core.commentchar ';'
davetapley

6
Я люблю цю відповідь. Онелінер для нового запропонованого рішення:git config --global core.commentChar auto
1818

81

Відповіді тут хороші та детальні, але для git noob, як я, налаштування параметрів git config не так очевидно. Ось приклад для переходу #до ;символів для коментарів:

git config core.commentChar ";"

Це все, що вам потрібно зробити.


3
Це також змінює коментований текст за замовчуванням, який git додає до повідомлення про фіксацію, коли використовується git commitвідкриття налаштованого редактора для редагування повідомлення про фіксацію!
Майкл Труу

1
Для разових виправлень скористайтеся цим: git -c core.commentChar="|" commit --amend(замініть |на все, що завгодно).
Droogans

62

Можна скористатися параметром командного рядка -m:

git commit -m "#123 fixed"

35
Але це жахливе повідомлення про вчинення. не забудьте вказати, що таке помилка та як її виправити
Good Person

3
повідомлення про фіксацію нормально, поки є кількість помилок
Trident D'Gao,

6
Не якщо система відстеження помилок раптом пошкоджується і у вас немає резервної копії! :)
caveman_dick

38

Якщо ви робите інтерактивну базу даних, тоді, коли ви зберігаєте повідомлення про фіксацію, не маючи нічого в ній (тому що #на початку зробила це коментарем і тому було проігноровано), 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"

і продовжити ребауз:

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.

Я не розумію, як це краще, ніж використовувати commit.cleanup = whitespaceта видаляти # …коментарі вручну, як @CharlesBailey вже запропонував. scissors-модель просто додатково очищає синтаксис ножиць, використовуваний git format-patch// mailinfo/ am; він не використовує …-- >8 --…синтаксис під час додавання коментарів для фіксації повідомлень .
Сліпп Д. Томпсон

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
Сліп Д. Томпсон

@ SlippD.Thompson Яку версію git ви використовуєте? Я використовую 2.8.3 і git commit --cleanup=scissors DOES випереджати # ------------------------ >8 ------------------------рядок перед git statusінформацією. Як і нижче: `# ------------------------> 8 ------------------- ----- # Не торкайтеся рядка вище. # Все, що нижче, буде видалено. # Про головне відділення # # Первісне введення # # Внесення змін: # новий файл: .gitignore `
Sungam

1
Я вважаю, що я дійшов до цього. Git дійсно вставляє # ------------------------ >8 ------------------------перед txt статусу "Схоже, ви можете бути ..." _ при використанні scissors; однак, він вставляє рядок ножиці після в # Conflicts: …тексті. Я був commit.status = falseвстановлений у своєму .gitconfig, тому я не бачив жодного тексту статусу, лише тексту конфлікту. Я стою виправлений; зміна на виклик.
Сліпп Д. Томпсон,

3

Використовуйте інший префікс для номера квитка. Або допишіть слово до номера квитка, наприклад "Помилка № 42". Або додайте до рядка один пробільний символ; якщо ви хочете видалити цей пробіл, ви можете додати гак для фіксації.

Мені особисто не хотілося б такого маніпулювання повідомленнями здійснювати гаком, оскільки це може бути дуже дратує, коли спрацьовує, коли ви цього не хочете. Найпростішим рішенням є, мабуть, переосмислення проблеми.


1
різні формулювання є лише вирішенням проблеми. якщо в керівництві проекту зазначено, що повідомлення про фіксацію повинно починатися з ідентифікатора квитка, воно не працюватиме. і гачок після вчинення дуже некрасивий. Думаю, я повинен повідомити про цю "помилку" розробникам git
knittl

Не турбуйтеся, це було б неправильно. Не вимагайте від розробників git працювати відповідно до ваших рекомендацій. Ви б не просили Денніса Річі змінити мову С, щоб він підтримував у вас зміну імен змін, починаючи з символу хешу, правда? Це ж стосується і тут. Якщо повідомлення про фіксацію дозволяють коментувати, це додає підтримку цікавих речей, наприклад, відкриття редактора комісій з розширенням, доданим та прокоментованим, тому вам не потрібно пам’ятати про ваші точні зміни. Що поганого в збереженні провідного космічного персонажа?
wilhelmtell

1
підтримка символів втечі в повідомленні про вчинення git не було б такою великою справою
knittl

5
Це абсолютно розумний запит на функцію. Особливо з огляду на той факт, що Trac, AFAICT, не пов'язує комісію з помилкою помилки, якщо повідомлення про фіксацію не починається з номера ковзання, починаючи з хеша. Тож це не просто чиїсь стандарти, це необхідний синтаксис інструменту. Нехай Git devs вирішить, варто чи ні. (І так, Trac також міг вирішити проблему. Немає нічого поганого в тому, щоб просити Git зробити все, що він може.)
Люк Маурер

"Особливо з огляду на той факт, що Trac, AFAICT, не пов'язує зобов'язання з помилкою помилок, якщо повідомлення про фіксацію не починається з номера промаху, починаючи з хеша." - за моїм обмеженим досвідом роботи з Trac, щось подібне, #xxxщо трапляється де-небудь у повідомленні про зв'язок, буде посилатися на проблему. Це не повинно бути на початку здійснення. Може, це щось, що змінилося за останні п’ять років?
Гільденстерн

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.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.