Здравствуйте, netch80, Вы писали:
N>Ситуацию, когда в пределах одной рабочей копии status показывает изменение, а hard reset его не сбрасывает, это не даст.
Я подобное наблюдал, когда в репозиторий были добавлены файлы с разным содержимым, но именами, отличающимися только регистром.
Типовой use case такой:
На GNU/Linux (сase-sensitive FS by default) добавляем файлы, имена которых отличаются только регистром.
На OS X (case-insensitive FS by default) делаем pull.
В этом случае "git status" на OS X показывает измененные файлы даже после "git reset --hard".
Здравствуйте, alex_public, Вы писали:
_>>>Ну так а разработка то идёт в других ветках с другими именами. Ну и к тому же имя Петя/develop вовсе не совпадает с именем develop (не говоря уже о том, что у тебя есть своя ветка develop с совсем другими данными). _>·>Имя совпадает, это "develop", а "Петя/" это префикс или пространство (namespace). Т.е. имена не глобальны, а разделены на пространства естественным образом.
_>Так, я сажусь за один компьютер даю команду показать мне содержимое ветки develop. Потом сажусь за соседний, даю такую же команду и вижу другие данные. Это ты называешь одинаковыми репозиториями? )))
Если мы рассматриваем ситуацию, когда всё синхронизировано — то с чего ты взял что данные будут другие? Репы будут идентичны.
А в общем случае да, могут быть другие, как и в hg — tip же может разный в разных репо.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>·>Опять. Почему меня должно волновать долго ли, коротко ли живёт ветка? Зачем меня ставить перед этим выбором? Какую пользу приносит это решение? _>Я тебе описал наиболее продуманные решения. Но тебя никто не заставляет ими пользоваться. Может приделывать имя на каждое микроветвление или вести основные ветки через закладки. Делай как тебе нравится. )))
Т.е. если я захочу в своём клоне делать всё через закладки, а ты в своём — через имена, то мы без проблем сможем обмениваться изменениями друг с другом? У нас ведь DVCS, каждый волен работать как ему нравится.
_>>>А что значит "запушить ветку"? ) И зачем это надо? ) _>·>Опубликовать в удалённый репозиторий, или, что аналогично, затащить (fetch) из удалённого. Чтобы передать знание о том, что я решил считать релиз-кандидатом. _>Эм, т.е. ты снова пытаешься просто повесить некую метку на конкретную ревизию с помощью создания именованной ветки? ) Жесть, вот что привычки к git'у делают. )))
Т.е. именованную ветку я "как мне нравится" уже не могу. Что-то ты себе противоречишь. Так "как нравится" или как разработчики hg решили?
_>>>Вот не надо только пропагандировать тут подход Apple — в профессиональной среде он плохо проходит. ))) _>·>Вроде ты тут пропагандируешь — смысла нет, остаётся только дело вкуса. _>Не, подход Apple "у нас этого нет — значит оно вам не нужно". )))
Я просто не понимаю чего "этого" у нас нет? Удобство работы с анонимными ветками что-ли? Но анонимные ветки это лишь способ решения неких задач, а не цель.
_>>>Я так и не понял что ты хочешь))) Точнее не пойму чем тебя не устраивает мой ответ в первом же сообщение (много страниц назад). Ну да ладно, мне не сложно повторить в сотый раз, уже с буковками. ))) Последовательности ревизий: {a, b, c}, {d, e, f}, {g}, {h, i, j, k}. _>·>Ок, допустим. Ты говорил, что последовательность ревизий это и есть ветка. Ты говорил, что hg позволяет хорошо работать с ветакми. Какой командой мне вывести эти четыре ветки для этого графа истории? _>Так это смотря в какой момент времени смотреть) В разные моменты будут разные ответы. )
В смысле? Я тебе говорю об одном моменте — который описан графом. Ты сказал в этом графе четыре ветки. Как их увидеть с помощью команд hg?
Ещё вопрос. Почему ты выбрал именно {h, i, j, k}? Чем {i, j, k}, {h, i, j}, {g, h, i, j, k} плохи? Тоже вроде линии.
_>>>Ну вот работаю над каким-то проектом, решил проверить некое решение, закодировал, убедился что оно сейчас не подходит (но код полезный и пригодится в будущем), зафиксировал его в виде ревизии, откатился назад на одну ревизий и пошёл работать дальше, создавая новые ревизии. При этом у меня там _>·>git stash _>Так можно (это будет hg shelve), но это даже не близко к тому, что я описал. Как мне к примеру воспользоваться этим кодом из соседнего репозитория? )
Да, когда шлёшь что-то другому репозиторию — надо создать имя. Иначе тому другому может пушить кто-то ещё и получится жуткий бардак.
Но в целом всё то же, всё так же, всё как обычно, ведь у нас всё — ветки!
git push origin stash@{13}:refs/heads/stash13
Да, длинновато писать приходится, но если это кому-то когда-то такое понадобится более одного раза, можно сделать алиас.
_>Я уже не говорю о том, чтобы посмотреть разницу с текущей копией и т.п.
git diff чем не устраивает?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, CrystaX, Вы писали:
N>>Ситуацию, когда в пределах одной рабочей копии status показывает изменение, а hard reset его не сбрасывает, это не даст. CX>Я подобное наблюдал, когда в репозиторий были добавлены файлы с разным содержимым, но именами, отличающимися только регистром.
Какая милая система... )))
Кстати, я помнится наблюдал ещё, что git (как и многий другой древний линуксовый софт) до сих пор ломается на каталога с пробелами в именах. ) Это вообще жесть и убогость. )))
Здравствуйте, alex_public, Вы писали:
N>>>Ситуацию, когда в пределах одной рабочей копии status показывает изменение, а hard reset его не сбрасывает, это не даст. CX>>Я подобное наблюдал, когда в репозиторий были добавлены файлы с разным содержимым, но именами, отличающимися только регистром.
_>Какая милая система... )))
Очевидно, что это не проблема git-а. Это проблема различных используемых FS. Подобные проблемы будут с любым софтом. Но git с этим пытается бороться с помощью core.ignoreCase:
core.ignoreCase
If true, this option enables various workarounds to enable Git to work better on filesystems that are not case sensitive, like FAT. For example, if a directory listing finds "makefile" when Git expects "Makefile", Git will assume it is really the same file, and continue to remember it as "Makefile".
The default is false, except git-clone(1) or git-init(1) will probe and set core.ignoreCase true if appropriate when the repository is created.
_>Кстати, я помнится наблюдал ещё, что git (как и многий другой древний линуксовый софт) до сих пор ломается на каталога с пробелами в именах. ) Это вообще жесть и убогость. )))
Это не так. Если подавать пути ему на вход правильно (т.е. в кавычках или с экранированными пробелами), проблем нет.
Здравствуйте, alex_public, Вы писали:
N>>>Ситуацию, когда в пределах одной рабочей копии status показывает изменение, а hard reset его не сбрасывает, это не даст. CX>>Я подобное наблюдал, когда в репозиторий были добавлены файлы с разным содержимым, но именами, отличающимися только регистром. _>Какая милая система... )))
Рад, что ты начал понимать. Есть "core.ignoreCase". В отличие от этого убожества hg:
* Renaming colliding files *
...
To repair such revisions, you should give new names to one or both of the colliding files on a case-sensitive filesystem, and commit them to create new collision safe revision.
.. note:: If you want to (or need to) browse or repair such revisions on case-insensitive filesystems, please see 'Updating manually' section.
...
* Updating manually *
... This is NOT recommended for non expert Mercurial users.
_>Кстати, я помнится наблюдал ещё, что git (как и многий другой древний линуксовый софт) до сих пор ломается на каталога с пробелами в именах. ) Это вообще жесть и убогость. )))
Можно пример? Надеюсь ты знаешь, что имена с пробелами надо заключать в кавычки?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Так, я сажусь за один компьютер даю команду показать мне содержимое ветки develop. Потом сажусь за соседний, даю такую же команду и вижу другие данные. Это ты называешь одинаковыми репозиториями? ))) ·>Если мы рассматриваем ситуацию, когда всё синхронизировано — то с чего ты взял что данные будут другие? Репы будут идентичны. ·>А в общем случае да, могут быть другие, как и в hg — tip же может разный в разных репо.
Давай разберёмся. Для нормальной работы Git необходимо завести минимально две ветки в каждом репозитории: одну общую для синхронизации со всеми и одну собственно для работы. Так вот, даже если каждый член команды и назовёт эту вторую ветку одинаково, то всё равно в них будут разные данные.
Здравствуйте, ·, Вы писали:
_>>Я тебе описал наиболее продуманные решения. Но тебя никто не заставляет ими пользоваться. Может приделывать имя на каждое микроветвление или вести основные ветки через закладки. Делай как тебе нравится. ))) ·>Т.е. если я захочу в своём клоне делать всё через закладки, а ты в своём — через имена, то мы без проблем сможем обмениваться изменениями друг с другом? У нас ведь DVCS, каждый волен работать как ему нравится.
Без проблем. ) Правда я тогда буду видеть твои закладки, а ты будешь видеть мои ветки. ))) Правда закладки можно и локальные сделать...
_>>>>А что значит "запушить ветку"? ) И зачем это надо? ) _>>·>Опубликовать в удалённый репозиторий, или, что аналогично, затащить (fetch) из удалённого. Чтобы передать знание о том, что я решил считать релиз-кандидатом. _>>Эм, т.е. ты снова пытаешься просто повесить некую метку на конкретную ревизию с помощью создания именованной ветки? ) Жесть, вот что привычки к git'у делают. ))) ·>Т.е. именованную ветку я "как мне нравится" уже не могу. Что-то ты себе противоречишь. Так "как нравится" или как разработчики hg решили?
Ну формально то как раз можешь, но это бред. Для таких целей теги есть)
_>>Так это смотря в какой момент времени смотреть) В разные моменты будут разные ответы. ) ·>В смысле? Я тебе говорю об одном моменте — который описан графом. Ты сказал в этом графе четыре ветки. Как их увидеть с помощью команд hg? ·>Ещё вопрос. Почему ты выбрал именно {h, i, j, k}? Чем {i, j, k}, {h, i, j}, {g, h, i, j, k} плохи? Тоже вроде линии.
Если ты имеешь в виду момент последней ревизии, то к нему останется только одна ветка, в которую сольются предыдущие. )
_>>>>Ну вот работаю над каким-то проектом, решил проверить некое решение, закодировал, убедился что оно сейчас не подходит (но код полезный и пригодится в будущем), зафиксировал его в виде ревизии, откатился назад на одну ревизий и пошёл работать дальше, создавая новые ревизии. При этом у меня там _>>·>git stash _>>Так можно (это будет hg shelve), но это даже не близко к тому, что я описал. Как мне к примеру воспользоваться этим кодом из соседнего репозитория? ) ·>Да, когда шлёшь что-то другому репозиторию — надо создать имя. Иначе тому другому может пушить кто-то ещё и получится жуткий бардак.
Ну т.е. чтобы создать отросток в одну ревизию с неким альтернативным вариантом кода, мне надо будет придумывать по новому имени ветки каждый раз, правильно? ) И я не смогу например объединить все подобные отростки под одним именем (как можно в том же Mercurial)?
_>>Я уже не говорю о том, чтобы посмотреть разницу с текущей копией и т.п. ·>git diff чем не устраивает?
А он может показать разницу между stash и рабочим каталогом? )
Здравствуйте, CrystaX, Вы писали:
_>>Какая милая система... ))) CX>Очевидно, что это не проблема git-а. Это проблема различных используемых FS. Подобные проблемы будут с любым софтом. Но git с этим пытается бороться с помощью core.ignoreCase:
Естественно это проблема разных ОС (в данном случае Винда хуже). Но подобный софт должен учитывать эти нюансы и как минимум предупреждать пользователя о потенциальном конфликте.
_>>Кстати, я помнится наблюдал ещё, что git (как и многий другой древний линуксовый софт) до сих пор ломается на каталога с пробелами в именах. ) Это вообще жесть и убогость. ))) CX>Это не так. Если подавать пути ему на вход правильно (т.е. в кавычках или с экранированными пробелами), проблем нет.
А я не про это. Я про инсталляцию самого git'a куда-нибудь в каталог с пробелом в имени (типа "Program Files"). Данная убогость присутствует в очень многих линуксовых программах (и это уже кривизна Линуха).
Здравствуйте, ·, Вы писали:
_>>Какая милая система... ))) ·>Рад, что ты начал понимать. Есть "core.ignoreCase". В отличие от этого убожества hg:
Ну и как эта опция поможет мне применить на винде ревизию (созданную в линухе) с двумя файлами отличающимися только регистром? )
_>>Кстати, я помнится наблюдал ещё, что git (как и многий другой древний линуксовый софт) до сих пор ломается на каталога с пробелами в именах. ) Это вообще жесть и убогость. ))) ·>Можно пример? Надеюсь ты знаешь, что имена с пробелами надо заключать в кавычки?
Я не про это. Я про расположение самого Git'а в каталоге с пробелом (типа "Program Files").
Здравствуйте, CrystaX, Вы писали:
CX>[skipped...] CX>"Вы, Шариков, чепуху говорите и возмутительнее всего то, что говорите ее безапелляционно и уверенно". CX>Мне к этому добавить нечего.
Здравствуйте, alex_public, Вы писали:
_>·>Если мы рассматриваем ситуацию, когда всё синхронизировано — то с чего ты взял что данные будут другие? Репы будут идентичны. _>·>А в общем случае да, могут быть другие, как и в hg — tip же может разный в разных репо. _>Давай разберёмся. Для нормальной работы Git необходимо завести минимально две ветки в каждом репозитории: одну общую для синхронизации со всеми
Не со всеми, а с "центральным" репозиторием.
_>и одну собственно для работы. Так вот, даже если каждый член команды и назовёт эту вторую ветку одинаково, то всё равно в них будут разные данные.
По дефолту эта вторая ветка создаётся с тем же именем. Т.е. если никто явно не указал гиту другое имя, то оно будет совпадать.
Если же кто-то что-то нахитрил и изменил имя, всё равно сам граф будет идентичный, просто будет видно, что имя изменено.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>>>Я тебе описал наиболее продуманные решения. Но тебя никто не заставляет ими пользоваться. Может приделывать имя на каждое микроветвление или вести основные ветки через закладки. Делай как тебе нравится. ))) _>·>Т.е. если я захочу в своём клоне делать всё через закладки, а ты в своём — через имена, то мы без проблем сможем обмениваться изменениями друг с другом? У нас ведь DVCS, каждый волен работать как ему нравится. _>Без проблем. ) Правда я тогда буду видеть твои закладки, а ты будешь видеть мои ветки. ))) Правда закладки можно и локальные сделать...
И наймём третьего, чтобы букмарки с ветками с тегами и с шелфом и т.п. синхронизировал.
_>>>·>Опубликовать в удалённый репозиторий, или, что аналогично, затащить (fetch) из удалённого. Чтобы передать знание о том, что я решил считать релиз-кандидатом. _>>>Эм, т.е. ты снова пытаешься просто повесить некую метку на конкретную ревизию с помощью создания именованной ветки? ) Жесть, вот что привычки к git'у делают. ))) _>·>Т.е. именованную ветку я "как мне нравится" уже не могу. Что-то ты себе противоречишь. Так "как нравится" или как разработчики hg решили? _>Ну формально то как раз можешь, но это бред. Для таких целей теги есть)
Чем теги от букмарок отличаются?
_>>>Так это смотря в какой момент времени смотреть) В разные моменты будут разные ответы. ) _>·>В смысле? Я тебе говорю об одном моменте — который описан графом. Ты сказал в этом графе четыре ветки. Как их увидеть с помощью команд hg? _>·>Ещё вопрос. Почему ты выбрал именно {h, i, j, k}? Чем {i, j, k}, {h, i, j}, {g, h, i, j, k} плохи? Тоже вроде линии. _>Если ты имеешь в виду момент последней ревизии, то к нему останется только одна ветка, в которую сольются предыдущие. )
Какой ещё момент? Пусть тебе на read only CD дали hg репо, граф которого я изобразил и попросили посчитать и перечислить ветки. Это так сложно?
_>>>Так можно (это будет hg shelve), но это даже не близко к тому, что я описал. Как мне к примеру воспользоваться этим кодом из соседнего репозитория? ) _>·>Да, когда шлёшь что-то другому репозиторию — надо создать имя. Иначе тому другому может пушить кто-то ещё и получится жуткий бардак. _>Ну т.е. чтобы создать отросток в одну ревизию с неким альтернативным вариантом кода,
А если не отросток? Не diverged т.е.?
_> мне надо будет придумывать по новому имени ветки каждый раз, правильно? )
uuid используй или хеш какой-нибудь, если думать лень.
_> И я не смогу например объединить все подобные отростки под одним именем (как можно в том же Mercurial)?
Для чего под одним именем объединять-то? Чтобы всех запутать?
_>>>Я уже не говорю о том, чтобы посмотреть разницу с текущей копией и т.п. _>·>git diff чем не устраивает? _>А он может показать разницу между stash и рабочим каталогом? )
git diff stash@{13}
неожиданно, правда?
Любопытно как это будет в hg.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>>>Какая милая система... ))) _>·>Рад, что ты начал понимать. Есть "core.ignoreCase". В отличие от этого убожества hg: _>Ну и как эта опция поможет мне применить на винде ревизию (созданную в линухе) с двумя файлами отличающимися только регистром? )
Пофиксить ревизию можно хотя бы, избавившись от одного из файлов.
_>>>Кстати, я помнится наблюдал ещё, что git (как и многий другой древний линуксовый софт) до сих пор ломается на каталога с пробелами в именах. ) Это вообще жесть и убогость. ))) _>·>Можно пример? Надеюсь ты знаешь, что имена с пробелами надо заключать в кавычки? _>Я не про это. Я про расположение самого Git'а в каталоге с пробелом (типа "Program Files").
Сколько себя не помню, официальный "Git for Windows" всегда ставился в "Program Files" или "Program Files (x86)" — проблем не наблюдал.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
N>Боянное верхоглядское делание выводов на основании недочтения с твоей стороны. Или покажи живой пример.
Сталкивался на практике с таким поведением гита. Когда резет делает переносы "как у другого разраба который их коммитил", а потом мой гит начинает кричать что файлы поменяны, надо коммитить.
Дико достает одним словом.
_>Кстати, я помнится наблюдал ещё, что git (как и многий другой древний линуксовый софт) до сих пор ломается на каталога с пробелами в именах. ) Это вообще жесть и убогость. )))
Ну с учетом того что система писалась Линусом для личных нужд Линуса это нормально
Здравствуйте, ·, Вы писали:
·>Сколько себя не помню, официальный "Git for Windows" всегда ставился в "Program Files" или "Program Files (x86)" — проблем не наблюдал.
Этих гитов под виндос как собак развелось.
Каждый настраивается как бог на душу положит. Поди разберись кто из них официальный
Вообще отмазка про неправильный дистрибутив весьма характерна именно для линуксоидов. Позволяет бесконечно вилять задом от неудобных вопросов
W>>·>Ещё можно просто по sha1 обращаться. Можно reflog полистать, можно в stash закинуть. Вариантов куча. W>> И ни один неудобен для человека. ·>В каком случае ты столкнёшься с этим неудобством? Опиши сценарий.
Кейсы когда надо git reflog не знаешь?
Сам же в треде приводил
