Як знайти хеш гілки в Git?

Враховуючи ім’я локальної / віддаленої гілки, як я можу отримати хеш коміту, на який вказує ця гілка?

Команда git rev-parse- це ваш друг, наприклад:

$ git rev-parse development
17f2303133734f4b9a9aacfe52209e04ec11aff4

... або для гілки віддаленого відстеження:

$ git rev-parse origin/master
da1ec1472c108f52d4256049fe1f674af69e785d

Ця команда, як правило, дуже корисна, оскільки вона може проаналізувати будь-який із способів вказівки назв гілок git, таких як:

git rev-parse master~3
git rev-parse HEAD@{2.days.ago}

... тощо

Хеші зберігаються у .git/refs/, наприклад,.git/refs/heads/master

Але використовуйте програмно, git rev-parseяк запропонував Марк Лонгайр, оскільки це безпечніше.

Не забувайте, що починаючи з Git 2.19 (Q2 2018), Git готує перехід від хешів SHA1 до SHA2: див. " Чому Git не використовує більш сучасний SHA? "

З Git 2.25 (Q1 2020) git rev-parseрозвивається та відображає можливий новий хеш.

Див здійснювати fa26d5e , здійснювати cf02be8 , здійснюють 38ee26b , здійснюють 37ab8eb , здійснюють 0370b35 , здійснюють 0253e12 , здійснюють 45e2ef2 , здійснюють 79b0edc , здійснюють 840624f , здійснюють 32a6707 , здійснюють 440bf91 , здійснюють 0b408ca , здійснюють 2eabd38 (28 окт 2019), а також здійснювати 1bcef51 , здійснюють ecde49b (05 жовтня 2019), Брайан М. Карлсон ( bk2204) .
^{(Об’єднано Хуніо С Хамано - gitster- у коміті 28014c1, 10 листопада 2019)}

rev-parse: додати --show-object-formatопцію

^{Підписав: Брайан М. Карлсон}

Додайте опцію для друку формату об’єкта, що використовується для введення, виведення чи зберігання.
Це дозволяє сценаріям оболонки виявити алгоритм хешування, що використовується.

Оскільки план переходу дозволяє використовувати декілька алгоритмів введення, задокументуйте, що ми можемо надати кілька результатів для введення, і формат, який можуть мати результати.
Хоча ми зараз цього не підтримуємо, раннє документування означає, що автори сценаріїв можуть перевірити свої сценарії в майбутньому, коли ми це зробимо.

git rev-parseДокументація тепер включає в себе:

--show-object-format[=(storage|input|output)]:

Показати формат об’єкта (алгоритм хешування), який використовується для сховища для зберігання всередині .gitкаталогу, вводу чи виводу. Для введення можуть бути надруковані кілька алгоритмів, розділених пробілом. Якщо не вказано, типовим значенням є "сховище".

