2016-07-06 3 views
4

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

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

$ 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 (как это было предложено here), мне было интересно, если есть более удобный способ сделать это.

Вопрос:

Есть ли какая-то reflog для индекса?

ответ

1

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

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

+0

Трудный момент создания - хорошая идея. Благодарю. – LeGEC

+0

Для тестирования я попытался найти все '.git/objects/ab/cdef ...' blobs, возвращенные моим 'fsck -unreachable'. Некоторые из оборванных капель не присутствуют, что, вероятно, означает, что они хранятся в файлах pack. Вы знаете быстрый способ найти файл пакета, к которому принадлежит blob? – LeGEC

+0

Я искал дату изменения файлов. У вас есть еще один трюк, чтобы найти дату изменения блоба? – LeGEC

4

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

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

При работе над чем-то, что занимает больше 5-10 минут, совершить как-вы-гоу (и очистку перед нажатием). В противном случае, stage-as-you-go.

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 является хорошим способом), то этот подход становится почти мгновенно.

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

+0

+1 на рабочем процессе. Кроме того, для нескольких более длительных задач (всего, что может занять больше дня, а иногда даже дольше нескольких часов), создавайте локальные ветви. Ветвь Git почти бесплатна: они занимают немного места на диске, но я считаю, что их самый дорогой ресурс - это мое собственное пространство на голове («hm, у меня есть« эксперимент1 »через« эксперимент45 », отлично, теперь *, что, черт возьми, я экспериментировал с *?) ... – torek

+0

@torek вне темы - но когда выйдет ваша книга git? :-) –

+0

@ Alok-- У меня есть работа на полный рабочий день, и работа над ней остановилась, увы! – torek

 Смежные вопросы

  • Нет связанных вопросов^_^