українська мова ▾ Topics ▾ Latest version ▾ git-send-email last updated in 2.54.0

НАЗВА

git-send-email — Надсилання набору латок у вигляді листів електронної пошти

СИНОПСИС

git send-email [<options>] (<file>|<directory>)…​
git send-email [<options>] <format-patch-options>
git send-email --dump-aliases
git send-email --translate-aliases

ОПИС

Приймає латки, вказані в командному рядку, та надсилає їх електронною поштою. Латки можна вказати у вигляді файлів, тек (у цьому випадку будуть надіслані всі файли з теки) або безпосередньо у вигляді списку змін. В останньому випадку до команди git send-email можна передавати будь-який формат, що підтримується git-format-patch[1], а також параметри, які розуміє git-format-patch[1].

Заголовки листів можна налаштувати за допомогою параметрів командного рядка. Якщо параметри не вказано в командному рядку, користувачеві буде запропоновано ввести необхідну інформацію через інтерфейс із підтримкою ReadLine.

Для файлів латок приймаються два формати:

  1. файли формату mbox

    Те що генерує git-format-patch[1]. Більшість заголовків та MIME-форматування ігноруються.

  2. Оригінальний формат, який використовувався скриптом send_lots_of_email.pl Грега Кроа-Хартмана

    У цьому форматі перший рядок файлу має містити значення Cc:, а другий рядок — Subject: повідомлення.

ОПЦІЇ

Складання

--annotate

Переглянути та відредагувати кожну латку, яку ви збираєтеся надіслати. Стандартним значенням є значення параметра sendemail.annotate. Інформацію про параметр sendemail.multiEdit див. у розділі КОНФІГУРАЦІЯ.

--bcc=<address>,…​

Вкажіть значення Прихована копія: для кожного електронного листа. Стандартно використовується значення sendemail.bcc.

Цей параметр можна вказати кілька разів.

--cc=<address>,…​

Вкажіть початкове значення поля Cc: для кожного електронного листа. Стандартно використовується значення sendemail.cc.

Цей параметр можна вказати кілька разів.

--compose

Запустити текстовий редактор (див. GIT_EDITOR у git-var[1]), щоб відредагувати вступне повідомлення для серії латок.

При використанні опції --compose команда git send-email використовуватиме заголовки From, To, Cc, Bcc, Subject, Reply-To та In-Reply-To, вказані у повідомленні. Якщо тіло повідомлення (те, що ви вводите після заголовків і порожнього рядка) містить лише порожні рядки (або рядки з префіксом Git:), підсумок не буде надіслано, але згадані вище заголовки будуть використані, якщо їх не видалити.

Буде запропоновано ввести відсутні заголовки From або In-Reply-To.

Дивіться розділ КОНФІГУРАЦІЯ для sendemail.multiEdit.

--from=<address>

Вкажіть відправника електронних листів. Якщо не вказано в командному рядку, використовується значення параметра конфігурації sendemail.from. Якщо а ні параметр командного рядка, а ні sendemail.from не встановлено, користувачеві буде запропоновано ввести значення. Стандартним значенням для запиту буде GIT_AUTHOR_IDENT або GIT_COMMITTER_IDENT, якщо воно не встановлено, як повертається git var -l.

--reply-to=<address>

Вкажіть адресу, на яку мають надходити відповіді від одержувачів. Використовуйте це, якщо відповіді на повідомлення мають надходити на адресу, відмінну від тієї, що вказана параметром --from.

--in-reply-to=<identifier>

Зробити так, щоб перший лист (або всі листи з --no-thread) показувались як відповідь на вказаний Message-ID, що дозволяє уникнути розриву потоків для створення нової серії латок. Другий та наступні листи будуть надіслані як відповіді відповідно до налаштування --[no-]chain-reply-to.

Так, наприклад, якщо вказано параметри --thread та --no-chain-reply-to, друга та наступні латки будуть відповідями на першу, як показано на ілюстрації нижче, де [PATCH v2 0/3] є відповіддю на [PATCH 0/2]:

