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

C>Что значит "откатиться"? У нас не централизованная VCS, некуда откатываться.

Это значит иметь возможность сделать чекаут коммита HEAD-N и получить возможность осмотреться внутри репозитория годичной давности. Какие ветки были, кто куда коммитил и все такое.
Граф гита — то еще убожество в таких ситуациях.

C>У нас не централизованная VCS, некуда откатываться.

В 99% продакшн энвайраментах есть центральная репа. Ее и можно считать основной.
У меня лично не было ни разу нужды заводить больше 1 remote репозитория. Поэтому все эти фичи децентрализованные только мешают и усложняют повседневные задачи.
Линусу линусово, а красноглазым членов команды надо тряпками по щщам когда они в очередной раз заводят свои байки про убер систему git
Пользоваться же надо теми системами которые хорошо поддерживаются твоей IDE. В случае C++/C# под VS это не так.

C>Можно посмотреть какие в репозитории были названия голов в данное время.

Как? Только чтобы удобно, а не а-ля полистать reflog

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

C>>Что значит "откатиться"? У нас не централизованная VCS, некуда откатываться.
W>Это значит иметь возможность сделать чекаут коммита HEAD-N и получить возможность осмотреться внутри репозитория годичной давности. Какие ветки были, кто куда коммитил и все такое.
А зачем? Ну сделай себе такой pre-commit hook на сервере: "git branch -a | sort > mybranches; git commit -am `date`".

W>Граф гита — то еще убожество в таких ситуациях.
Я не очень понимаю в чём проблема у аффтора.

W>В 99% продакшн энвайраментах есть центральная репа. Ее и можно считать основной.
А зачем?

W>У меня лично не было ни разу нужды заводить больше 1 remote репозитория. Поэтому все эти фичи децентрализованные только мешают и усложняют повседневные задачи.
Сожалею, в большой команде, значит, не работали.

W>Пользоваться же надо теми системами которые хорошо поддерживаются твоей IDE. В случае C++/C# под VS это не так.
Ну дык, а ещё можно привязать батарею цепью к ногам и не ходить дальше того, что разрешает цепь.

C>>Можно посмотреть какие в репозитории были названия голов в данное время.
W>Как? Только чтобы удобно, а не а-ля полистать reflog
Какая конкретно задача-то?

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

N>>Боянное верхоглядское делание выводов на основании недочтения с твоей стороны. Или покажи живой пример.

W>Сталкивался на практике с таким поведением гита. Когда резет делает переносы "как у другого разраба который их коммитил", а потом мой гит начинает кричать что файлы поменяны, надо коммитить.

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

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

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

W>·>Сколько себя не помню, официальный "Git for Windows" всегда ставился в "Program Files" или "Program Files (x86)" — проблем не наблюдал.

W>Этих гитов под виндос как собак развелось.
W>Каждый настраивается как бог на душу положит. Поди разберись кто из них официальный

Ну поставь винду со ZverCD и потребуй официальной поддержки.

W>Вообще отмазка про неправильный дистрибутив весьма характерна именно для линуксоидов. Позволяет бесконечно вилять задом от неудобных вопросов

"Виляет задом" тот, кто ставит ХЗ что и потом кричит про всё средство в целом.

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

N>>Нет. То, что по нему пишут книги, всего лишь показывает его популярность.
W>Нет. Книги пишут по всему чему попало.

По никому не нужному — не пишут. Или не печатают.

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

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

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

N>>Ситуацию, когда в пределах одной рабочей копии status показывает изменение, а hard reset его не сбрасывает, это не даст.
CX>Я подобное наблюдал, когда в репозиторий были добавлены файлы с разным содержимым, но именами, отличающимися только регистром.

Хм, вот это таки может быть вариантом. Надо запомнить, спасибо.

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

_>>>Из существенных претензий тут только пункт с close-branch. Если бы он был правдивый (тут уже вроде всё показали на эту тему).
N>>Не-а. Из существенных тут невозможность узнать в любой момент, что в staging. Вот это действительно очень серьёзный злобный фактор. А работа веток, которые не ветки, тут действительно мелкий фактор.
_>Это ты про что (в Mercurial же нет понятия staging), про возможность показать что будет зафиксировано или про какие-то дополнения к работе расширения record? )

