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

N>У Git(*) нет проблем с пробелами в именах. Как и у подавляющего большинства юниксовых средств, где эта проблема давно отработана на всех уровнях.

Это не так. В линухе тоже натыкался. Опять же говорю не про передачу в качестве параметра имени файла с пробелами, а про запуск различных программ/скриптов из каталога с пробелами в имени. Вот помнится тот же autotools от этого корёжило. )

N>Проблема пробелов в именах существует (нежданчик, да?) в Windows, которая эти самые имена с пробелами использует значительно шире (начиная с знаменитой PROGRA~1, ой, простите, "Program Files"). Вызвана она тем, что:

Что-то не помню проблем с современным виндовым софтом. )

N>3. Посредники вроде cmd.exe ещё больше усложняют ситуацию.
N>Передать в sh аргумент в вызываемую команду без репарсинга тривиально — "$x" вместо $x. Передать исходный набор аргументов — "$@". Аналога для Windows не вижу, или он настолько прочно спрятан внутрь, что не гуглится.

%* если ты говоришь про bat файлы) И для их запуска не требуется вызывать cmd руками (так же как и в линухе не обязательно руками писать sh).

N>Реально, я сталкивался со средствами, которые просто отказывались ставиться в Program Files и требовали для себя пути без пробелов. Видимо, их авторы задолбались.

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

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

_>>Откуда он будет одинаковым то? ))) Ну вот покажи мне git log --graph из первого и из второго репозитория для подобного простейшего случая (инициализация, потом по одной параллельной ревизии в каждом репозитории, потом слияние), про который тут говорил (где в Mercurial обходятся вообще только анонимными ветками). Могу показать пример такого графа для Mercurial. )
·>А почему оно будет разным-то?

Ну так ты тут обошёлся только одной веткой и всё. ) Для реальной работы команды такое естественно не пойдёт. ) Это же уже обсуждалось выше.

··>Как видишь — графы после синхронизации идентичны. Единственная разница — наличие в other веток с префиксом origin/, т.к. я other репозиторий клонировал. Если бы тоже создал новый через init, то remote-а и его веток не было бы.

О том и речь)

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

_>>>Откуда он будет одинаковым то? ))) Ну вот покажи мне git log --graph из первого и из второго репозитория для подобного простейшего случая (инициализация, потом по одной параллельной ревизии в каждом репозитории, потом слияние), про который тут говорил (где в Mercurial обходятся вообще только анонимными ветками). Могу показать пример такого графа для Mercurial. )
_>·>А почему оно будет разным-то?
_>Ну так ты тут обошёлся только одной веткой и всё. ) Для реальной работы команды такое естественно не пойдёт. ) Это же уже обсуждалось выше.
На уровне команд я вообще без веток обошелся. Но они использовались неявно, в репозиториях они есть.
Я не понимаю какой ты сценарий тогда хочешь, если будет 10 other репозиториев — ничего принципиально не поменяется.

_>··>Как видишь — графы после синхронизации идентичны. Единственная разница — наличие в other веток с префиксом origin/, т.к. я other репозиторий клонировал. Если бы тоже создал новый через init, то remote-а и его веток не было бы.
_>О том и речь)
О чём речь?

Здравствуйте, Ночной Смотрящий, Вы писали:

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

Я бы даже углубил эту мысль на собственном опыте. Лет ... назад гит был коряв и ужасен, особенно под виндой, Hg же вполне себе удобоварим. И в этот момент вылезает на сцену ГитХаб и начинает хостит 146% нового кода. Волей не волей ежей заставили кушать, а две столь похожие системы держать в голове влом. Теперь оно конечно обкаталось, но осадочек до сих пор остался.

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

_>>>Ну формально то как раз можешь, но это бред. Для таких целей теги есть)
_>·>Чем теги от букмарок отличаются?
_>Закладки — это указатель, который автоматически скачет на следующую ревизию при фиксации. А тег никуда не скачет, но зато может просто редактироваться пользователем.
А tip это тег, который скачет как закладка? тегладка (tagmark)? Всё чудесатее и чудесатее.

_>>>Если ты имеешь в виду момент последней ревизии, то к нему останется только одна ветка, в которую сольются предыдущие. )
_>·>Какой ещё момент? Пусть тебе на read only CD дали hg репо, граф которого я изобразил и попросили посчитать и перечислить ветки. Это так сложно?
_>Ну так я тебе уже ответил только что. )
Ты ответил, что их четыре. Теперь одна. И ты так и не объяснил по какому принципу ты выбрал эти четыре и как оно согласуется с определением в документации.

