Git удалять вещи таинственно (редактировать: на самом деле django-хранилища)

Проблема: иногда, но не каждый раз, Git удаляет каталог static репо. Мы не знаем, что это заставляет, но похоже, что это происходит при слиянии веток или иногда даже при проверке ветвей. Он делает это без запроса и ест отслеживаемые файлы.

Фон:

У меня есть (частный) проект, который имеет несколько ветвей, "выпуск", "разработка", несколько линий функций.
Есть два из нас (меня и @stevejalim), работающих на репо. Эта проблема возникает с нами обоими.
Я использую чисто командную строку для моих команд Git; Стив использует смесь командной строки и Git Tower.
Это проект Django с каталогом static. У нас может быть git rm ed каталог static в какой-то момент в прошлом или поместить его в .gitignore, но не в последнее время. И руководитель нашей ветки разработки не имеет static в .gitignore и имеет файлы в static отслежены.
Это случается так редко, что мы не уверены, что это то, что мы делаем, или прерывистая проблема, ошибка с Git или поврежденное дерево
Это может произойти только при объединении другой ветки обратно в develop. Но ветки всегда разветвлены от develop и обратно в develop. Но мы не уверены.
Мы используем git -flow, но проблема возникает при использовании команд не git -flow.
В качестве примеров, когда это может ударить:

1) Стив имел ветку разработки, которая была чистой (никаких изменений в фиксации или стадии) и стабильной. Он вырезал новый релиз с помощью git flow release start|finish и в процессе (возможно, слияние с мастером для разработки), все /static/tree были удалены.

2) Стив восстановил удаление, отменив изменения (по сути, восстановить файл). Но затем Стив просто переключился с мастера обратно на разработку, и /static/dir снова забили (это было с Git Tower)

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

Может ли это быть связано с тем, как мы исправляем zapping/static/dir? Каков наилучший способ перепрограммирования объектов, которые были удалены? Отказ от локальных изменений или жесткий reset для HEAD, похоже, не излечивает. Может ли помочь нам помощь в восстановлении?

ОБНОВЛЕНИЕ Мы просто испытали это снова просто с git add . - без изменений ветвей, без слияния. Это помогает диагностировать вообще?

Вот содержание Steve.git/config:

[core]
   repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
    url = [email protected]:foobarbazbam/bar.git
[branch "master"]
    remote = origin
    merge = refs/heads/master
[gitflow "branch"]
    master = master
    develop = develop
[gitflow "prefix"]
    feature = feature/
    release = release/
    hotfix = hotfix/
    support = support/
    versiontag = 
[difftool "tower"]
    cmd = \"/Applications/Tower.app/Contents/Resources/CompareScripts/kaleidoscope.sh\" \"$LOCAL\" \"$REMOTE\"

Вот содержание .gitignore:

.DS_Store
*.pyc
*.log
*.log.*
*.bak
*~
settings_local.py
/build/
/static_collected/*
/static/uploads/*
/static/theme_files/*
/static/picture/*
pip-log.txt
*.tmproj
*.dot
*.db
*.sublime-project
*.sublime-workspace
/docs/_*

Ответ 1

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

Мы использовали бэкэнд django-storages ( "плагин", чтобы Django мог хранить файлы на Amazon S3 прозрачно). Это испытание называется HashPathStorageTest. Срыв этого теста удаляет settings.MEDIA_ROOT, который был установлен на ./static. Это, по-моему, ошибочно. У него нет деловых бланков - удаление файлов, которые он не создал.

Мы проводили наши тесты, как хорошие граждане, перед регистрацией. В большинстве случаев мы проводили только тесты для нашего кода, но иногда мы запускали тесты для всего проекта (включая сторонние плагины). Это порождало поведение в вопросе. Поскольку мы запускали тестовые и git вещи вместе, было непросто указать, какая команда выполняла удаление (и удаленные файлы показывались только при запуске git status).

Итак, проблема решена. Опять же, извините за то, что вы выбрасываете аферы по доброму имени Git!

Ответ 2

Это будет выглядеть как git, решив слить на ветку, у которой A) удалена папка. B) она думает, что она более поздняя, чем ветка, с которой вы сливаетесь. Может быть, есть машина с американским типом даты и с европейским типом даты? Или какое-либо из ваших испытаний связано с перезагрузкой даты машины?

Я бы

a) проверьте области всех машин, включенных в ваше развитие. б) выберите фиксированную точку в своей разработке, скопируйте файлы и создайте новый реестр и оттуда.

Ответ 3

Хорошо, так что это произошло - я добавлю отдельный ответ, потому что это так глупо. У нас есть ссылка на наши скрипты SQL, а новый разработчик случайно отредактировал .gitignore, чтобы содержать *.sql - не говоря уже о том, что изменения перестали распространяться на этой ветке - и, к счастью, он был пойман до любой значимой потери времени разработки. Однако не исключено, что это может привести к возникновению проблем выше, так что вы проверили свои файлы директив git? Если папка игнорируется (и там есть .gitignore - i.e игнорируется), она может исчезнуть и появиться почти по волшебству.