Вот я читаю `hg help record` и вижу описание того, что она "interactively select changes to commit". Где находятся эти изменения, когда hg record уже отработала, а hg commit ещё не запускалась? Это то, по чему я предположил существование staging area. Видишь ли, в отличие от предположений коллеги woah, я читаю документацию и верю ей.

А вот сейчас проверил — hg record сразу коммитит. Значит, враньё с самого начала в документации — фраза "interactively select changes to commit" должна звучать на самом деле примерно как "commit interactively selected changes". Да, ты прав, всё ещё хуже, чем я предположил — в Hg нет staging, а в документации ещё один кусок гнилого обмана.

(А ещё в таком случае интересно, зачем такую пустую банальность, не дающую никаких потенциально неожиданных свойств, как staging area, прятать в выключенные по умолчанию расширения. Конспирология, но у меня нет никаких идей, кроме как то, что авторы Hg считают своих пользователей за полных дебилов, которые всё протеряют.)

_>А почему это грязнокодинг? ) Разве нельзя добиться нужного результата не меняя историю (например та же команда hg backout демонстрирует пример подобного)? В итоге у тебя будет всё красиво и история сохранится. Или тебе надо скрыть из истории все следы косяков и т.п.? )))

Кроме эмоциональных оценок в терминах "скрыть" и "косяк", всё верно. Первичная история — до начала взаимодействия с другими людьми — не должна быть историей косяков, она должна быть историей правильно сформированных и сгруппированных изменений. Ты предлагаешь хоть и маленький и временный, но _продукт_. Своей работы. Никого не должно волновать, сколько промежуточных косяков ты допускаешь по дороге, пока это укладывается в ограничения по ресурсам — на суд коллег должны быть вынесены результаты.

А эти результаты в нормальном варианте строятся в цепочку изменений (в сложном — несколько цепочек, но каждая должна быть логически закончена), так, что каждое из них
* делает только одно из набора: стилевые правки, рефакторинг, функциональное изменение
* или сделано вручную, или автоматически (как автоформаттером), кроме случаев, когда за автоформаттером надо подчищать
* функциональное изменение по возможности максимально однородно по сути действий

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

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

N>>Она не базовая. Базовая это цепочки коммитов. А фиксация безымянных голов это уже расширение. И это ещё раз показывает следствия безумного бардака с терминологией.
_>А как можно организовать цепочки без фиксации? )

Ключевое слово было "безымянных". Не делай вид, что не понял этого.

N>>Это называется наплевательством на качество результата. Я не могу принять ни такой стиль, ни следствия в виде "нефиг менять, раз однажды закоммитил" для *VCS.

_>А что ты называешь качественным результатом то? ) Мне казалось это должна быть идеально работающая последняя ревизия. Но у тебя это похоже что-то иное... )))

См. выше.

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

_>>>Т.е. чтобы сделать аналог простейшего режима работы в Mercurial вообще без именованных веток в Git надо завести в каждом репозитории минимум 2 ветки (одну общую для синхронизации и слияний и одну для локальной разработки), правильно? )
N>>Да. И это правильно.
_>Ага, и в итоге у каждого репозиторий выглядит по своему. Весело. )))

Это _распределённая_ система. Если удивляет, что у разных людей разное содержание — хм, я боюсь, тут вообще не centralized VCS должна помочь, а вообще файловая шара.
Это не наезд, но попытка определить границы того, что тебе не нравится, что "у каждого репозиторий выглядит по своему", значит, для тебя он у всех должен быть одинаковым.

_>>>P.S. Кстати, тут что-то вспомнилось... А что у git с аналогами команд hg copy/rename/remove? ) Помнится он там что-то автоматическое пытался делать, но чаще всего криво... )))
N>>Не понимаю проблемы.
_>Да тут вот народ рядом жалуется на то, что при рефакторинге git делает некую ересь. )

Он не делает никакой "ереси", это опять попытка втихую навесить эмоциональный ярлык (<sarcasm>branch, в терминах Hg</sarcasm>). А что именно он делает — уже обсудили и объяснили в деталях.

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