_>>>·>Да, когда шлёшь что-то другому репозиторию — надо создать имя. Иначе тому другому может пушить кто-то ещё и получится жуткий бардак.
_>>>Ну т.е. чтобы создать отросток в одну ревизию с неким альтернативным вариантом кода,
_>·>А если не отросток? Не diverged т.е.?
_>Не понял, не отросток, а что тогда? )
"the middle of a development line, not necessarily at a diverging point"

_>>> мне надо будет придумывать по новому имени ветки каждый раз, правильно? )
_>·>uuid используй или хеш какой-нибудь, если думать лень.
_>Да, очень удобно. ))) Как раз принцип Оккама в действие. )))
Если тебе и правда нужен такой сценарий, то напишешь альяс:
git config alias.craZyexPerIment "!git branch experimental/`git rev-parse HEAD`"
Всё. После этого
git craZyexPerIment
будет создавать бранчи со случайным именем.
Их потом можно всех вывести командой "git branch --list experimental/*" , тоже можно заальясить.
Т.е. при желании это реализуется в несколько строчек конфига. И нет этого в стандартной поставке гита потому что это нафиг никому не сдалось, слава Оккаму, что этот анонимный бред отрезали. Такой инструмент — не удобен. Он может быть удобен только в том случае, когда ничего более удобного нет. А в гите есть куча более адекватных инструментов.

_>>> И я не смогу например объединить все подобные отростки под одним именем (как можно в том же Mercurial)?
_>·>Для чего под одним именем объединять-то? Чтобы всех запутать?
_>Почему запутать? Как раз удобно все эксперименты держать под одним именем experimental)
Будет у тебя 20 экспериментов... и как их различать-то?

_>>>А он может показать разницу между stash и рабочим каталогом? )
_>·>git diff stash@{13}
_>·>неожиданно, правда?
_>Это разве покажет не разницу с последней ревизией? )
Нет, именно с working copy.
Можно и с любой ревизией сравнить. Могу даже подсказать синтаксис если ты скажешь, что ты понимаешь под последней ревизией. А вообще, читай доки, там всё написано: https://git-scm.com/docs/git-diff

Так как в hg сравнить стеш с рабочим каталогом? Какой extension для этого нужно включить?

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

_>>>Ну и как эта опция поможет мне применить на винде ревизию (созданную в линухе) с двумя файлами отличающимися только регистром? )
_>·>Пофиксить ревизию можно хотя бы, избавившись от одного из файлов.
_>Ага, под линухом. А как мне исправить ситуацию из под винды? )
В отличие от hg, который грохнется уже при попытке запуллить changeset с такой ревизией, git спокойно всё сделает, но будет указывать, что один из файлов изменён (т.к. контент обоих файлов из репо будет записан в один и тот же файл на диске), сразу после чекаута. А потом — как обычно, удалить ненужное, закоммитить.

_>·>Сколько себя не помню, официальный "Git for Windows" всегда ставился в "Program Files" или "Program Files (x86)" — проблем не наблюдал.
_>Это вот этот https://habrahabr.ru/post/255443/ вот, да? )))
Ы?

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

_>>·>Пофиксить ревизию можно хотя бы, избавившись от одного из файлов.
_>>Ага, под линухом. А как мне исправить ситуацию из под винды? )
·>В отличие от hg, который грохнется уже при попытке запуллить changeset с такой ревизией, git спокойно всё сделает, но будет указывать, что один из файлов изменён (т.к. контент обоих файлов из репо будет записан в один и тот же файл на диске), сразу после чекаута.

Т.е. он даже не предупредит пользователя о проблеме и тот будет бегать по форумам в поисках ответа почему у него файл сам меняется магическим образом? ))) Как мило... )))

Что касается Mercurial, то естественно синхронизируется всё вообще без проблем (т.к. формат хранилища никак не зависит от файловой системы). А вот при попытке исполнения hg update ты получишь такое сообщение: "abort: case-folding collision between a.txt and A.txt". Всё информативно, понятно и удобно.

·>А потом — как обычно, удалить ненужное, закоммитить.

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

Да, в Mercurial кстати есть ещё и расширения для автоматического исправления таких вещей. Хотя на мой взгляд это уже перебор)))

_>>·>Сколько себя не помню, официальный "Git for Windows" всегда ставился в "Program Files" или "Program Files (x86)" — проблем не наблюдал.
_>>Это вот этот https://habrahabr.ru/post/255443/ вот, да? )))
·>Ы?

