Управление обработкой символических ссылок в eGit - PullRequest
7 голосов
/ 22 июля 2010

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

Я считаю, что инструмент командной строки git ведет себя так, как я хочу: git add -A. Однако если я попытаюсь использовать версию git eGip для Eclipse, чтобы добавить все неверсированные файлы, используя Team->Track в контекстном меню проекта, eGit захочет добавить каждый файл в каталоги с символическими ссылками. Есть ли способ сказать eGit, что нет, это действительно символические ссылки, и на них нельзя ссылаться?

Ответы [ 2 ]

4 голосов
/ 19 октября 2011

Мы пострадали от этой проблемы, загромождая экран фиксации без конца, и иногда заставляя кого-то забыть включить созданный ими файл.

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

/ ProjectHomeFolder / .gitignore

Поскольку мы работали в Play Framework, мы также отредактировали следующие игнорируемые объекты: / ProjectHomeFolder/conf/.gitignore
/ProjectHomeFolder/public/.gitignore

Мы просто добавили / ModuleName для каждого из модулей, которые были связаны символами, и теперь egit игнорирует их должным образом, для полноты здесь полныйсодержимое моего корневого файла .gitignore, который находится в корневом каталоге проекта:

/. project
/.classpath
/.gitignore
/ eclipse
/ tmp
/ crud
/.git
/.settings
/ modules
/ conf
/betterlogs-1.0
/chronostamp-0.1
/logisimayml-1.5
/betterlogs-1.0
/sass-1.1
/deadbolt-1.4.2
/jquery-1.0
/log4play-0.5
/messages-1.1.1
/navigation-0.1
/jqueryui-1.0
/scaffold-0.1
/table-1.2
/tabularasa-0.2

4 голосов
/ 23 сентября 2011

Наша проблема обсуждалась в следующем: Eclipse Community Forums Thread

Похоже, что в настоящее время поддержку Linux lstat не так просто сделать переносимой. Парадигма Наименьший общий знаменатель , которую они имеют для программирования Eclipse на Java, усложняет создание нативных вещей для Linux или Mac. (читай: * кашель * Windows не поддерживает символические ссылки * кашель *).

Хорошая новость:

Это кажется возможным, но им нужно было бы закодировать его так, чтобы оно соответствовало их стандартам программирования Write Once Test Everywhere . Мне кажется, что при использовании EGit важно иметь некоторую встроенную поддержку stat и lstat в Linux из-за этой проблемы, а также Eclipse bug # 346079 .

Простая установка EGit приводит к замедлению работы и зависанию IDE при обновлении Git: - (

Плохие новости:

Эти две ошибки мешают мне использовать EGit для большинства моих команд git. Пользовательский опыт делает EGit непригодным для использования для меня. Было бы очень приятно иметь возможность использовать EGit в Eclipse, чтобы истории пользователей и задачи Mylyn могли быть автоматически привязаны к ветвям объектов. Также было бы замечательно иметь функции шаблона сообщения автоматической фиксации. Это сделало бы создание текущей задачи и статуса в сообщении фиксации быстрым.

Это вызывает у меня почти достаточно того, что я готов посмотреть, можно ли создать несколько сценариев для запроса Eclipse / Mylyn для вывода шаблона сообщения текущего коммита и выполнить коммит git из командной строки используя это. Однако я не уверен, как будет работать автоматическое создание ветки для каждой пользовательской истории.

Пока эти проблемы не будут устранены, я уверен, что многие пользователи EGit не будут счастливы: - (

...