Должен ли Git когда-либо думать, что файл, полученный при извлечении, теперь не отслеживается?

У одного из наших разработчиков постоянно возникают проблемы с его репозиториями Git. Он вытаскивает, а затем «git status» показывает весь список неотслеживаемых файлов (то есть Git считает их новыми), которые на самом деле были получены из его последнего извлечения. На самом деле вы можете вернуться к его журналу git и указать конкретный коммит, который их добавил, и это в его истории. Однако, если вы перейдете к одному из не отслеживаемых файлов и сделаете для него журнал git, истории вообще не будет.

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

Он использует msysgit 1.7.6 и Tortoise Git 1.7.3. Некоторое время мы использовали eGit с myEclipse, и он неоднократно давал сбой, поэтому все первые проблемы были виноваты в этом. Я не думаю, что кто-то больше его использует, поэтому я не чувствую, что могу больше винить eGit.

Мне нужна помощь гуру Git по Stack Overflow! Что может быть причиной этого? Есть ли какие-то обстоятельства, при которых это было бы нормально?

По запросу, вот файл .git / config для репозитория, который был поврежден:

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true
    symlinks = false
    ignorecase = true
    hideDotFiles = dotGitOnly
[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
    url = G:\\DotcomB
    puttykeyfile = 
[branch "master"]
    remote = origin
    merge = refs/heads/master
[user]
    name = jsmith
    email = [email protected]

git egit msysgit tortoisegit
person John Munsch    schedule 04.10.2011    source источник
comment
Не могли бы вы предоставить дополнительную информацию? Что находится в пользовательском файле .git / config в папке проекта? Вы знаете, какие команды Git выполняются (чаще всего используются git pull или git pull origin master). Другой пользователь в группе воспроизвел точные шаги с разными результатами? Есть ли один каталог .git в папке проекта и никаких других подпапок?   -  person Dan Cruz    schedule 05.10.2011
comment
Это какая-то проблема, в которой случай почему-то другой, как в stackoverflow.com/questions/52950/? (каково значение git config core.ignorecase? По умолчанию оно должно быть истинным, но если оно ложно ... это могло бы это объяснить.   -  person VonC    schedule 05.10.2011
comment
Кроме того, вы использовали git log -- untracked_file для проверки журнала?   -  person manojlds    schedule 05.10.2011
comment
Если предположить, что git log untracked_file и git log - untracked file - это одно и то же, тогда да. Вот как мы заметили странное несоответствие. Журнал git для всего перечисленного проекта коммиты, которые включали файлы (те, которые изначально добавляли их в файлы локально), и все же журналы git для отдельных файлов, которые, по его мнению, не отслеживаются, вообще не имеют истории. Так что это похоже на болезнь Альцгеймера о том, откуда они пришли.   -  person John Munsch    schedule 05.10.2011
comment
@John: Это не совсем то же самое, но если у вас в настоящее время есть неотслеживаемый файл foo, и раньше был файл foo, отслеживаемый git, то я считаю, что оба должны делать то же самое. Что касается ответа на ваш вопрос, я думаю, вам нужно будет предоставить более подробную информацию, например, точную последовательность событий и / или некоторый фактический вывод журнала и состояния.   -  person Ryan Stewart    schedule 05.10.2011

Ответы (2)


arrow_upward
2
arrow_downward

Посмотрите, была ли изменена переменная среды git-dir. Аналогично переменной рабочего дерева. Также посмотрите, действительно ли вы находитесь в том же каталоге, что и думаете. Вы используете tortoisegit, и это может быть другой каталог, на который вы смотрите, по сравнению с командной строкой.

Кроме того, когда вы CD к файлу, чтобы увидеть, есть ли он там, убедитесь, что вы завершили имена каталогов табуляцией, так как msysgit с радостью обрабатывает файл / каталог независимо от того, какой у него корпус. Однако Git заботится.

mydir/somefile

можно добраться по

cd MYDIR

и путь будет отражать это.

Теперь git status покажет, что есть файл, который не отслеживается, потому что git будет рассматривать mydir/somefile как нечто иное, чем MYDIR/somefile. Иногда это трудно увидеть, потому что все, что нужно, - это разница на один регистр во всем пути к файлу, чтобы получить такое поведение.

Пока что придерживайтесь командной строки, чтобы решить эту проблему. Перепрыгивание между tortoisegit и командной строкой не могло помочь ситуации.

Можете ли вы запустить новый репозиторий и посмотреть, можно ли его воспроизвести только в командной строке?

Надеюсь это поможет,

Адам

person Adam Dymitruk    schedule 05.10.2011
comment
Я полностью согласен с вами относительно установки этого параметра по умолчанию. Мои коллеги страдают ... - person cJ Zougloub; 05.10.2011
comment
Я определенно вижу, как это приведет к тому, что он подумает, что файлы, полученные с помощью извлечения, изменились, даже если они не были затронуты, но действительно ли это заставит Git думать, что файлы были новыми и неотслеживаемыми? Он все равно должен знать, что файл был там раньше и откуда он появился. - person John Munsch; 05.10.2011
comment
Я не могу понять, как это отвечает на вопрос ОП в его ситуации. Где вообще untracked фигурирует в этой картине? Где в этот ответ вообще не вписывается отображение файла в журнале? - person manojlds; 05.10.2011
comment
Изменил ответ и добавил еще несколько идей и проблем, с которыми я столкнулся. дайте нам знать, как это происходит. - person Adam Dymitruk; 05.10.2011

arrow_upward
0
arrow_downward

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

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

person John Munsch    schedule 16.08.2012