Прочитал статью? ) Там в каждом разделе можно найти по шедевру удобства использования Git под виндой. )))

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

_>>>·>Пофиксить ревизию можно хотя бы, избавившись от одного из файлов.
_>>>Ага, под линухом. А как мне исправить ситуацию из под винды? )
_>·>В отличие от hg, который грохнется уже при попытке запуллить changeset с такой ревизией, git спокойно всё сделает, но будет указывать, что один из файлов изменён (т.к. контент обоих файлов из репо будет записан в один и тот же файл на диске), сразу после чекаута.
_>Т.е. он даже не предупредит пользователя о проблеме и тот будет бегать по форумам в поисках ответа почему у него файл сам меняется магическим образом? ))) Как мило... )))
Честно говоря не знаю как оно выглядит. Винды под рукой сейчас нет...

_>Что касается Mercurial, то естественно синхронизируется всё вообще без проблем (т.к. формат хранилища никак не зависит от файловой системы). А вот при попытке исполнения hg update ты получишь такое сообщение: "abort: case-folding collision between a.txt and A.txt". Всё информативно, понятно и удобно.
А что делать-то?

_>·>А потом — как обычно, удалить ненужное, закоммитить.
_>Ну так а можно подробности, каким собственно образом это будет реализовываться? )
git rm или git mv.

_> И да, терять содержимое обоих файлов в следующей ревизии естественно нельзя... )
Так история же иммутабельная, как можно потерять что-то закоммиченное...

_>>>Это вот этот https://habrahabr.ru/post/255443/ вот, да? )))
_>·>Ы?
_>Прочитал статью? ) Там в каждом разделе можно найти по шедевру удобства использования Git под виндой. )))
"В поставке гит нет rsync и староватый perl, а ещё кофе не варит".
А в поставке hg какой версии rsync?
Дальше читать лениво. Давай конкретно.

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

_>>Ну так ты тут обошёлся только одной веткой и всё. ) Для реальной работы команды такое естественно не пойдёт. ) Это же уже обсуждалось выше.
·>На уровне команд я вообще без веток обошелся. Но они использовались неявно, в репозиториях они есть.
·>Я не понимаю какой ты сценарий тогда хочешь, если будет 10 other репозиториев — ничего принципиально не поменяется.

Да, это я чуть спутал. Это я с netch80 обсуждал, а не с тобой, насчёт минимального режима по 2 ветки на репозиторий для Git'a. )

_>>··>Как видишь — графы после синхронизации идентичны. Единственная разница — наличие в other веток с префиксом origin/, т.к. я other репозиторий клонировал. Если бы тоже создал новый через init, то remote-а и его веток не было бы.
_>>О том и речь)
·>О чём речь?

Ну смотри. Вот допустим у нас кто-то сделал не одну ревизию относительно init, а две, причём параллельные (для этого в git придётся ещё одну ветку завести, да?). А теперь он хочет сделать слияние одной из этих ревизий с чужими результатами (как в изначальном сценарии). Теперь представь себе как будет выглядеть весь процесс в каждом из двух случаев (ревизия_алт1 или ревизия_алт2) и насколько будут похожими после этого выглядеть репозитории участников.

Да, кстати, а в Mercurial не только итоговые графы будут одинаковые, но и сам процесс синхронизации/слияния не будет отличаться для этих двух параллельных ревизий. А в Git?)))

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

_>>Т.е. он даже не предупредит пользователя о проблеме и тот будет бегать по форумам в поисках ответа почему у него файл сам меняется магическим образом? ))) Как мило... )))
·>Честно говоря не знаю как оно выглядит. Винды под рукой сейчас нет...

Ты же сам только что написал "git спокойно всё сделает". ) Да и народ тут как раз писал об этом как об известной причине таинственных багов. )))

_>>·>А потом — как обычно, удалить ненужное, закоммитить.
_>>Ну так а можно подробности, каким собственно образом это будет реализовываться? )
·>git rm или git mv.

Это ты просто помечаешь файл как удалённый, а не решаешь проблему.

_>> И да, терять содержимое обоих файлов в следующей ревизии естественно нельзя... )
·>Так история же иммутабельная, как можно потерять что-то закоммиченное...