[PATCH 0/2] Here is what I did...
  [PATCH 1/2] Clean up and tests
  [PATCH 2/2] Implementation
  [PATCH v2 0/3] Here is a reroll
    [PATCH v2 1/3] Clean up
    [PATCH v2 2/3] New tests
    [PATCH v2 3/3] Implementation

Потрібно лише якщо також встановлено --compose. Якщо --compose не встановлено, буде запропоновано це зробити.

--outlook-id-fix
--no-outlook-id-fix

SMTP-сервери Microsoft Outlook відкидають ідентифікатор повідомлення (Message-ID), надісланий електронною поштою, і присвоюють новий випадковий ідентифікатор, тим самим порушуючи ланцюжок листування.

З параметром --outlook-id-fix команда git send-email використовує механізм, характерний для серверів Outlook, щоб дізнатися ідентифікатор повідомлення (Message-ID), який сервер призначив для виправлення структури ланцюжка листів. Використовуйте цей параметр лише в тому випадку, якщо ви впевнені, що сервер повідомляє про переписаний ідентифікатор повідомлення так само, як це роблять сервери Outlook.

Якщо цей параметр не вказано, виправлення стандартно виконується під час звʼязку з «smtp.office365.com або smtp-mail.outlook.com. Використовуйте --no-outlook-id-fix, щоб це вимкнути навіть під час зв’язку з цими двома серверами.

--subject=<string>

Вкажіть початкову тему електронного листа. Потрібно лише якщо також встановлено параметр --compose. Якщо параметр --compose не встановлено, буде запропоновано ввести цю тему.

--to=<address>,…​

Вкажіть основного одержувача згенерованих електронних листів. Зазвичай це буде відповідальний за розробку проєкту. Зазвичай використовується значення конфігурації sendemail.to; якщо воно не вказано й --to-cmd не вказано також, буде запропоновано його ввести.

Цей параметр можна вказати кілька разів.

--8bit-encoding=<encoding>

Якщо ви зіткнулися з повідомленням, що містить не-ASCII-символи, або з темою, у якій не вказано кодування, додайте заголовки/цитування, щоб вказати, що воно закодовано у форматі <encoding>. Стандартним значенням є значення параметра sendemail.assume8bitEncoding; якщо це значення не вказано, система запропонує його ввести при виявленні будь-яких файлів, що містять не-ASCII-символи.

Зверніть увагу, що жодних спроб перевірити кодування не робиться.

--compose-encoding=<encoding>

Вкажіть кодування повідомлення, що створюється. Стандартним значенням є значення параметра sendemail.composeEncoding; якщо це значення не вказано, використовується UTF-8.

--transfer-encoding=(7bit|8bit|quoted-printable|base64|auto)

Вкажіть кодування передачі, яке буде використовуватися для надсилання повідомлення через SMTP. Параметр 7bit призведе до помилки при виявленні повідомлення, що містить не-ASCII-символи. quoted-printable може бути корисним, коли репозиторій містить файли з символами повернення каретки, але значно ускладнює ручну перевірку файлу електронного листа з необробленою латкою (як збережено з MUA). base64 є ще більш надійним, але й ще більш непрозорим. auto використовуватиме 8bit, коли це можливо, а в іншому випадку — quoted-printable.

Типовим значенням є значення параметра конфігурації sendemail.transferEncoding; якщо воно не вказано, типовим значенням є auto.

--xmailer
--no-xmailer

Додати (або заборонити додавання) заголовка X-Mailer:. Типово заголовок додається, але його можна вимкнути, встановивши для змінної конфігурації sendemail.xmailer значення false.

Надсилання

--envelope-sender=<address>

