Здравствуйте, velkin, Вы писали:

V>>>Git создал Линус Торвальдс для ядра Linux. Очевидно и работа заточена под это дело. С каким бы проектом у себя не работал, будешь работать как с ядром Linux.
N>>Это уже много лет не так.
V>Это не может быть не так, то есть то, что другие люди развивают проект никак не влияет на то откуда взялся git и его основные положения.

Я про вторую часть. "Как с ядром" давно неактуально, сейчас значительно больше влияют github, gitlab, политики Git flow (которые существенно отличаются от практик работы с ядром), и так далее.

N>>Это у любой нормальной работы с исходниками (и не обязательно программ).
N>>Например, перетащили текст какого-то юридического параграфа из главы 2 в главу 4. Это одно изменение — перенос.
N>>И не только с исходниками. Ты про транзакции в файловой системе слышал? Windows умеет такое.
V>Есть NTFS, который работает у меня в Debian и Windows. Если имеется в виду вот это Транзакционная NTFS, то нет, я про этот костыль Windows Only первый раз слышу, и он никакого отношения к обсуждению не имеет, как и транзакции. Причём здесь транзакции? Я не знаю.

При том, что точно так же дают атомарную работу с файлами — или весь пакет изменений принят, или не принят.

N>>Тогда зачем вообще привязываться в этой теме к Git?
V>Потому, что эволюция систем хранилища версий файлов и директорий не закончена. Я раньше думал, что же мне не нравится в git, ведь вроде есть децентрализация, а значит автономная работа, слияние и так далее, и вот наконец понял. Git заточен под проекты как абсолютно независимые единицы данных. А чтобы хоть как-то это исправить придумали субмодули и прочее.

Ну а тогда зачем ты говориш о разбиении ещё более дробном — на файлы?

V>Но в итоге получается костыль на костыле и самое главное мало автоматизации, а то и вовсе автоматики. Ведь для чего нужен компьютер и программы, чтобы они выполняли за человека работу. Когда за тебя выполняют работу, то можешь этого не замечать, но когда тебя заставляют выполнять работу, то не заметить это трудно.

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

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

Может, тебе нужно что-то вроде etckeeper? У меня подобная тулза (но древнее) вообще поверх CVS была сделана и по крону запускалась, только отчёты писала с диффами. Вот тебе и автоматика.
А если речь идёт о сознательном действии "я принял решение изменить XXX", то тут никакой автоматики в самом принятии решения нет и не будет.

V>А если мне всё равно, как оно там сохраняется и синхронизируется пока система хранения версий сама записывает коммиты, то так даже лучше. Или если я хочу взять файл курсором мышки и переместить его в другое хранилище (drag&drop) с сохранением его изменений.

А потом ты захотел отменить, потому что решил, что не надо было перетаскивать, и что тогда?
А потом в письмо деловому партнёру случайно попал из клипборда текст с обещанием подружке, как ты её хочешь радовать вечером, тоже хочешь автофиксации? Или когда одному заказчику — подробности другого, с которым первый на ножах?
Лично я против всей подобной автоматики.

V> А если я хочу хранить файл со всеми его изменениями в разных хранилищах одновременно.

И что мешает?

V>Вот и выходит, что эволюция поколений систем хранения версий ещё не закончена.

Она не закончена — факт. Но совсем не по причинам, которые ты тут описываешь.

V>Ну, это просто тема для обсуждения, это не холивар что-то против чего-то и тому подобное.

Так я вот пытаюсь выловить что-то осмысленное из этого обсуждения...

Здравствуйте, Pzz, Вы писали:

Pzz>>>Mercurial совершенно изоморфен git'у. Что у него там данные под капотом немного в другом виде хранятся, это его личное дело.
Pzz>·>Не личное. Некоторые операции манипулирования историей и управлением ветками в таком хранилище становятся неэффективными и практически неюзабельными.
Pzz>Например?
rebase, например. В mercurial старая история будет сохранена в отдельный неюзабельный бэкап-бандл.
Простая фича — fetch pull request ref. В bitbucket осилили сделать только для git.

Pzz>·>Это не функция скв как таковой, а алгоритмов слияния конфликтов. git сам по себе хранит по сути полный снапшот каждого закоммиченного состояния и по умолчанию зовёт встроенные дефолтные тулзы типа diff/patch. Ты можешь на разные типы файлов назначить свои тулзы и парсь/диффь/сливай арифметические выражения как душе угодно.
Pzz>Мне бы хотелось готовый инструмент, а не набор запчастей для сборки своего.
Готовый инструмент для чего? Для автоматического сравнения и слияния _произвольных_ выражений на _произвольном_ ЯП?! Ну хоти дальше.

Pzz>>>Но вряд ли мы этого дождемся.
Pzz>·>Не в этой Вселенной. Потому что это в общем случае алгоритмически неразрешимая задача.
Pzz>Многие алгоритмически неразрешимые задачи имеют практически полезное решения, заключающееся в том, что алгоритм делает все, что может, а в остальных случаях обращается за помощью к человеку.
В git внезапно реализовано практически полезное решение (auto-conflict resolution) и обращение к человеку (manual conflict resolution).

Здравствуйте, Pzz, Вы писали:
Pzz>Но вряд ли мы этого дождемся.
У меня одногруппник в качестве диплома пилит semantic diff. Подкину ему в качестве идеи

Здравствуйте, Sinclair, Вы писали:

Pzz>>Но вряд ли мы этого дождемся.
S>У меня одногруппник в качестве диплома пилит semantic diff. Подкину ему в качестве идеи

Я бы делал это с учетом языка. Т.е., отдельно для C++, отдельно для Go, отдельно для JS и т.п. Выходной формат должен быть одинаковым, независимо от языка, а алгоритм построения diff'а — разным, с фаллбеком на подтрочмый, если ничего не понятно. Всех языков, конечно, не покроешь, но это и не надо.