Я имею в виду, что если у тебя в кривой линуксовой ревизии были файлы a.txt и A.txt, то после исправления на винде у тебя в ревизии очевидно должно быть что-то вроде a.txt (с содержимым a.txt, а не некой рандомной хренью, создаваемой git'ом) и a1.txt (с содержимым А.txt), а не просто отсутствие файла A.txt.

_>>>>Это вот этот https://habrahabr.ru/post/255443/ вот, да? )))
_>>·>Ы?
_>>Прочитал статью? ) Там в каждом разделе можно найти по шедевру удобства использования Git под виндой. )))
·>"В поставке гит нет rsync и староватый perl, а ещё кофе не варит".
·>А в поставке hg какой версии rsync?
·>Дальше читать лениво. Давай конкретно.

Если кратко, то под винду существует множество реализаций Git'а и при этом каждая убога по своему. ))) Да, а последний раздел (про 64-ёх битный вариант) я вообще без смеха читать не мог. )))

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

_>>·>Чем теги от букмарок отличаются?
_>>Закладки — это указатель, который автоматически скачет на следующую ревизию при фиксации. А тег никуда не скачет, но зато может просто редактироваться пользователем.
·>А tip это тег, который скачет как закладка? тегладка (tagmark)? Всё чудесатее и чудесатее.

Ну да, типа того. ) По идее tip было бы логично реализовать как закладку, но изначально их в Mercurial просто не было. )))

_>>Ну так я тебе уже ответил только что. )
·>Ты ответил, что их четыре. Теперь одна. И ты так и не объяснил по какому принципу ты выбрал эти четыре и как оно согласуется с определением в документации.

Я же тебе уже отвечал и не один раз. Утомило уже. Последняя попытка... В разные периоды жизни существовали разные ветки. Они же не фиксированные навсегда сущности, а могут появляться и пропадать через разделения/слияния. Соответственно на момент последней ревизии у тебя в репозитории одна ветка. А вот за всю историю их там было больше. )

_>>·>А если не отросток? Не diverged т.е.?
_>>Не понял, не отросток, а что тогда? )
·>"the middle of a development line, not necessarily at a diverging point"

И? ) Что это должно было означать? )

_>>Да, очень удобно. ))) Как раз принцип Оккама в действие. )))
·>Если тебе и правда нужен такой сценарий, то напишешь альяс:
·>git config alias.craZyexPerIment "!git branch experimental/`git rev-parse HEAD`"
·>Всё. После этого
·>git craZyexPerIment
·>будет создавать бранчи со случайным именем.
·>Их потом можно всех вывести командой "git branch --list experimental/*" , тоже можно заальясить.
·>Т.е. при желании это реализуется в несколько строчек конфига. И нет этого в стандартной поставке гита потому что это нафиг никому не сдалось, слава Оккаму, что этот анонимный бред отрезали. Такой инструмент — не удобен. Он может быть удобен только в том случае, когда ничего более удобного нет. А в гите есть куча более адекватных инструментов.

Например? )

_>>·>Для чего под одним именем объединять-то? Чтобы всех запутать?
_>>Почему запутать? Как раз удобно все эксперименты держать под одним именем experimental)
·>Будет у тебя 20 экспериментов... и как их различать-то?

Вообще то у каждого есть подробное описание в комментарии к ревизии. )))

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


W>>Это значит иметь возможность сделать чекаут коммита HEAD-N и получить возможность осмотреться внутри репозитория годичной давности. Какие ветки были, кто куда коммитил и все такое.
C>А зачем?

Затем чтобы посмотреть чем занималась команда в наследство от которой достался проект. Или команда пока ты был в отпуске.
Хуки ф топку. Должно работать из каробки. Элементарные вещи же.

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

N>У Git(*) нет проблем с пробелами в именах. Как и у подавляющего большинства юниксовых средств, где эта проблема давно отработана на всех уровнях.

N>Проблема пробелов в именах существует (нежданчик, да?) в Windows, которая эти самые имена с пробелами использует значительно шире (начиная с знаменитой PROGRA~1, ой, простите, "Program Files"). Вызвана она тем, что:

N>1.
N>2.
N>бла-бла-бла

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

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


W>>·>В каком случае ты столкнёшься с этим неудобством? Опиши сценарий.
W>>Кейсы когда надо git reflog не знаешь?
·>reflog обычно нужен для того, чтобы посмотреть какие действия и когда делал, типа "какую ветку я вчера утром смотрел?". И, иногда, откатиться к предыдущим состояниям после того, как понял, что сделал что-то не так, типа "хотел смержить ту ветку, а смержил эту", или "ну и накой я удалил тот коммит?!".