За допомогою Git 2.29 (Q4 2020) ви можете переконатися, який формат ви повинні використовувати для читання хеш-коміту гілки (або будь-якого іншого об'єкта).

Див здійснювати e023ff0 , здійснювати 4feb562 , здійснює 8a06d56 , здійснює c49fe07 , здійснює 02a32db , здійснюють ceaa4b3 , здійснює eff45da , здійснює b5b46d7 , здійснює c5aecfc , здійснює e74b606 , здійснює 439d3a1 , здійснює 6c2adf8 , здійснює de5737c , здійснює e0a646e , здійснює 6ff6a67 , здійснює 831279d , зробити b6e5005 , коміт 287bb3a , коміт 22f1824 , коміт db00af9 ,здійснюють 7187eb1 , здійснюють 98de0b2 , здійснює a5587b8 , здійснює 66b6d43 , здійснює 2197f87 , здійснює c0b65ea , здійснює d62607d , здійснює d482c23 , здійснюють 866be6e , здійснюють 4bacb6d , здійснює 252a4ee , здійснює 368f3cb , здійснює abe3db1 , здійснює 08fbc5d , здійснює 11b6961 , здійснює 9e3bd8a , здійснює d827bce , здійсни 094a685 (29 липня 2020 р.) Брайан М. Карлсон ( bk2204) .
Подивитисяздійснити 800e6a7 (29 липня 2020 р.) Йоганнесом Шінделіном ( dscho) .
^{(Об’єднано Junio ​​C Hamano - gitster- у комітеті e0ad957 , 11 серпня 2020)}

docs: додати документацію для extensions.objectFormat

^{Підписав: Брайан М. carlson
Відгук: Ерік Саншайн}

Документуйте extensions.objectFormatналаштування конфігурації.
Попередити користувачів не змінювати його самостійно.

git configтепер включає в свою довідкову сторінку :

extensions.objectFormat

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

Допустимими значеннями є sha1> sha256.
Якщо не вказано, sha1передбачається.
Помилковим є вказівка ​​цього ключа, якщо core.repositoryFormatVersionне 1.

Зверніть увагу, що цей параметр повинен встановлюватися лише за допомогою git initабо git clone.
Спроба змінити його після ініціалізації не буде працювати, і це призведе до важких для діагностики проблем.

Щоб бути зрозумілим, завдяки Git 2.29 (Q4 2020) нещодавнє додавання підтримки SHA-256 позначено як експериментальне в документації.

Див. Коміт ff233d8 (16 серпня 2020 р.) Мартіна Агрена ( none) .
^{(Об’єднано Junio ​​C Hamano - gitster- у комітеті d1ff741 , 24 серпня 2020)}

Documentation: позначити --object-format=sha256як експериментальний

^{Підписав: Мартін Егрен}

Після eff45daab8 (" repository: включити підтримку SHA-256 за замовчуванням", 2020-07-29, Git v2.29.0 - злиття, перелічене в пакеті №6 ), ванільні збірки Git дозволяють користувачеві запускати, наприклад,

git init --object-format=sha256  

і зламати.
Це може бути хорошим способом набути досвіду у світі SHA-256, наприклад, знайти такі помилки

GIT_TEST_DEFAULT_HASH=sha256 make test  

не помічає.

Але це насправді окремий світ: такі репозиторії SHA-256 житимуть повністю окремо від (на сьогодні досить великого) набору репозиторіїв SHA-1.
Взаємодія через кордон можлива в принципі, наприклад, через " diff+ apply" (або " format-patch+ am"), але навіть це має свої обмеження: Застосування різниці SHA-256 у репозиторії SHA-1 працює в простому випадку, але якщо ви потрібно вдатися -3, тобі не пощастило.

Подібним чином, " push+ pull" має спрацьовувати, але ви дійсно будете працювати переважно компенсовано від решти світу. Це може бути нормально до моменту ініціалізації вашого сховища, і це може бути нормально протягом декількох місяців після цього, але може настати день, коли ви починаєте шкодувати про використання [git init --object-format = sha256 ](https://github.com/git/git/blob/ff233d8dda12657a90d378f2b403bc6c85838c59/Documentation/git-init.txt#L52)<sup>([man](https://git-scm.com/docs/git-init#Documentation/git-init.txt---object-formatltformatgt))</sup>і мати покопався в досить глибокій норі.

На даний момент у польоті є теми для документування наших форматів даних та протоколів щодо SHA-256, а в деяких випадках (midx та commit-graph) ми розглядаємо можливість коригування того, як формати файлів вказують, який формат об’єкта використовувати.

Де б --object-formatне було згадано в нашій документації, давайте чітко пояснити, що використання його з "sha256" є експериментальним.
Якщо згодом нам потрібно пояснити, чому ми не можемо обробляти дані, які ми створили ще в 2020 році, ми завжди можемо вказати на цей абзац, який ми додаємо сюди.

"Включаючи ::" - додаючи невелику розмивку, ми повинні мати змогу бути послідовними у всій документації і в кінцевому підсумку можемо поступово зменшувати суворість цього тексту.
Одного разу ми можемо навіть використовувати його, щоб почати поступово відмовлятися --object-format=sha1, але давайте не будемо випереджати себе ...

Є також extensions.objectFormat, але це згадується лише тричі. Двічі ми додаємо цю нову відмову від відповідальності, а в третьому місці ми вже маємо попередження "не редагувати". Звідти зацікавлені читачі зрештою повинні знайти цей новий, який ми додаємо сюди.

Оскільки GIT_DEFAULT_HASHце ще одна точка входу в цю функціональність, задокументуйте і експериментальний характер цієї функції.

gitтепер включає в свою довідкову сторінку :

використовується замість цього. За замовчуванням "sha1". ЦЯ ЗМІННА ЕКСПЕРИМЕНТАЛЬНА! Дивіться --object-formatв git init.

object-format-disclaimerтепер включає в свою довідкову сторінку :

ЦЕ ВАРІАНТ ЕКСПЕРИМЕНТАЛЬНИЙ!
Підтримка SHA-256 є експериментальною і все ще на ранній стадії.

Репозиторій SHA-256 загалом не зможе ділитися роботою зі "звичайними" сховищами SHA-1.
Слід припустити, що, наприклад, внутрішні формати файлів Git стосовно репозиторіїв SHA-256 можуть змінюватися назад-несумісними способами.
Використовуйте лише --object-format=sha256для тестування.

Той самий Git 2.29 (Q4 2020) переконується, що " git clone" ^{( людина )} буде працювати, коли хтось клонує зі сховища SHA-1, тоді як GIT_DEFAULT_HASHуже встановлено використання SHA-256.
До 2.29 це призвело до непридатного сховища, яке наполовину стверджує, що це сховище SHA-256 із об'єктами SHA-1 та посиланнями.
Це виправлено.

Див. Коміт 47ac970 (20 вересня 2020 р.) Брайана М. Карлсон ( bk2204) .
^{(Об’єднано Junio ​​C Hamano - gitster- у комітеті b28919c , 29 вересня 2020 р.)}

builtin/clone: уникати невдач за допомогою GIT_DEFAULT_HASH

^{Повідомляє: Матеус Таварес
Підписав: Брайан М. Карлсон}

Якщо користувач клонує сховище SHA-1 із GIT_DEFAULT_HASHвстановленим значенням " sha256", ми можемо отримати сховище, де формат формату сховища дорівнює 0, але для extensions.objectformatключа встановлено значення " sha256".
Це як неправильно (у користувача є сховище SHA-1), так і нефункціональне (оскільки розширення не можна використовувати у сховищі v0).

Це відбувається тому, що в клоні ми спочатку налаштовуємо сховище, а потім змінюємо його алгоритм, виходячи з того, що віддалена сторона каже нам, що воно використовує.
Спочатку ми налаштували сховище як SHA-256 у цьому випадку, а потім пізніше скинули версію сховища, не очищаючи розширення.

Ми могли б завжди встановити розширення в цьому випадку, але це означало б, що наші сховища SHA-1 не були сумісні зі старими версіями Git, хоча немає жодної причини, чому вони не повинні бути.
І ми також не хочемо ініціалізувати сховище як SHA-1 спочатку, оскільки це означає, що якщо ми клонуємо порожнє сховище, ми не зможемо виконати GIT_DEFAULT_HASHзмінну і в кінцевому підсумку отримаємо сховище SHA-1, а не сховище SHA-256.

Жодне з них не є привабливим, тому давайте повідомлятимемо код ініціалізації сховища, якщо ми робимо подібне перевстановлення, і якщо так, очищаємо розширення, якщо ми використовуємо SHA-1.
Це гарантує, що ми створимо дійсне та функціональне сховище та не порушимо жодного з інших випадків використання.