Вкажіть адресу відправника, яка використовується для надсилання електронних листів. Це корисно, якщо ваша стандартна адреса не є тією, на яку ви підписалися у списку розсилки. Щоб використовувати адресу From, встановіть значення auto. Якщо ви використовуєте бінарний файл sendmail, ви повинні мати відповідні права для параметра -f. Стандартним значенням є значення змінної конфігурації sendemail.envelopeSender; якщо воно не вказане, вибір відправника листа залишається за вашим MTA.

--sendmail-cmd=<command>

Вкажіть команду для надсилання електронного листа. Команда має бути схожою на sendmail; зокрема, вона повинна підтримувати параметр -i. Команда буде виконана в оболонці, якщо необхідно. Зазвичай використовується значення sendemail.sendmailCmd. Якщо не вказано, а також не вказано --smtp-server, git send-email шукатиме sendmail у /usr/sbin, /usr/lib та $PATH.

--smtp-encryption=<encryption>

Вкажіть, яким чином починається шифрування для SMTP-зʼєднання. Допустимими значеннями є ssl та tls. Будь-яке інше значення призведе до використання звичайного (незашифрованого) SMTP, який стандартно використовує порт 25. Незважаючи на назви, обидва значення використовуватимуть одну й ту саму нову версію TLS, але з історичних причин мають такі назви. ssl означає «неявне» шифрування (іноді його називають SMTPS), яке стандартно використовує порт 465. tls означає «явне» шифрування (часто відоме як STARTTLS), яке стандартно використовує порт 25. SMTP-сервер може використовувати й інші порти, які не є стандартними. Поширеним альтернативним портом для tls та незашифрованого режиму є 587. Вам потрібно перевірити документацію вашого провайдера або конфігурацію сервера, щоб переконатися у вашому конкретному випадку. Стандартним значенням є значення sendemail.smtpEncryption.

--smtp-domain=<FQDN>

Вкажіть повне імʼя домену (FQDN, Fully Qualified Domain Name), яке використовується в команді HELO/EHLO для SMTP-сервера. Деякі сервери вимагають, щоб FQDN збігалося з вашою IP-адресою. Якщо це значення не вказано, git send-email спробує визначити ваш FQDN автоматично. Стандартним значенням є значення sendemail.smtpDomain.

--smtp-auth=<mechanisms>

Список дозволених механізмів SMTP-AUTH, розділених пробілами. Цей параметр примусово використовує лише перелічені механізми. Приклад:

$ git send-email --smtp-auth="PLAIN LOGIN GSSAPI" ...

Якщо хоча б один із зазначених механізмів відповідає тим, що оголошуються SMTP-сервером, і якщо він підтримується використаною бібліотекою SASL, цей механізм використовується для автентифікації. Якщо не вказано а ні sendemail.smtpAuth, а ні --smtp-auth, можна використовувати всі механізми, що підтримуються бібліотекою SASL. Спеціальне значення none може бути вказано для повного вимкнення автентифікації незалежно від --smtp-user.

--smtp-pass[=<password>]

Пароль для SMTP-AUTH. Аргумент необов’язковий: якщо аргумент не вказано, то як пароль використовується порожній рядок. Стандартне значення — sendemail.smtpPass, проте --smtp-pass завжди замінює це значення.

Крім того, паролі не потрібно вказувати у файлах конфігурації або в командному рядку. Якщо імʼя користувача було вказано (за допомогою --smtp-user або sendemail.smtpUser), але пароль не було вказано (за допомогою --smtp-pass або sendemail.smtpPass), то пароль отримується за допомогою git-credential[1].

--no-smtp-auth

Вимкнути SMTP-автентифікацію. Скорочена форма --smtp-auth=none.

--smtp-server=<host>

Вкажіть вихідний SMTP-сервер для використання (наприклад, smtp.example.com або необроблену IP-адресу). Якщо не вказано, а також не вказано --sendmail-cmd, зазвичай sendmail шукатиметься в /usr/sbin, /usr/lib та $PATH, якщо така програма доступна, в іншому випадку повертатиметься до localhost.

