можно настроить дополнительные фичи, типа закрыть ветку
И как будет выглядеть закрытая ветка гита в моей локальной репе? И чему соответствовать в удаленной?
git mv file1 file2 — что не так?
Строго по документации: работает в точности как добавление файла на новом месте и удаление в старом. Никакого перемещения на уровне истории не добавляет.
В других VCS необходимости нет точно так же: удаление и добавление файлов поддерживается везде.
Зато есть возможность указать правильное переименование/перемещение (определив его в том числе автодетектом) и сохранить в истории.
Гит же вынужден гадать всегда: у него в истории такой информации нет.
Для систем контроля версий — подграф взаимосвязанных коммитов, которому можно дать имя. Это вполне соответствует веткам для математического дерева или даже обычного живого дерева.
И только в гите ветка — это всего лишь именованный мутабельный указатель на коммит и не более.
Что значит закрыть ветку? В гите это просто указатель на коммит.
Самая обычная вещь: я не хочу больше изменять ветку (и видеть ее как опцию для соответствующих команд), но хочу, чтобы коммиты по-прежнему ей принадлежали. Так обычно поступают с ветками для закрытых задач. В гите ее приходится удалять, а принадлежность коммитов маркировать другими средствами.
Это не проблема гита.
Это проблема гита. Перемещение и переименование для всех есть, а для гита нет. Его приходится угадывать с помощью костылей с переменным успехом. Забавно смотреть, как меняется видимая история файла, в зависимости от настройки чувствительности поиска. Обычно приходится разбивать коммит с перемещениями-переименованиями на два — в одном менять содержимое файлов, в другом перемещать-переименовывать.
Гит хранит историю состояний рабочего каталога. Есть хоть одна ФС, которая хранит, откуда скопирован файл?
Этот вопрос нерелевантен проблеме и отсылает к ФС, которая в контроль версий не умеет от слова совсем.
А в системе контроля версий обычно полезно знать, из какой ветки взят коммит, выполненный командой cherry pick. В гите для этого есть возможность указать в сообщении хеш оригинального коммита. Но сам гит про это ничего не знает, нигде не хранит и никак не показывает, в отличие, например, от меркуриала.
Если надо разделить не последний коммит, то добавляется пара команд из консоли.
Я не против консоли для редких вариантов использования, а также случаев, когда GUI недоступен.
Но в рамках принятого текущим работодателем процесса разделение коммита (не последнего) — вариант типовой.
Победил не гит, а гитхаб.
А вместе с гитхабом я использую меркуриал, подключаясь с помощью расширения hg-git
К сожалению, все косяки дизайна гита так не исправить.
SmartGit как "существенно более продуманный" аналог TortoiseHg — очень хорошая шутка.
Платный, тормозной, некостистентный, с древним дизайном, с кучей неотключаемых модальных окон — это все SmartGit, и smart в его названии — явный сарказм. Если кто подскажет gui-клиент, умеющий в split commit, то я с удовольствием выкину smartGit и забуду как страшный сон.
Веб-разработчик, десктоп и качественнее? Фантастика на втором этаже. Никогда не любил десктоп на яве. Но десктоп на электроне — это уже из серии «и тут снизу постучали». Он объединяет недостатки как веба (никакущая виртуализация, огромное потребление ресурсов, тормоза), так и классики (необходимости установки, зависимость от окружения, безопасность).
И если я сам найду и определю все зависимости — мне уже не нужен Autofac, вот в чем проблема.
Нет такой проблемы.
То, что надо реализовать определяется не контейнером, а постановкой задачи.
То, что надо выставить как зависимости — это НЕ список всех зависимостей в контейнере, это список только тех из них, которые не разрешаются внутри самого контейнера.
Список таких зависимостей также определяется при постановке задачи — проектируя модуль, вы решаете, что он НЕ должен обеспечивать сам.
Если уровнем выше использовать композитный модуль, то он сможет определить неразрешенные зависимости подмодулей автоматически и выставить их как свои — тут контейнер действительно может быть лишним.
За связи, невидимые снаружи модуля, контейнер отвечает по-прежнему и нужен внутри модуля именно с
этой целью.
Простой для реализации модуль, конечно же, проще сделать без контейнера.
В случае использования модуля, снаружи у вас может быть один контейнер, внутри другой, но оба они друг о друге ничего не знают и никак друг от друга не зависят.
Ваш исходный тезис содержал посылку про якобы имеющееся дублирование работы Autofac.
Это очевидно неверно «снаружи».
Под капотом Autofac тоже ничего подобного не делает, по крайней мере на момент моего копания в его исходниках.
В нем нет выделенной функциональности построения графа зависимостей. Нет и анализа с целью определения исчерпывающего списка неразрешаемого в рамках имеющихся регистраций.
Autofac только пытается разрешать зависимости на лету, неразрешаемое он специально не ищет.
Нет никакой необходимости разрешать зависимости до тех пор, пока не начата инициализация модулей.
Список неразрешенных зависимостей для графа модулей необходимо построить заранее: это позволяет разрешить их за счет ядра или заявить как зависимости композитного модуля.
Autofac ничего из этого не умеет, превращая разрешение зависимостей в игру "Сапер" периода выполнения без индикации числа соседних мин.
Очевидно, что внутри Autofac есть код который эти зависимости определяет
Очевидно, что никакого списка зависимостей для дексриптора модуля Autofac создать не может, следовательно ваш тезис из цитаты ниже неверен.
Вот только чтобы сделать модуль из контейнера — вам нужно сначала вручную сформировать для него дескриптор, для чего нужно найти все зависимости. То есть сделать ту работу, которую обычно неявно делает Autofac…
Он их определяет, только не собирает в один список.
Этого он тоже не делает.
Максимум, что умеет Autofac: при попытке разрешения найти первую неразрешаемую зависимость или цикл, после чего выкинуть исключение или вернуть false для TryResolve().
Эта работа годится только для минимальной индикации ошибок конфигурации контейнера.
Для задач модульности это и слишком поздно, и слишком мало.
Так определяется непрозрачность и нерекурсивность контейнеров:
Граф зависимостей неявный
Автоматическое определение зависимостей работает для типов, но не для контейнеров.
До попытки разрешения не работает практически ничего.
С моей библиотекой можно построить явный граф зависимостей, определить циклы и неразрешенные зависимости еще до инициализации самих модулей.
Отсюда и велосипедостроение: я, к сожалению, не видел ни одной библиотеки, которая умела бы это из коробки.
То есть сделать ту работу, которую обычно неявно делает Autofac…
Autofac, как и другие DI-контейнеры, эту работу вообще не делает ни явно, ни неявно. Нет метода, который вернул бы исчерпывающий список неразрешенных зависимостей. Только рантайм, только хардкор, только при попытке резолва из заранее сконфигурированного контейнера.
Фреймворк определяет структуру проекта.
Интерфейс же не мешает как реализовать модуль средствами на свой выбор, так и встроить реализованное в уже имеющийся проект.
Пример: двусторонняя интеграция с Autofac, можно как сделать модуль из контейнера, так и зарегистрировать модуль в вышестоящем контейнере github.com/Kirill-Maurin/FluentHelium/blob/master/FluentHelium.Autofac/AutofacModuleExtensions.cs
Кажется что ваш интерфейс IModule нарушает ваше же требование ортогональности
Интерфейс — не нарушает.
Ортогональность соблюдена — и внутри, и снаружи модуля может быть что угодно, в отличие от требований фреймворков.
От COM взяли только базовые интерфейсы с GUID и счетчиками ссылок: Delphi в них умеет из коробки.
Реестр и прочее ActiveX барахло не использовалось.
Согласно трекеру, такой функциональности в SourceTree нет
jira.atlassian.com/browse/SRCTREE-3036
И как будет выглядеть закрытая ветка гита в моей локальной репе? И чему соответствовать в удаленной?
Строго по документации: работает в точности как добавление файла на новом месте и удаление в старом. Никакого перемещения на уровне истории не добавляет.
Зато есть возможность указать правильное переименование/перемещение (определив его в том числе автодетектом) и сохранить в истории.
Гит же вынужден гадать всегда: у него в истории такой информации нет.
Для систем контроля версий — подграф взаимосвязанных коммитов, которому можно дать имя. Это вполне соответствует веткам для математического дерева или даже обычного живого дерева.
И только в гите ветка — это всего лишь именованный мутабельный указатель на коммит и не более.
Самая обычная вещь: я не хочу больше изменять ветку (и видеть ее как опцию для соответствующих команд), но хочу, чтобы коммиты по-прежнему ей принадлежали. Так обычно поступают с ветками для закрытых задач. В гите ее приходится удалять, а принадлежность коммитов маркировать другими средствами.
Это проблема гита. Перемещение и переименование для всех есть, а для гита нет. Его приходится угадывать с помощью костылей с переменным успехом. Забавно смотреть, как меняется видимая история файла, в зависимости от настройки чувствительности поиска. Обычно приходится разбивать коммит с перемещениями-переименованиями на два — в одном менять содержимое файлов, в другом перемещать-переименовывать.
Этот вопрос нерелевантен проблеме и отсылает к ФС, которая в контроль версий не умеет от слова совсем.
А в системе контроля версий обычно полезно знать, из какой ветки взят коммит, выполненный командой cherry pick. В гите для этого есть возможность указать в сообщении хеш оригинального коммита. Но сам гит про это ничего не знает, нигде не хранит и никак не показывает, в отличие, например, от меркуриала.
Я инструкцию читал с самого начала, но ряд косяков так и остались косяками:
Это все я делал, по объективным результатам и субъективным ощущениям — худший сорт того же самого.
Я не против консоли для редких вариантов использования, а также случаев, когда GUI недоступен.
Но в рамках принятого текущим работодателем процесса разделение коммита (не последнего) — вариант типовой.
Победил не гит, а гитхаб.
А вместе с гитхабом я использую меркуриал, подключаясь с помощью расширения hg-git
К сожалению, все косяки дизайна гита так не исправить.
SmartGit как "существенно более продуманный" аналог TortoiseHg — очень хорошая шутка.
Платный, тормозной, некостистентный, с древним дизайном, с кучей неотключаемых модальных окон — это все SmartGit, и smart в его названии — явный сарказм. Если кто подскажет gui-клиент, умеющий в split commit, то я с удовольствием выкину smartGit и забуду как страшный сон.
Нет такой проблемы.
этой целью.
Это очевидно неверно «снаружи».
Под капотом Autofac тоже ничего подобного не делает, по крайней мере на момент моего копания в его исходниках.
В нем нет выделенной функциональности построения графа зависимостей. Нет и анализа с целью определения исчерпывающего списка неразрешаемого в рамках имеющихся регистраций.
Autofac только пытается разрешать зависимости на лету, неразрешаемое он специально не ищет.
Autofac ничего из этого не умеет, превращая разрешение зависимостей в игру "Сапер" периода выполнения без индикации числа соседних мин.
Очевидно, что никакого списка зависимостей для дексриптора модуля Autofac создать не может, следовательно ваш тезис из цитаты ниже неверен.
Дубль, просьба удалить
Этого он тоже не делает.
Максимум, что умеет Autofac: при попытке разрешения найти первую неразрешаемую зависимость или цикл, после чего выкинуть исключение или вернуть false для TryResolve().
Эта работа годится только для минимальной индикации ошибок конфигурации контейнера.
Для задач модульности это и слишком поздно, и слишком мало.
Так определяется непрозрачность и нерекурсивность контейнеров:
С моей библиотекой можно построить явный граф зависимостей, определить циклы и неразрешенные зависимости еще до инициализации самих модулей.
Отсюда и велосипедостроение: я, к сожалению, не видел ни одной библиотеки, которая умела бы это из коробки.
Autofac, как и другие DI-контейнеры, эту работу вообще не делает ни явно, ни неявно. Нет метода, который вернул бы исчерпывающий список неразрешенных зависимостей. Только рантайм, только хардкор, только при попытке резолва из заранее сконфигурированного контейнера.
Интерфейс же не мешает как реализовать модуль средствами на свой выбор, так и встроить реализованное в уже имеющийся проект.
Пример: двусторонняя интеграция с Autofac, можно как сделать модуль из контейнера, так и зарегистрировать модуль в вышестоящем контейнере
github.com/Kirill-Maurin/FluentHelium/blob/master/FluentHelium.Autofac/AutofacModuleExtensions.cs
Интерфейс — не нарушает.
Ортогональность соблюдена — и внутри, и снаружи модуля может быть что угодно, в отличие от требований фреймворков.
От COM взяли только базовые интерфейсы с GUID и счетчиками ссылок: Delphi в них умеет из коробки.
Реестр и прочее ActiveX барахло не использовалось.