LINUX.ORG.RU

git после отката не выдает ошибки - это баг?


0

1

Добавляем директорию:

mkdir something
echo "something" > ./something/something.txt

Смотрим что изменилось:

git status
# On branch svntrunk
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       something/
nothing added to commit but untracked files present (use "git add" to track)

Добавляем под контроль:

git add .
git commit -a -m "add something"

Смотрим что изменилось:

# On branch svntrunk
nothing to commit (working directory clean)

Чудесно, папочка добавилась.

Теперь смотрим лог и попытаемся окотиться назад на один коммит: (по айдишнику - из параноидальных соображений)

git reset --hard 7ec3b79f9fea841db24eeb645ce322c475e79af9

И смотрим что изменилось:

# On branch svntrunk
nothing to commit (working directory clean)

Казалось бы, мы только что умертвили папочку с гиперважным файлом something.txt

Однако

ls -al | grep something

drwxr-xr-x  3 olegchir users  4096 Sep  5 08:15 something

Возникают вопросы:

1) Почему при жестком откате не удалилась директория с непустыми файлами?
2) и даже если директория по какой-то мистической причине _должна_ остаться, то почему всего лишь nothing to commit, почему оно не завопило «but untracked files present»?

git-1.7.6-1 из репов арча. Переустановил - та же фигня. Я негодую =)

UPD: Оказывается, оно не удалило директорию, но удалило в ней файл. Тогда понятно, почему nothing to commit, директория пустая, а гит индексирует по контенту. Но почему оно не убило директорию? Котэ продолжает негодовать.

★★★★☆

Последнее исправление: stevejobs (всего исправлений: 1)

Чую, ты не тот id указал.

/tmp/111[master]$ mkdir some
/tmp/111[master]$ echo seme > some/some
/tmp/111[master]$ git st
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	some/
nothing added to commit but untracked files present (use "git add" to track)
/tmp/111[master]$ git add .
/tmp/111[master]$ git st
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	new file:   some/some
#
/tmp/111[master]$ git ci -am 'added some'
[master 0f26fe6] added some
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 some/some
/tmp/111[master]$ git log
/tmp/111[master]$ git log
/tmp/111[master]$ git reset --hard d53069a92c77f9d7ab11ce385733b0dbeb4ba0c5
HEAD is now at d53069a initial import
/tmp/111[master]$ git st
# On branch master
nothing to commit (working directory clean)
/tmp/111[master]$ ll
total 12
drwxr-xr-x  3 bobrov users 4096 Sep  5 13:05 .
drwxrwxrwt 21 root   root  4096 Sep  5 13:03 ..
-rw-r--r--  1 bobrov users    0 Sep  5 13:04 aaa
drwxr-xr-x  8 bobrov users 4096 Sep  5 13:05 .git
/tmp/111[master]$ git --version
git version 1.7.6.1
baverman ★★★
()
Ответ на: комментарий от baverman

кстати, спасибо, ты ведь реально проверил, что у тебя всё работает о_О

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

Тогда ты согласен, что это - баг?

Да, в мане белым по черному описано поведение --reset и объяснить твой сценарий по-другому как-то не выходит.

baverman ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.