Для зворотної сумісності цей параметр також може вказувати повний шлях до програми, подібної до sendmail; програма повинна підтримувати параметр -i. Цей метод не підтримує передачу аргументів або використання простих імен команд. У таких випадках використання розгляньте можливість використання --sendmail-cmd.

--smtp-server-port=<port>

Вкажіть порт, відмінний від стандартного порту (SMTP-сервери зазвичай прослуховують smtp-порт 25, але можуть також прослуховувати порт надсилання 587 або поширений SSL-smtp-порт 465); також приймаються символічні назви портів (наприклад, submission замість 587). Порт також можна встановити за допомогою змінної конфігурації sendemail.smtpServerPort.

--smtp-server-option=<option>

Вкажіть параметр вихідного SMTP-сервера, який потрібно використовувати. Стандартне значення можна вказати за допомогою параметра конфігурації sendemail.smtpServerOption.

Опцію --smtp-server-option потрібно повторити для кожної опції, яку потрібно передати серверу. Аналогічно, для кожної опції потрібно використовувати різні рядки у файлах конфігурації.

--smtp-ssl

Застарілий псевдонім для --smtp-encryption ssl.

--smtp-ssl-cert-path <path>

Шлях до сховища сертифікатів довірених центрів сертифікації (CA) для перевірки сертифікатів SMTP SSL/TLS (це може бути тека, оброблена командою c_rehash, або окремий файл, що містить один або кілька сертифікатів у форматі PEM, об’єднаних у єдиний файл): докладнішу інформацію див. в описі опцій -CAfile <файл> та -CApath <dir> на сторінці довідки https://docs.openssl.org/master/man1/openssl-verify/ [verify(1) OpenSSL] для докладнішої інформації про це). Встановіть порожній рядок, щоб вимкнути перевірку сертифікатів. Стандартне значення — це значення змінної конфігурації sendemail.smtpSSLCertPath, якщо вона встановлена, або стандартне значення, вбудоване в бібліотеку SSL, у протилежному випадку (що має бути найкращим вибором на більшості платформ).

--smtp-user=<user>

Імʼя користувача для SMTP-AUTH. Стандартне значення — sendemail.smtpUser; якщо імʼя користувача не вказано (з --smtp-user або sendemail.smtpUser), то спроба автентифікації не виконується.

--smtp-debug=(0|1)

Увімкнути (1) або вимкнути (0) вивід налагодження. Якщо ввімкнено, команди та відповіді SMTP будуть виведені. Корисно для налагодження проблем з підключенням TLS та автентифікацією.

--imap-sent-folder=<folder>

Деякі постачальники послуг електронної пошти (наприклад, iCloud) не надсилають копії електронних листів, надісланих через SMTP, до теки «Надіслані» або подібної теки у вашій поштовій скриньці. Використовуйте цю опцію, щоб за допомогою команди git imap-send надіслати копію електронних листів до теки, вказаної за допомогою цієї опції. Ви можете виконати команду git imap-send --list, щоб отримати список дійсних назв тек, включаючи правильну назву теки «Надіслані» у вашій поштовій скриньці. Ви також можете використовувати цю опцію для надсилання електронних листів до спеціальної теки IMAP на ваш вибір.

Ця функція вимагає налаштування git imap-send. Див. інструкції за посиланням git-imap-send[1].

--use-imap-only
--no-use-imap-only

Якщо це встановлено, усі електронні листи будуть скопійовані лише до теки IMAP, зазначеної за допомогою --imap-sent-folder або sendemail.imapSentFolder, і не будуть надіслані одержувачам. Корисно, якщо ви просто хочете створити чернетку електронних листів і використовувати інший поштовий клієнт для їх надсилання. Якщо вимкнено за допомогою --no-use-imap-only, електронні листи будуть надіслані як завжди. Стандартно вимкнено, але для його ввімкнення можна використовувати змінну конфігурації sendemail.useImapOnly.

