Конкретный файл продолжает удаляться из git

Мы используем azure devops с репозиториями git. Репозиторий git нашего основного продукта в последнее время ведет себя странно. Примерно через три недели конкретный файл (проекта) в репозитории отсутствует после проверки веток на основе конкретной ветки разработки. Когда я смотрю на репозиторий, файл действительно присутствует в репозитории.

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

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

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

Я уже запускал git fsck, и он возвращает только некоторые висящие объекты

Кто-нибудь знает, что здесь происходит?

Обновлять: У нас это случилось снова. git ls-files перечисляет только 25 файлов в агенте с проблемой. При запуске той же команды в локальном репо она возвращает список, который кажется полным списком файлов репо. Интересно, что файл, который продолжает исчезать, ЯВЛЯЕТСЯ одним из 25 файлов, перечисленных в агенте. При переходе на другую ветку файл появляется снова. Я дважды проверил, и файл НЕ удаляется в ветке, в которой он не отображается. Более того, при переключении с ветки слияния обратно на исходную ветку и повторном переключении на ветку слияния файл НЕ исчезает. Есть предположения?

Примечание: удаление файла . Совершение этого, повторное добавление файла и удаление пробела, а также фиксация этого -> снова исправлено (возможно, временно)

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

torek 23.12.2020 18:06

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

PaulVrugt 24.12.2020 09:42

Чтобы проверить (напрямую), какие файлы находятся в индексной/промежуточной области, используйте git ls-files (обратите внимание, что это предназначено для скриптов, это неудобная команда). Например, сравните «хорошую» систему или кассу с плохой.

torek 24.12.2020 15:35

Как только это произойдет снова, я расследую и обновлю вопрос. Спасибо за информацию

PaulVrugt 04.01.2021 09:55

Я обновил вопрос с подробностями после запуска git ls-files

PaulVrugt 12.01.2021 11:55

Каков результат git show-ref?

Edward Thomson 12.01.2021 14:45

Он показывает длинный список доступных ветвей. Только две ветки существуют локально, а все остальные ветки являются удаленными ветками.

PaulVrugt 12.01.2021 14:56

Я думаю, мой вопрос: есть ли у вас имена веток, которые отличаются только регистром? Чтобы не просить вас вставить список веток, чего вы (разумно) не хотите делать, эта команда сообщит вам, есть ли у вас конфликтующие имена веток: git show-ref --head | tr A-Z a-z | awk '{print $2}' | sort | uniq -c | awk '{$1=$1;print}' | grep -v '^1 '

Edward Thomson 12.01.2021 15:44

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

PaulVrugt 12.01.2021 19:27
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
9
97
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Вы не предоставили нам достаточно информации, чтобы с уверенностью определить проблему, но эта деталь:

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

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

Запустите эту команду в git bash (заменив filename фактическое имя файла проекта):

git ls-files --stage | grep -i filename

Я подозреваю, что вы увидите более одной записи в списке, например:

100644 a5675676e903973a412f7aaa0a07ad45f586c02b 0   filename
100644 db0cc477c38714c4ee77b0bf462a7b7156a066a2 0   FileName

Это произошло потому, что git хранит имена файлов с учетом регистра, в то время как Windows хранит файлы без учета регистра (но с сохранением регистра). Либо кто-то на платформе, которая также чувствительна к регистру, добавил файл с похожим именем (отличается только регистром), либо кто-то по ошибке изменил значение core.ignoreCase, ошибочно полагая, что это параметр конфигурации (это не так, это это кешированная информация о локальной файловой системе, и ее изменение вызовет подобные проблемы).

Чтобы исправить это, запустите git rm --cached для разных имен файлов, затем запустите git add для правильного имени файла. Например:

git rm --cached filename
git rm --cached FileName
git add filename

И используйте git log, чтобы определить, кто из ваших коллег по ошибке изменил свою конфигурацию git, и убедитесь, что они не сделают этого снова.

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

PaulVrugt 12.01.2021 12:49

честь там, где должна быть честь, сегодня мы обнаружили, что на самом деле БЫЛА проблема с корпусом, но гораздо дальше по пути к файлу. Мы исправляем корпус, и, надеюсь, проблема не останется в стороне.

PaulVrugt 22.02.2021 12:31

Другие вопросы по теме