Не только. Бывалоча отматаешь бошку ветки на Nкоммитов назад и растишь оттуда. А потом хочешь этот отросток отловить чтобы черрипикнуть оттуда.
Чем кроме рефлога это делать?

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

W>>Но гит это первая система при встрече с которой я начал читать эти книги чтобы заставить это работать

N>Значит, не сложилось. Соболезную. Видимо, коллега Средняя Точка был прав, что у Hg тяжкое наследие centralized VCS, но я этого не прочувствовал.

Если бы не сложилось только у меня то еще ладно.
Просто гит кривой и неудобный. С кучей рудиментов и 100500 вариантами сделать одно и то же действие. Ни один из которых неудобен

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

C>>А зачем?
W>Затем чтобы посмотреть чем занималась команда в наследство от которой достался проект. Или команда пока ты был в отпуске.
Ну так и смотри по общей истории веток. Элементарная вещь же, и работает изкаропки.

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


C>Ну так и смотри по общей истории веток. Элементарная вещь же, и работает изкаропки.

Двумя сообщениями выше была ссылка почему эта элементарная казалось бы вещь в гите плохо работает.

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

_>·>На уровне команд я вообще без веток обошелся. Но они использовались неявно, в репозиториях они есть.
_>·>Я не понимаю какой ты сценарий тогда хочешь, если будет 10 other репозиториев — ничего принципиально не поменяется.
_>Да, это я чуть спутал. Это я с netch80 обсуждал, а не с тобой, насчёт минимального режима по 2 ветки на репозиторий для Git'a. )
Минимальный режим — одна ветка. Если ты регулярно синхронизируешься с одним и тем же репозиторием, то имеет смысл (но не обязательно, просто задалбывает каждый раз урл вбивать) добавить его URL как remote, что _автоматически_ создаст удалённые ветки (ветки с префиксом remote/) для отслеживания состояния удалённого репо и состояния синхронизации с ним.

_>>>··>Как видишь — графы после синхронизации идентичны. Единственная разница — наличие в other веток с префиксом origin/, т.к. я other репозиторий клонировал. Если бы тоже создал новый через init, то remote-а и его веток не было бы.
_>>>О том и речь)
_>·>О чём речь?
_>Ну смотри. Вот допустим у нас кто-то сделал не одну ревизию относительно init, а две, причём параллельные (для этого в git придётся ещё одну ветку завести, да?).
Можно не заводить, но тогда эту ревизию будет сложнее найти потом (только неявно, как в hg, читая коммит-сообщения и т.п.) и она может собраться GC через месяц (если хочется, можно увеличить время или вообще отключить).

_>А теперь он хочет сделать слияние одной из этих ревизий с чужими результатами (как в изначальном сценарии). Теперь представь себе как будет выглядеть весь процесс в каждом из двух случаев (ревизия_алт1 или ревизия_алт2)
Да ровно так же. Бранчевание локальное или бранчевание между разыми клонами репов — не отличается вообще никак.

_>и насколько будут похожими после этого выглядеть репозитории участников.
После синхронизации — репы будут идентичны.

_>Да, кстати, а в Mercurial не только итоговые графы будут одинаковые
По дефолту не будут из-за разных номеров ревизий. Или эти номера можно отключить?

_>, но и сам процесс синхронизации/слияния не будет отличаться для этих двух параллельных ревизий. А в Git?)))
Не понимаю на что ты намекаешь. А что будет в git по-твоему?
Короче, я уже перестал понимать что конкретно ты хочешь. Скачай гит, обыграй некий сценарий, сравни его с hg и покажи результаты исследований здесь что там плохо, и мы посмотрим, можно ли улучшить.

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

_>>>Т.е. он даже не предупредит пользователя о проблеме и тот будет бегать по форумам в поисках ответа почему у него файл сам меняется магическим образом? ))) Как мило... )))
_>·>Честно говоря не знаю как оно выглядит. Винды под рукой сейчас нет...
_>Ты же сам только что написал "git спокойно всё сделает". ) Да и народ тут как раз писал об этом как об известной причине таинственных багов. )))
Я не знаю как git реагирует, попробую когда-нибудь на досуге, самому интересно. Но не удивлюсь, что это выглядит не очень понятно по сравнению с hg. Как я понял, в git это никогда не было проблемой. Раньше в hg это было критическим багом. Ранние версии hg просто падали и было невозможно использовать репозиторй вообще. Поэтому они пофиксили багу добавив явную поддержку этого сценария. В git, похоже, просто никто не заморачивался.