Ця функція вимагає налаштування git imap-send. Див. інструкції за посиланням git-imap-send[1].

--batch-size=<num>

Деякі поштові сервери (наприклад, smtp.163.com) обмежують кількість електронних листів, що надсилаються за сеанс (зʼєднання), і це призведе до збою під час надсилання великої кількості повідомлень. З цією опцією send-email відключиться після надсилання <num> повідомлень і зачекає кілька секунд (див. --relogin-delay), а потім знову підключиться, щоб обійти таке обмеження. Ви можете використовувати певний помічник з обліковими даними, щоб уникнути необхідності повторно вводити пароль щоразу, коли це трапляється. Стандартно використовується змінна конфігурації sendemail.smtpBatchSize.

--relogin-delay=<int>

Очікування <int> секунд перед повторним підключенням до SMTP-сервера. Використовується разом з опцією --batch-size. Стандартно використовується змінна конфігурації sendemail.smtpReloginDelay.

Автоматизація

--no-to
--no-cc
--no-bcc

Очистити будь-який список адрес To:, Cc:, Bcc:, раніше встановлений через конфігурацію.

--no-identity

Очистити раніше зчитане значення sendemail.identity, встановлене через конфігурацію, якщо таке є.

--to-cmd=<command>

Вкажіть команду, яку потрібно виконати один раз для кожного файлу латки, щоб генерувати записи To:, специфічні для файлу латки. Вивід цієї команди має бути однією адресою електронної пошти на рядок. Стандартно використовується значення конфігурації sendemail.toCmd.

--cc-cmd=<command>

Вкажіть команду, яку потрібно виконати один раз для кожного файлу латки, щоб створити записи Cc:, специфічні для файлу латки. Вивід цієї команди має бути однією адресою електронної пошти на рядок. Стандартно використовується значення конфігурації sendemail.ccCmd.

--header-cmd=<command>

Вкажіть команду, яка виконується один раз для кожного вихідного повідомлення, та виведіть рядки заголовків у стилі RFC 2822, які потрібно вставити в них. Якщо встановлено змінну конфігурації sendemail.headerCmd, її значення завжди використовується. Якщо в командному рядку вказано --header-cmd, її значення має пріоритет над значенням змінної конфігурації sendemail.headerCmd.

--no-header-cmd

Вимкніть будь-яку команду заголовка, що використовується.

--chain-reply-to
--no-chain-reply-to

Якщо це встановлено, кожен електронний лист буде надіслано як відповідь на попередньо надісланий електронний лист. Якщо вимкнено за допомогою --no-chain-reply-to, усі електронні листи після першого будуть надіслані як відповіді на перший надісланий електронний лист. Під час використання цього рекомендується, щоб перший наданий файл був оглядом усієї серії латок. Стандартно вимкнено, але для його ввімкнення можна використовувати змінну конфігурації sendemail.chainReplyTo.

--identity=<identity>

Ідентифікатор конфігурації. Якщо задано, значення в підрозділі sendemail.<identity> матимуть пріоритет над значеннями в розділі sendemail. Стандартним ідентифікатором є значення sendemail.identity.

--signed-off-by-cc
--no-signed-off-by-cc

Якщо це значення встановлено, до списку копій додаються електронні адреси, знайдені в трейлері Signed-off-by або рядках Cc:. Стандартно використовується значення конфігурації sendemail.signedOffByCc; якщо це значення не вказано, використовується — --signed-off-by-cc.

--cc-cover
--no-cc-cover

Якщо це значення встановлено, електронні листи, знайдені в заголовках Cc: у першій латці серії (зазвичай супровідний лист), додаються до списку копій для кожного набору електронних листів. Стандартне значення — це значення конфігурації sendemail.ccCover; якщо воно не вказано, значення — --no-cc-cover.

--to-cover
--no-to-cover