_>>Кстати, я помнится наблюдал ещё, что git (как и многий другой древний линуксовый софт) до сих пор ломается на каталога с пробелами в именах. ) Это вообще жесть и убогость. )))

W>Ну с учетом того что система писалась Линусом для личных нужд Линуса это нормально

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

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

1. В программы передаётся цельная "командная строка", а не список аргументов. Корректный, стандартизованный, поддержанный в WinAPI парсинг этой строки появился ой не сразу (обратим внимание, что эта функция существует только в Unicode варианте, и я не помню её существование во времена Windows 95-98, хотя специально искал). Несмотря на существование этой функции, если верить (ха-ха) MSDN, с Windows 2000, до сих пор её существование замалчивается (я не видел пока ни одного руководства, где бы её упоминали — видимо, для кого-то это совсем фантастические уровни). Причём на SO говорится: "It's ultimately up to the individual programs how they tokenize the command-line into an argv array (and even CommandLineToArgv in theory (and perhaps in practice, if what one of the comments said is true) could behave differently than the CRT when it initializes argv to main()), so there isn't even a standard set of esoteric rules that you can follow."

Также, нет готовой проверенной обратной функции (для Unix присутствует в десятке открытых источников).

2. Стандарт эскейпинга аргументов командной строки значительно более кривой, чем в Unix, малопонятный, и, в отличие от Unix, где он описывается в любых книгах по администрированию, глубоко спрятан в недрах MSDN.
Например, различный парсинг бэкслешей argv[1] в примерах 2 и 3 по предыдущей ссылке, и правила 5-7 в тексте — диверсия, которая не была бы пропущена ни в одно приличное средство. Пример плача.

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

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

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

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

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

W>Сам же в треде приводил
Напомни. Не знаю что ты имеешь в виду.

Из свежих "приятностей". У коллег стали пропадать изменения при слиянии веток в мастера. Стал разбираться и выяснилось что проблема возникает из за EOL. Выяснилось что алгоритм "странного мерджа" такой: человек работает в ветке, комитит,переключается на мастера, студия говорит о неконсистентных EOL в файле например 1.txt и предлагает исправить, человек нажимает да, после чего успешно мерджит ветку и мастера, при этом изменения из ветки сделанные в файле 1.txt не попадают в мердж.

Почему так происходит?

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

M>Из свежих "приятностей". У коллег стали пропадать изменения при слиянии веток в мастера. Стал разбираться и выяснилось что проблема возникает из за EOL. Выяснилось что алгоритм "странного мерджа" такой: человек работает в ветке, комитит,переключается на мастера, студия говорит о неконсистентных EOL в файле например 1.txt и предлагает исправить, человек нажимает да, после чего успешно мерджит ветку и мастера, при этом изменения из ветки сделанные в файле 1.txt не попадают в мердж.
M>Почему так происходит?
Трудно сказать. Надо смотреть что происходит конкретно, "git log -p" должен многое рассказать.
Могу предположить, что когда ветки переключатся, Студия "забывает" перечитать файлы с диска в память редактора и затирает изменения при "исправлении" EOL, человек не обращает на это внимание и коммитит это как результат мержа.
Самым правильным будет разобраться откуда у вас проблемы с EOL и пофиксить их.

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

Похоже что так и было в студии, но конечно это большой сюрприз. Сейчас поставил у себя autocrlf=false и склонировал репозиторий. Выяснилось что часть файлов в репозитории имеет LF формат EOL. Очень странно — значит у кого-то был autocrlf=false c которым он коммитил так что ли получается? А вот как теперь наладить чтобы у всех был CRLF не очень понятно. Мой первый порыв был сконвертить все EOL в CRLF и закомитить их в мастера. Но это ничего не даст веточникам. Как быть?

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

M>Похоже что так и было в студии, но конечно это большой сюрприз.
Да это вечная проблема. Если юзеры сидят под разными операционками, то конфликты неизбежны. Особенно под виндой. Скажем, если ты работаешь с родными виндовыми программами, то они ожидают crlf, а если скажем cygwin, то он хочет lf. Или если под виндой собираешь .tag.gz, который затем шлётся на линукс.

