Имеет ли коммит git log pickup (show) связанный только с какой-либо веткой или тегом?

Question

При запуске git log --graph --oneline я вижу только коммиты (и там родительские коммиты, и там родительские коммиты и так далее), которые связаны с какой-то веткой (локальной и исходной) или тегом.

То есть, если я переустанавливаю ветку на предыдущий коммит и делаю новый коммит, создается новая строка истории.Теперь, если я объединю новую строку локальной истории с источником, я вижу, что старая строка истории больше не отображается на графике (если только не был помечен старый совет по истории).

Даже запросы к журналам всего репо, похоже, не помогают git log --graph --oneline -all

Так что, интересно, зафиксированы ли в git log / graph pickups (показывает) какие-либо ветви или теги?Может ли кто-нибудь подтвердить или исправить.

Редактировать - следующий ответ от RomainValeri

Из git docs:

git-log - Показать журналы коммитов

и из фактического наблюдения, а также ответа от - RomainValeri

git log --graph --oneline --all

выводит все ветви / тегиисторий

Таким образом, есть ли способ просмотреть журнал каждого коммита (включая висячие коммиты, то есть те, которые не связаны ни с одной веткой / тегом), либо с помощью git log, либо любой другой альтернативной команды / инструмента.

Answer 1

Это немного неясно, но после вашего обновления кажется, что ваш главный вопрос:

Так есть ли способ просмотреть журнал каждого коммита (включая висячие коммиты, т.е. те, которые не связаны с каким-либоответвление / тег) либо с помощью git log, либо с помощью любой другой альтернативной команды / инструмента.

Краткий (и все еще в основном точный) ответ: не совсем.

Если у вас зафиксирован фиксированный коммит (т. Е. HEAD отсоединен и отклонен от всех ссылок), вы можете увидеть эту историю.Вы можете просмотреть историю из reflogs (локальная запись о том, где ветки вашего репо и HEAD указывали в прошлом), чтобы увидеть историю, которая может быть недоступна ни из каких текущих ссылок.И есть другие подобные исключения.Вы могли бы даже дать git конкретный идентификатор коммита, чтобы увидеть историю, ведущую к этому коммиту.

Но так или иначе вы должны указать git log, с чего начать его обход;он не предназначен для поиска висячих коммитов и начала прогулки там.

Прежде чем я последую этому выводу до конца - и причина, по которой "на самом деле" не только в основном правильная - я 'Я хотел бы отметить, что если у вас есть коммит, который не может быть достигнут --all, то это вопрос времени, когда gc вытащит ковер из-под этого коммита - потому что, насколько он может судить, такойкоммиты не используются.Большинство команд git делают то же самое, что делает журнал: что полезные коммиты доступны из ссылок (веток, тегов и т. Д.), Поэтому даже если вы отключили gc, чтобы избежать удаления таких коммитов (не очень хорошая идея), вы быпо-прежнему пытайтесь убедить git работать с ними навсегда.

Поэтому единственный разумный совет - не заводите привычку работать в автономном состоянии головы при создании кода, который вы хотите сохранить;и если вы пишете новые изменения, которые хотите сохранить, а затем понимаете, что находитесь в отстраненной голове, создайте ветку.

Но для технически более полного ответа я отмечу, чтоУ git есть одна команда, чья работа равна , чтобы найти оборванные коммиты.Вы можете использовать git fsck, чтобы найти недоступные объекты (при условии, что они еще не были очищены gc), а затем передать полученные значения идентификатора SHA в log.Возможно, вы даже сможете настроить скрипт для этого.

Answer 2

Боюсь, это немного нелепо, так как сам вопрос немного не сфокусирован.Вы начали с git log и забрели на git gc территорию.: -)

Git имеет видимых ссылок, таких как HEAD, имена ветвей и имена тегов.Но у Git также есть менее видимые ссылки, такие как reflogs, и невидимые ссылки.Последнее особенно сложно:

• На мгновение игнорируя git worktree add, давайте посмотрим на невидимые ссылки.Это записи в индексе!Они относятся непосредственно к объектам BLOB-объектов (только), но поддерживают эти объекты в git gc целях.

• Теперь давайте добавим git worktree add.Когда вы добавляете рабочее дерево, добавленное рабочее дерево получает свой собственный индекс, свой собственный HEAD и свой собственный набор специальных ссылок для конкретного рабочего дерева (ORIG_HEAD, git bisect refs и т. Д.),Команды git gc и git fsck должны проверять все эти ссылки.В Git 2.5, когда git worktree впервые появился, они этого не сделали!Это осталось незафиксированным до Git 2.15.Результатом этого стало то, что при запуске git gc он мог отбрасывать данные, используемые в некоторых из добавленных рабочих деревьев: объекты, хранящиеся только в индексе добавленного рабочего дерева, или фиксации, достижимые только из отсоединенного добавленного рабочего дерева.HEAD, были пропущены и могут быть GCed после истечения срока действия чернослива (по умолчанию = 14 дней).

Вы можете git log пройти рефлоги с помощью -g, или вы можете иметьэто пройти все нормальные ссылки с --all.Однако флаг --all просматривает только ссылки этого рабочего дерева, относящиеся к рабочему дереву.Между тем git fsck и git gc должны просматривать все ссылки, в том числе reflogs и невидимые ссылки и ссылки на дерево работ.Если у вас Git между 2.5 и 2.15, это не работает, так что остерегайтесь слишком долго использовать добавленные рабочие деревья.(Я был укушен этой конкретной ошибкой сам. К счастью, в добавленном рабочем дереве не было ничего важного.)

Упражнение (обнаруживаемое без просмотра источника): refs/stash для каждого рабочего дерева илиГлобальный?(Я сам не знаю ответа.)

Answer 3

Да, по умолчанию для этого требуется HEAD, но вы можете указать его в любой ссылке:

git log --graph --oneline
# outputs history backwards from HEAD

git log --graph --oneline branch-1
# outputs only branch-1 history

git log --graph --oneline --all
# outputs all branch histories

Для ответа на ваш комментарий ниже: для случая --all это не означает, чтопринимает все коммиты, но все реф.Таким образом, все refs/ dir будут исследованы (и HEAD также)

---

Редактировать после новой области:

Чтобы найти потерянные (висячие) коммиты, используйте fsck

git fsck --lost-found

---

Наконец, чтобы связать их, вы можете вкладывать команды.

git log --graph --oneline $(git fsck --lost-found | sed -E 's/dangling (tree|commit|blob|tag) //')

Answer 4

есть ли способ просмотреть журнал каждого коммита (включая висячие коммиты, т.е. те, которые не связаны с какой-либо веткой / тегом)

Обычно добавления --reflog к вашей команде достаточночтобы увидеть каждый коммит, который вы сделали или отменили за последний месяц или около того, независимо от того, есть ли он в какой-либо текущей истории.

Можно генерировать и отменить коммиты, не делая записей reflog, но сложнее представить, почемувы бы охотились за этим.Способ найти все подсказки-призраки, которые --reflogs не достижим, потому что они были заброшены давно или были сгенерированы доморощенными рабочими процессами / скриптами, которые думают, что им не нужны никакие вонючие reflogs,

git fsck --connectivity-only --unreachable --no-dangling