Якщо це значення встановлено, електронні листи, знайдені в заголовках To: у першій латці серії (зазвичай супровідний лист), додаються до списку "Кому" для кожного набору електронних листів. Стандартне значення — це значення конфігурації sendemail.toCover; якщо воно не вказано, значення — --no-to-cover.

--suppress-cc=<category>

Вкажіть додаткову категорію одержувачів, щоб приховати автоматичне надсилання копії:

  • author дозволить уникнути зазначення імені автора латки.

  • self уникатиме вказівки відправника.

  • cc уникатиме включення будь-кого, згаданого в рядках Cc у заголовку латки, окрім self (для цього використовуйте self).

  • bodycc уникне включення будь-кого, згаданого в рядках Cc, до тіла латки (повідомлення коміту), окрім self (для цього використовуйте self).

  • sob уникатиме врахування будь-кого, згаданого в трейлерах Signed-off-by, окрім себе (для цього використовуйте self).

  • misc-by уникатиме включати будь-кого, згаданого в рядках Acked-by, Reviewed-by, Tested-by та інших рядках з "-by" в тілі латки, окрім Signed-off-by (для цього використовуйте sob).

  • cccmd уникне запуску --cc-cmd.

  • body еквівалентно sob + bodycc + misc-by.

  • all придушить усі значення автоматичного копіювання.

Стандартне значення — значення конфігурації sendemail.suppressCc; якщо воно не вказано, використовується — self, якщо вказано — --suppress-from, а також — body, якщо вказано --no-signed-off-cc.

--suppress-from
--no-suppress-from

Якщо це значення встановлено, не додавати адресу From: до списку Cc:. Зазвичай використовується значення конфігурації sendemail.suppressFrom; якщо це значення не вказано, використовується — --no-suppress-from.

--thread
--no-thread

Якщо це встановлено, заголовки In-Reply-To та References будуть додаватися до кожного надісланого електронного листа. Те, чи посилається кожен лист на попередній лист (глибока потоковість згідно з формулюванням git format-patch), чи на перший лист (поверхнева потоковість), визначається --[no-]chain-reply-to.

Якщо вимкнено за допомогою --no-thread, ці заголовки не будуть додані (якщо не вказано за допомогою --in-reply-to). Стандартно використовується значення конфігурації sendemail.thread; якщо воно не вказано, використовується — --thread.

Користувач повинен переконатися, що заголовок In-Reply-To ще не існує, коли git send-email запитується на його додавання (особливо зверніть увагу, що git format-patch можна налаштувати на власне виконання потоків). Невиконання цієї вимоги може не призвести до очікуваного результату в MUA одержувача.

--mailmap
--no-mailmap

Використовуйте файл mailmap (див. gitmailmap[5]), щоб зіставити всі адреси з їхнім канонічним справжнім іменем та адресою електронної пошти. Додаткові дані mailmap, специфічні для git send-email, можна надати за допомогою значень конфігурації sendemail.mailmap.file або sendemail.mailmap.blob. Стандартно — sendemail.mailmap.

Адміністрування

--confirm=<mode>

Підтвердьте безпосередньо перед відправленням:

  • always завжди підтверджуватиме перед надсиланням.

  • never ніколи не підтверджуватиме перед надсиланням.

  • cc підтвердить перед надсиланням, коли send-email автоматично додасть адреси з латки до списку копій.

  • compose підтвердить надсилання першого повідомлення при використанні --compose.

  • auto еквівалентно cc + compose.

Стандартне значення — значення конфігурації sendemail.confirm; якщо воно не вказано, використовується значення auto, якщо не було вказано жодного з параметрів придушення, у такому разі використовується значення compose.

--dry-run

Зробіть усе, крім фактичного надсилання електронних листів.

--format-patch
--no-format-patch

Коли аргумент можна розуміти або як посилання, або як імʼя файлу, виберіть, чи розуміти його як аргумент format-patch (--format-patch), або як імʼя файлу (--no-format-patch). Стандартно, коли виникає такий конфлікт, git send-email завершиться невдачею.