M>Сейчас поставил у себя autocrlf=false и склонировал репозиторий. Выяснилось что часть файлов в репозитории имеет LF формат EOL. Очень странно — значит у кого-то был autocrlf=false c которым он коммитил так что ли получается? А вот как теперь наладить чтобы у всех был CRLF не очень понятно. Мой первый порыв был сконвертить все EOL в CRLF и закомитить их в мастера. Но это ничего не даст веточникам. Как быть?
Обычно договорённость такая, что в репозитории всегда lf, а юзеры должны настраивать свои репозитории так, чтобы в рабочей копии были желаемые eols.
А сейчас можно пофиксить все ветки "главного" репозитория и навесить на него хук, чтобы он отпинывал все коммиты с crlf. В интернетах думаю можно найти готовый скрптик... или несложно написать самому. Правда непонятно как отличать текстовые файлы от бинарных, можно попробовать трюки типа этого...

UPD: А, что-то торможу. Ведь git diff покажет crlf, а бинарики он игнорирует. Т.е. в хуке надо просто грепнуть выхлоп git diff на отсутствие crlf

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

_>>и одну собственно для работы. Так вот, даже если каждый член команды и назовёт эту вторую ветку одинаково, то всё равно в них будут разные данные.
·>По дефолту эта вторая ветка создаётся с тем же именем. Т.е. если никто явно не указал гиту другое имя, то оно будет совпадать.
·>Если же кто-то что-то нахитрил и изменил имя, всё равно сам граф будет идентичный, просто будет видно, что имя изменено.

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

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

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

Закладки — это указатель, который автоматически скачет на следующую ревизию при фиксации. А тег никуда не скачет, но зато может просто редактироваться пользователем.

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

Ну так я тебе уже ответил только что. )

_>>·>Да, когда шлёшь что-то другому репозиторию — надо создать имя. Иначе тому другому может пушить кто-то ещё и получится жуткий бардак.
_>>Ну т.е. чтобы создать отросток в одну ревизию с неким альтернативным вариантом кода,
·>А если не отросток? Не diverged т.е.?

Не понял, не отросток, а что тогда? )

_>> мне надо будет придумывать по новому имени ветки каждый раз, правильно? )
·>uuid используй или хеш какой-нибудь, если думать лень.

Да, очень удобно. ))) Как раз принцип Оккама в действие. )))

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

Почему запутать? Как раз удобно все эксперименты держать под одним именем experimental)

_>>·>git diff чем не устраивает?
_>>А он может показать разницу между stash и рабочим каталогом? )
·>git diff stash@{13}
·>неожиданно, правда?

Это разве покажет не разницу с последней ревизией? )

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

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

Ага, под линухом. А как мне исправить ситуацию из под винды? )

·>Сколько себя не помню, официальный "Git for Windows" всегда ставился в "Program Files" или "Program Files (x86)" — проблем не наблюдал.

Это вот этот https://habrahabr.ru/post/255443/ вот, да? )))

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

_>>Это ты про что (в Mercurial же нет понятия staging), про возможность показать что будет зафиксировано или про какие-то дополнения к работе расширения record? )
N>Вот я читаю `hg help record` и вижу описание того, что она "interactively select changes to commit". Где находятся эти изменения, когда hg record уже отработала, а hg commit ещё не запускалась? Это то, по чему я предположил существование staging area. Видишь ли, в отличие от предположений коллеги woah, я читаю документацию и верю ей.
N>А вот сейчас проверил — hg record сразу коммитит. Значит, враньё с самого начала в документации — фраза "interactively select changes to commit" должна звучать на самом деле примерно как "commit interactively selected changes". Да, ты прав, всё ещё хуже, чем я предположил — в Hg нет staging, а в документации ещё один кусок гнилого обмана.
N>(А ещё в таком случае интересно, зачем такую пустую банальность, не дающую никаких потенциально неожиданных свойств, как staging area, прятать в выключенные по умолчанию расширения. Конспирология, но у меня нет никаких идей, кроме как то, что авторы Hg считают своих пользователей за полных дебилов, которые всё протеряют.)

Собственно hg record был в старых версиях Mercruial, а в новых просто hg commit -i. Так что всё становится до конца логично и понятно, и без всяких расширений.

И это намного удобнее реализации в Git, т.к. полностью решает описанную тобой задачку (фиксации только части изменений рабочего каталога) без введения каких-либо дополнительных ненужных сущностей типа stage.

