Есть ли журнал ссылок для индекса?

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

Некоторые примеры случаев:

$ git add <file>
# find out that I already had an indexed version of <file>,
# and that for some reason I shouldn't have added the extra modifications

$ git stash pop
# find out afterwards that I have a mix of "the index I had"
# and "the index in the stash"

$ git stash
# with an active index, which is now mixed with the state of the working tree

$ git reset <typo>
# accidentally resetting the wrong file, or the whole directory

Можно прибегнуть к копанию через git fsck --full --unreachable --no-reflog (как было предложено -a-git-reset">здесь), мне было интересно, есть ли более удобный способ сделать это.

Вопрос:

Есть ли какой-то рефлог для индекса?


person LeGEC    schedule 06.07.2016    source источник


Ответы (2)


Журнал ссылок содержит записи для ссылок, а не для индекса.

Но, возможно, ответом здесь является настройка рабочего процесса ... (это было для меня).

Если вы работаете над чем-то, что займет более 5–10 минут, фиксируйте по мере выполнения (и выполняйте очистку перед отправкой). В противном случае используйте показ по мере продвижения.

index великолепен... Я использую его весь день! Но на самом деле я использую его только в том случае, если знаю, что буду совершать коммит всего через минуту или две (по сути, это атомарная операция рабочего процесса). Это потому, что я боюсь, что сделаю какую-нибудь глупость и снесу свой индекс.

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

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

Это дает огромное преимущество в виде создания маленьких хлебных крошек в моем журнале ссылок, если это необходимо.

Вот мой рабочий процесс:

# start work
git checkout -b featurea
# work
vim file.txt
# reach a little milestone
git commit -a -m "working on feature..."
# work some more
vim file.txt
# reach another little milestone
git commit -a --reuse-message=HEAD --amend
# work some more
vim file.txt
# another little milestone...
git commit -a --reuse-message=HEAD --amend
# finishing touches...
vim file.txt
# ok, done now, put everything back in working dir so I can review
git reset HEAD~
# decide what goes in this commit
# perhaps use `git add -p`
git add file.txt
# give a nice commit message (use editor)
git commit
# now merge to master and push with confidence!

Может показаться, что вам приходится много печатать, но если вы научитесь летать на оболочке (хорошим способом будет воспользоваться преимуществами set -o emacs или set -o vi), то этот подход станет практически мгновенным.

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

person Jonathan.Brink    schedule 06.07.2016
comment
+1 за рабочий процесс. Кроме того, для несколько более длительных задач (все, что может занять больше дня, а иногда даже больше, чем несколько часов), создайте локальные ветки. Ветки Git почти бесплатны: они занимают немного места на диске, но я считаю, что их самый дорогой ресурс — это мое собственное свободное пространство (хм, у меня есть от experiment1 до experiment45, отлично, теперь какого черта я экспериментировал?)... - person torek; 06.07.2016
comment
@torek не по теме, но когда выйдет твоя книга о git? :-) - person Alok--; 07.07.2016
comment
@Alok-- Я получил работу на полную ставку, и работа на ней остановилась, увы! - person torek; 07.07.2016
comment
@torek спасибо за сообщение! Могу помочь с мелкими деталями, если нужно :-) - person Alok--; 07.07.2016

Нет, для индекса нет reflog. вам придется работать, как вы поняли, с git fsck с флагом --lost-found или без него в команде.

Вы можете использовать метку времени файлов (SHA-1), чтобы «сортировать» файлы по дате создания и иметь базовый журнал ссылок на основе времени создания файла.

person CodeWizard    schedule 06.07.2016
comment
Ради тестирования я попытался найти все .git/objects/ab/cdef... большие двоичные объекты, возвращенные моим fsck --unreachable. Некоторых висячих блобов там нет, что, вероятно, означает, что они хранятся в пакетных файлах. Знаете ли вы, как быстро найти пакетный файл, которому принадлежит большой двоичный объект? - person LeGEC; 07.07.2016
comment
Я искал дату модификации файлов. Есть ли у вас какой-нибудь другой трюк, чтобы найти дату модификации BLOB-объекта? - person LeGEC; 07.07.2016