--quiet

Зменшити обсяг виводу команди git send-email. У виводі має бути лише один рядок на кожен лист.

--validate
--no-validate

Виконувати перевірки латок на безпеку. Наразі валідація означає наступне:

  • Викликати гачок sendemail-validate, якщо він є (див. githooks[5]).

  • Попереджати про латки, що містять рядки довжиною понад 998 символів, якщо не використовується відповідне кодування передачі (auto, base64 або quoted-printable); це пов’язано з обмеженнями SMTP, як описано в https://www.ietf.org/rfc/rfc5322.txt.

Стандартне значення — sendemail.validate; якщо це значення не встановлено, використовується значення --validate.

--force

Надсилати електронні листи, навіть якщо цьому забороняють перевірки безпеки.

Інформація

--dump-aliases

Замість звичайної операції, вивести скорочені псевдоніми з налаштованого(их) файлу(ів) псевдонімів, по одному на рядок в алфавітному порядку. Зверніть увагу, що це включає лише псевдонім, а не його розширені адреси електронної пошти. Див. sendemail.aliasesFile для отримання додаткової інформації про псевдоніми.

--translate-aliases

Замість звичайної операції, читати зі стандартного вводу та інтерпретувати кожен рядок як псевдонім електронної пошти. Перетворювати його відповідно до налаштованого(их) файлу(ів) псевдонімів. Виводити кожне перетворене імʼя та адресу електронної пошти у стандартний вивід, по одному на рядок. Див. sendemail.aliasFile для отримання додаткової інформації про псевдоніми.

КОНФІГУРАЦІЯ

Все, що знаходиться нижче цього рядка в цьому розділі, вибірково включено з документації git-config[1]. Вміст такий самий, як і там:

Warning

Missing uk/config/sendemail.adoc

See original version for this content.

ПРИКЛАДИ SMTP-СЕРВЕРІВ

Використання Gmail як SMTP-сервера

Щоб використовувати git send-email для надсилання латок через SMTP-сервер Gmail, відредагуйте ~/.gitconfig, щоб вказати налаштування облікового запису:

[sendemail]
	smtpEncryption = ssl
	smtpServer = smtp.gmail.com
	smtpUser = yourname@gmail.com
	smtpServerPort = 465

Gmail не дозволяє використовувати ваш звичайний пароль для git send-email. Якщо у вашому обліковому записі Gmail налаштовано багатофакторну автентифікацію, ви можете створити пароль для програми, який використовуватиметься з git send-email. Щоб створити його, відвідайте сторінку https://security.google.com/settings/security/apppasswords.

Або ж замість використання пароля для програми ви можете використовувати автентифікацію OAuth2.0 з Gmail. OAuth2.0 безпечніший за паролі для програми та працює незалежно від того, чи налаштовано багатофакторну автентифікацію. OAUTHBEARER та XOAUTH2 — це поширені механізми, що використовуються для цього типу автентифікації. Gmail підтримує обидва. Наприклад, якщо ви хочете використовувати OAUTHBEARER, відредагуйте файл ~/.gitconfig та додайте smtpAuth = OAUTHBEARER до налаштувань облікового запису:

[sendemail]
	smtpEncryption = ssl
	smtpServer = smtp.gmail.com
	smtpUser = yourname@gmail.com
	smtpServerPort = 465
	smtpAuth = OAUTHBEARER

Іншою альтернативою є використання інструменту, розробленого Google, відомого як sendgmail, для надсилання електронних листів за допомогою git send-email.

Використання Microsoft Outlook як SMTP-сервера

На відміну від Gmail, Microsoft Outlook більше не підтримує паролі для окремих програм. Тому для Outlook необхідно використовувати автентифікацію OAuth2.0. Крім того, він підтримує лише механізм автентифікації XOAUTH2.

Відредагуйте ~/.gitconfig, щоб вказати налаштування облікового запису для Outlook та використовувати його SMTP-сервер за допомогою git send-email:

[sendemail]
	smtpEncryption = tls
	smtpServer = smtp.office365.com
	smtpUser = yourname@outlook.com
	smtpServerPort = 587
	smtpAuth = XOAUTH2

НАДСИЛАННЯ ЛАТОК

Як тільки ваші коміти будуть готові до надсилання до списку розсилки, виконайте такі команди:

$ git format-patch --cover-letter -M origin/master -o outgoing/
$ edit outgoing/0000-*
$ git send-email outgoing/*

Під час першого запуску вам буде запропоновано ввести облікові дані. Введіть пароль для програми або звичайний пароль, залежно від обставин.

Якщо у вас налаштовано допоміжний засіб облікових даних (див. git-credential[1]), пароль буде збережено у сховищі облікових даних, тому вам не доведеться вводити його наступного разу.

Якщо ви використовуєте автентифікацію OAuth2.0, вам потрібно буде використовувати токен доступу замість пароля, коли буде запропоновано. Різні генератори токенів OAuth2.0 доступні в Інтернеті. Також доступні помічники з обліковими даними, що підтримуються спільнотою:

  • git-credential-gmail (кросплатформний, спеціалізований помічник для автентифікації облікових записів Gmail)

  • git-credential-outlook (кросплатформний, спеціалізований помічник для автентифікації облікових записів Microsoft Outlook)

  • git-credential-yahoo (кросплатформний, спеціалізований помічник для автентифікації облікових записів Yahoo)

  • git-credential-aol (кросплатформний, спеціалізований помічник для автентифікації облікових записів AOL)

Ви також можете переглянути gitcredentials[7] для отримання додаткових помічників автентифікації на основі OAuth.

Proton Mail не надає SMTP-сервер для надсилання електронних листів. Якщо ви є платним клієнтом Proton Mail, ви можете скористатися Proton Mail Bridge, офіційно наданим Proton Mail, для створення локального SMTP-сервера для надсилання електронних листів. Як для безкоштовних, так і для платних користувачів можна використовувати проекти, що підтримуються спільнотою, такі як git-protonmail.

Примітка: потрібні такі основні модулі Perl, які можуть бути встановлені разом з вашим дистрибутивом Perl:

MIME::Base64, MIME::QuotedPrint, Net::Domain і Net::SMTP.

Також потрібні ці додаткові модулі Perl:

Authen::SASL і Mail::Address.

Використання опції sendmailCmd команди git send-email

Окрім надсилання електронних листів через SMTP-сервер, git send-email також може надсилати електронні листи через будь-яку програму, яка підтримує команди, подібні до sendmail. Ви можете ознайомитися з документацією --sendmail-cmd=<команда> вище для отримання додаткової інформації. Ця можливість може бути дуже корисною, якщо ви хочете використовувати іншу програму як SMTP-клієнт для git send-email, або якщо ваш постачальник послуг електронної пошти використовує власні API замість SMTP для надсилання електронних листів.

Як приклад, розгляньмо, як налаштувати msmtp, популярний SMTP-клієнт, який можна знайти в багатьох дистрибутивах Linux. Відредагуйте ~/.gitconfig, щоб вказати git-send-email використовувати його для надсилання електронних листів.

[sendemail]
	sendmailCmd = /usr/bin/msmtp # Змініть це на шлях, де встановлено msmtp

Посилання на кількох таких помічників, що підтримуються спільнотою, є:

  • msmtp (популярний SMTP-клієнт з багатьма функціями, доступний для Linux та macOS)

  • git-protonmail (кросплатформний клієнт, який може надсилати електронні листи за допомогою API ProtonMail)

  • git-msgraph (кросплатформний клієнт, який може надсилати електронні листи за допомогою Microsoft Graph API)

ДИВ. ТАКОЖ

git-format-patch[1], git-imap-send[1], mbox(5)

GIT

Частина набору git[1]