_>>А почему это грязнокодинг? ) Разве нельзя добиться нужного результата не меняя историю (например та же команда hg backout демонстрирует пример подобного)? В итоге у тебя будет всё красиво и история сохранится. Или тебе надо скрыть из истории все следы косяков и т.п.? )))
N>Кроме эмоциональных оценок в терминах "скрыть" и "косяк", всё верно. Первичная история — до начала взаимодействия с другими людьми — не должна быть историей косяков, она должна быть историей правильно сформированных и сгруппированных изменений. Ты предлагаешь хоть и маленький и временный, но _продукт_. Своей работы. Никого не должно волновать, сколько промежуточных косяков ты допускаешь по дороге, пока это укладывается в ограничения по ресурсам — на суд коллег должны быть вынесены результаты.

Похоже что ты забыл (или может вообще не знал?) один из главных научных принципов "отрицательный результат — тоже результат". ) Это же вполне касается и инженерной работы — надо документировать весь процесс разработки, в том числе и подробно описывать все тупики.

N>А эти результаты в нормальном варианте строятся в цепочку изменений (в сложном — несколько цепочек, но каждая должна быть логически закончена), так, что каждое из них
N>* делает только одно из набора: стилевые правки, рефакторинг, функциональное изменение
N>* или сделано вручную, или автоматически (как автоформаттером), кроме случаев, когда за автоформаттером надо подчищать
N>* функциональное изменение по возможности максимально однородно по сути действий
N>и только такое заслуживает передачи в общее репо так, чтобы не было чего мучительно стыдиться.

Это похоже на какие-то опенсорсные заморочки. )))

N>И реально сложное изменение такого рода не сделать без возможности разделения, перестановки, слияния коммитов, выбора нужного из локальных изменений. А если какое-то современное средство прячет эту функциональность поглубже (отдельные команды, выключенные по умолчанию расширения), то его авторы целенаправленно воспитывают ламеров и говнокодеров.

У меня противоположное мнение. )

N>>>Она не базовая. Базовая это цепочки коммитов. А фиксация безымянных голов это уже расширение. И это ещё раз показывает следствия безумного бардака с терминологией.
_>>А как можно организовать цепочки без фиксации? )
N>Ключевое слово было "безымянных". Не делай вид, что не понял этого.

Ну так в Git же цепочки тоже внутри безымянные (у них есть только хэш, как и в Mercurial), а имена вешаются поверх (как закладки в Mercurial).

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

_>>>и одну собственно для работы. Так вот, даже если каждый член команды и назовёт эту вторую ветку одинаково, то всё равно в них будут разные данные.
_>·>По дефолту эта вторая ветка создаётся с тем же именем. Т.е. если никто явно не указал гиту другое имя, то оно будет совпадать.
_>·>Если же кто-то что-то нахитрил и изменил имя, всё равно сам граф будет идентичный, просто будет видно, что имя изменено.

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

/temp/git$ git init main
Initialized empty Git repository in C:/Program Files (x86)/Git/temp/git/main/.git/
/temp/git$ cd main/
/temp/git/main$ git config user.name mainRepoUser
/temp/git/main$ echo line1 > file1
/temp/git/main$ git add .
/temp/git/main$ git commit -m init
[master (root-commit) 6659af7] init
 1 file changed, 1 insertion(+)
 create mode 100644 file1
/temp/git/main$ cd ..
/temp/git$ git clone main other
Cloning into 'other'...
done.
/temp/git$ cd other/
/temp/git/other$ git config user.name otherRepoUser
/temp/git/other$ echo line1 > file2
/temp/git/other$ git add .
/temp/git/other$ git commit -m "new file2"
[master 30a77ab] new file2
 1 file changed, 1 insertion(+)
 create mode 100644 file2
/temp/git/other$ cd ../main/
/temp/git/main$ echo line2 >> file1
/temp/git/main$ git commit -am "file1 modified"
[master 6945355] file1 modified
 1 file changed, 1 insertion(+)
/temp/git/main$ git pull ../other
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 2 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (2/2), done.
From ../other
 * branch            HEAD       -> FETCH_HEAD