_>>>·>А потом — как обычно, удалить ненужное, закоммитить.
_>>>Ну так а можно подробности, каким собственно образом это будет реализовываться? )
_>·>git rm или git mv.
_>Это ты просто помечаешь файл как удалённый, а не решаешь проблему.
А как ещё её можно решить?

_>>> И да, терять содержимое обоих файлов в следующей ревизии естественно нельзя... )
_>·>Так история же иммутабельная, как можно потерять что-то закоммиченное...
_>Я имею в виду, что если у тебя в кривой линуксовой ревизии были файлы a.txt и A.txt, то после исправления на винде у тебя в ревизии очевидно должно быть что-то вроде a.txt (с содержимым a.txt, а не некой рандомной хренью, создаваемой git'ом) и a1.txt (с содержимым А.txt), а не просто отсутствие файла A.txt.
"git mv A.txt a1.txt"?

_>>>Прочитал статью? ) Там в каждом разделе можно найти по шедевру удобства использования Git под виндой. )))
_>·>"В поставке гит нет rsync и староватый perl, а ещё кофе не варит".
_>·>А в поставке hg какой версии rsync?
_>·>Дальше читать лениво. Давай конкретно.
_>Если кратко, то под винду существует множество реализаций Git'а и при этом каждая убога по своему. )))
В чём официальная убога? "Устарвешая версия" — да, немного отстаёт от линуховой, но незначительно, на пару месяцев по моим наблюдениям.

_>Да, а последний раздел (про 64-ёх битный вариант) я вообще без смеха читать не мог. )))
И что?.. egit/jgit это pure java имплементации, оно изначально было сделано для работы с репозиториями из ява-приложений, чтобы не звать внешние тулзы или нативные либы. Для hg такого и нет.
Остальное — какие-то эксперименты, что в этом плохого? Не нравится — используй официальную версию.
64 бита — хз, понятия не имею, в последнее время проблем вроде нет. Хотя не удивлюсь что были, из-за разного понимания 64 под виндой и линухом.

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

_>·>А tip это тег, который скачет как закладка? тегладка (tagmark)? Всё чудесатее и чудесатее.
_>Ну да, типа того. ) По идее tip было бы логично реализовать как закладку, но изначально их в Mercurial просто не было. )))
Вот это в hg и не нравится. Нет концептуальной целостности — макароны слабосвязанных фич и нечёткой терминологии.

_>>>Ну так я тебе уже ответил только что. )
_>·>Ты ответил, что их четыре. Теперь одна. И ты так и не объяснил по какому принципу ты выбрал эти четыре и как оно согласуется с определением в документации.
_>Я же тебе уже отвечал и не один раз. Утомило уже. Последняя попытка... В разные периоды жизни существовали разные ветки. Они же не фиксированные навсегда сущности, а могут появляться и пропадать через разделения/слияния. Соответственно на момент последней ревизии у тебя в репозитории одна ветка. А вот за всю историю их там было больше. )
Вот это хорошй пример нечёткой терминологии. Что-то как то было, толи один, толи эти четыре, толи ещё что... Гуманитарщина какая-то.

_>·>git craZyexPerIment
_>·>будет создавать бранчи со случайным именем.
_>·>Их потом можно всех вывести командой "git branch --list experimental/*" , тоже можно заальясить.
_>·>Т.е. при желании это реализуется в несколько строчек конфига. И нет этого в стандартной поставке гита потому что это нафиг никому не сдалось, слава Оккаму, что этот анонимный бред отрезали. Такой инструмент — не удобен. Он может быть удобен только в том случае, когда ничего более удобного нет. А в гите есть куча более адекватных инструментов.
_>Например? )
Ссылки (ветки, теги, stash, етс), reflog. Перечисляли же, не раз.
Вот скажем stash гораздо удобнее в git, чем анонимные ветки. А в hg это полная хрень, прикрученная сбоку, сделанная "шоб було" слабосвязанная фича, с которой даже diff нельзя сделать. Не удивительно, что приходится использовать анонимные ветки и считать их за благо.

_>>>·>Для чего под одним именем объединять-то? Чтобы всех запутать?
_>>>Почему запутать? Как раз удобно все эксперименты держать под одним именем experimental)
_>·>Будет у тебя 20 экспериментов... и как их различать-то?
_>Вообще то у каждого есть подробное описание в комментарии к ревизии. )))
Почему подробное описание писать не лень (мне наоборот — лень, ибо потом всё равно менять — добавить story number, перечитать/переписать раза два для понятности ревьюверам), а одно-два слова сочинить для имени ветки — проблема?