Merge made by the 'recursive' strategy.
 file2 | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 file2
/temp/git/main$ git log --decorate --graph
*   commit a0fbdb9a9f33af674a54463c1dd320d940cf005f (HEAD, master)
|\  Merge: 6945355 30a77ab
| | Author: mainRepoUser <user@email.com>
| | Date:   Fri Feb 12 18:18:06 2016 +0000
| |
| |     Merge ../other
| |
| * commit 30a77abd08b1998f0321f10ee33b53dfe4343a20
| | Author: otherRepoUser <user@email.com>
| | Date:   Fri Feb 12 18:07:18 2016 +0000
| |
| |     new file2
| |
* | commit 6945355499c122dd2b9e447ce4c8f5e38408f0ff
|/  Author: mainRepoUser <user@email.com>
|   Date:   Fri Feb 12 18:14:59 2016 +0000
|
|       file1 modified
|
* commit 6659af7312be43f321dba61f28832d0fb7e7285e
  Author: mainRepoUser <user@email.com>
  Date:   Fri Feb 12 17:59:36 2016 +0000
/temp/git/main$ cd ../other/
/temp/git/other$ git log --decorate --graph
* commit 30a77abd08b1998f0321f10ee33b53dfe4343a20 (HEAD, master)
| Author: otherRepoUser <user@email.com>
| Date:   Fri Feb 12 18:07:18 2016 +0000
|
|     new file2
|
* commit 6659af7312be43f321dba61f28832d0fb7e7285e (origin/master, origin/HEAD)
  Author: mainRepoUser <user@email.com>
  Date:   Fri Feb 12 17:59:36 2016 +0000

      init
/temp/git/other$ git pull
remote: Counting objects: 8, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 5 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (5/5), done.
From C:/Program Files (x86)/Git/temp/git/main
   6659af7..a0fbdb9  master     -> origin/master
Updating 30a77ab..a0fbdb9
Fast-forward
 file1 | 1 +
 1 file changed, 1 insertion(+)
/temp/git/other$ git log --decorate --graph
*   commit a0fbdb9a9f33af674a54463c1dd320d940cf005f (HEAD, origin/master, origin/HEAD, master)
|\  Merge: 6945355 30a77ab
| | Author: mainRepoUser <user@email.com>
| | Date:   Fri Feb 12 18:18:06 2016 +0000
| |
| |     Merge ../other
| |
| * commit 30a77abd08b1998f0321f10ee33b53dfe4343a20
| | Author: otherRepoUser <user@email.com>
| | Date:   Fri Feb 12 18:07:18 2016 +0000
| |
| |     new file2
| |
* | commit 6945355499c122dd2b9e447ce4c8f5e38408f0ff
|/  Author: mainRepoUser <user@email.com>
|   Date:   Fri Feb 12 18:14:59 2016 +0000
|
|       file1 modified
|
* commit 6659af7312be43f321dba61f28832d0fb7e7285e
  Author: mainRepoUser <user@email.com>
  Date:   Fri Feb 12 17:59:36 2016 +0000

      init

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

Заметь — мне вообще не пришлось делать что-то с ветками, и никаких анонимных веток не понадобилось.

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

N>Это _распределённая_ система. Если удивляет, что у разных людей разное содержание — хм, я боюсь, тут вообще не centralized VCS должна помочь, а вообще файловая шара.
N>Это не наезд, но попытка определить границы того, что тебе не нравится, что "у каждого репозиторий выглядит по своему", значит, для тебя он у всех должен быть одинаковым.

Ну так mercurial то предоставляет все возможности распределённой системы и при этом в дефолтном режиме создаёт одинаковые репозитории (в состояние синхронизации). )))

_>>Да тут вот народ рядом жалуется на то, что при рефакторинге git делает некую ересь. )
N>Он не делает никакой "ереси", это опять попытка втихую навесить эмоциональный ярлык (<sarcasm>branch, в терминах Hg</sarcasm>). А что именно он делает — уже обсудили и объяснили в деталях.

Мне понятно что он делает. Только вот он не справляется, как тут подробно показали. Аналогичный автоматический инструмент в Mercurial может тоже не справится, но кроме него тут есть и удобный ручной вариант, который полностью решает проблему. )