Здравствуйте, ·, Вы писали:
_>>Я всё понимаю, с точки зрения техники. ) Но по факту у тебя используется два эти имени в обоих репозиториях. И скорее всего во всех подобных сценариях так и будет. Хотя конечно формально есть возможность делать любые локальные имена. ) ·>Используются потому что я так захотел. А по факту это разные имена, их отдельно можно адресовать, указав явно. Полные имена это refs/heads/SomeName и refs/remotes/origin/SomeName — как видишь — они не равны. Просто git видя, что локальное имя SomeName используется в контексте ремотного репозитория origin, по умолчанию сопоставляет их друг другу при push или pull.
Я вообще то об этом и говорю. ) Что скорее всего будешь так хотеть и во всех остальных аналогичных случаях. )))
_>>Нуу кстати в данном случае это явно проявление архитектурной особенности git'a — наличия понятия stage. Это кстати единственный случае в git, где я вообще не понимаю зачем такое ввели, т.к. оно не приносит ни малейшей пользы, а лишнее телодвижения из-за этой хрени делать приходится. ·>Неверно. -a флажок же проблем не было реализовать. Просто, как мне кажется, это наиболее частый сценарий — закоммитить изменённые файлы, но не случайно появившееся.
Конечно самый частый и поэтом за него у mercurial отвечает просто "commit", а у git зачем-то "commit -a". А вот аналогом "commit -A" из mercurial будет уже "add . ; commit" из git. Хотя на самом деле все эти различия в параметрах — это естественно мелочи. Но я в любом случае не понимаю смысла существования такой штуки как stage в git.
_>>Да, ровно столько же. Но в варианте без именованных локальных веток один checkout можно выкинуть (он там только для вида у тебя был), а в случае локальных веток нельзя, т.к. он задаёт имя. ·>Локальное имя только для наглядности, можно обойтись и master.
Короче, вариант с именами в удалённом репозитории по числу команд сокращаем до аналога из Maercurial, а вариант с локальными именами нет. Можешь сам повычислять, на своих же примерах (я прямо по ним и смотрю, а не где-то ещё).
_>>Нуу покажи другой вариант решения, чтобы точка выбора между альтернативами находилась после их фиксации и чтобы после слияния одной из альтернатив (естественно не должно быть разницы в командах и графах в зависимости от выбора), другая осталась в истории (и была доступна в других репозиториях). ·>Была доступна как? Безымянной головой — не выйдет, конечно. А именованным бранчем — просто запушить да и всё. Я уже не понимаю что тебе ещё не понятно.
Мне всё понятно и ты уже давно предоставил нормальный работающий вариант. Просто потом вот написал что-то вроде "если бы не надо было синхронизировать на стадии развилки, то в git можно было бы сделать всё проще.". А я тебе говорю что нельзя, т.к. проблема была не в синхронизации, а в сохранение альтернативы на будущее. Но если ты считаешь по другому, то давай предоставь другой вариант с совсем другим кодом — посмотрим, может так и есть. )))
Здравствуйте, ·, Вы писали:
·> W>·>то в изначальном будет 3 головы master, clones_master, clones_branch, структура графа — идентична.
·> W>Слегка не в тему вопрос. Допустим я пилил ветку и слил ее в ремот. Там она была смержена куда надо и удалена. Потом я тоже у себя ее удалил. ·> W>Как понять в рамках какой ветки изначально был запилен тот или иной коммит?
·> Никак. А зачем?
В мире очень много девиаций Но я пока не натыкался на внятное описание такой.
Здравствуйте, alex_public, Вы писали:
_>·>Используются потому что я так захотел. А по факту это разные имена, их отдельно можно адресовать, указав явно. Полные имена это refs/heads/SomeName и refs/remotes/origin/SomeName — как видишь — они не равны. Просто git видя, что локальное имя SomeName используется в контексте ремотного репозитория origin, по умолчанию сопоставляет их друг другу при push или pull. _>Я вообще то об этом и говорю. ) Что скорее всего будешь так хотеть и во всех остальных аналогичных случаях. )))
Нет, далеко не всегда. Сейчас я локально работаю в master, а push делаю с именем jira issue.
_>>>Нуу кстати в данном случае это явно проявление архитектурной особенности git'a — наличия понятия stage. Это кстати единственный случае в git, где я вообще не понимаю зачем такое ввели, т.к. оно не приносит ни малейшей пользы, а лишнее телодвижения из-за этой хрени делать приходится. _>·>Неверно. -a флажок же проблем не было реализовать. Просто, как мне кажется, это наиболее частый сценарий — закоммитить изменённые файлы, но не случайно появившееся. _>Конечно самый частый и поэтом за него у mercurial отвечает просто "commit", а у git зачем-то "commit -a". А вот аналогом "commit -A" из mercurial будет уже "add . ; commit" из git. Хотя на самом деле все эти различия в параметрах — это естественно мелочи. Но я в любом случае не понимаю смысла существования такой штуки как stage в git.
Удобно. Коммит можно собирать по частям, серией различных команд.
Ещё удобно при разрешении конфликтов — при мерже неконфликтующие файлы идут в индекс, а кофликтующие не идут. Потом удобно по мере разрешения конфликтов добавлять разрешенное в индекс.
В общем, попробуешь — понравится.
_>>>Да, ровно столько же. Но в варианте без именованных локальных веток один checkout можно выкинуть (он там только для вида у тебя был), а в случае локальных веток нельзя, т.к. он задаёт имя. _>·>Локальное имя только для наглядности, можно обойтись и master. _>Короче, вариант с именами в удалённом репозитории по числу команд сокращаем до аналога из Maercurial, а вариант с локальными именами нет. Можешь сам повычислять, на своих же примерах (я прямо по ним и смотрю, а не где-то ещё).
Все push можно сделать одной командой. Тогда и получится столько же или даже меньше.
Например можно сделать так так:
cd clone
//мы уже находимся в master по умолчанию, не нужен checkout
//do change2A
git commit
git checkout -b change2B origin/master // switching back to previous revision
//do change 2B
git commit
теперь две альтернативы.
Выбрали 2B:
// мы уже находимся в change2B, не нужен checkout
git pull origin master// мержимся с изменениями пришедшими из начального репо
git push origin master:alternativeUnmergedSolution change2B:master
Выбрали 2A:
git checkout master
git pull origin master // мержимся с изменениями пришедшими из начального репо
git push origin master change2B:alternativeUnmergedSolution
В итоге в начальном репозитории будет две ветки — одна master — с замерженным решением и вторая alternativeUnmergedSolution.
_>>>Нуу покажи другой вариант решения, чтобы точка выбора между альтернативами находилась после их фиксации и чтобы после слияния одной из альтернатив (естественно не должно быть разницы в командах и графах в зависимости от выбора), другая осталась в истории (и была доступна в других репозиториях). _>·>Была доступна как? Безымянной головой — не выйдет, конечно. А именованным бранчем — просто запушить да и всё. Я уже не понимаю что тебе ещё не понятно. _>Мне всё понятно и ты уже давно предоставил нормальный работающий вариант. Просто потом вот написал что-то вроде "если бы не надо было синхронизировать на стадии развилки, то в git можно было бы сделать всё проще.". А я тебе говорю что нельзя, т.к. проблема была не в синхронизации, а в сохранение альтернативы на будущее. Но если ты считаешь по другому, то давай предоставь другой вариант с совсем другим кодом — посмотрим, может так и есть. )))
Что значит "сохранение"? Я понимаю под сохранением отправить альтернативную (незамерженную) ветку в ремотный (начальный) репо, т.е. то что ты называешь "синхронизация".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Dziman, Вы писали:
D>·> W>Слегка не в тему вопрос. Допустим я пилил ветку и слил ее в ремот. Там она была смержена куда надо и удалена. Потом я тоже у себя ее удалил. D>·> W>Как понять в рамках какой ветки изначально был запилен тот или иной коммит? D>·> Никак. А зачем? D>В мире очень много девиаций Но я пока не натыкался на внятное описание такой.
Профессионализм это называется.
Не надо путать цель и средство. Человек не решает задачу "понять в рамках какой ветки изначально...". Задача звучит совсем по-другому, например, "узнать когда коммит X ушел в продакшн". Если человек привык решать эти задачи в hg, используя такое средство, как имя бранча внутри коммита, это не означет, что эта задача не решается в git, т.к. он не сохраняет имя бранча внутрь коммита. Задача вполне может решаться в git, но другими средствами.
Если человек расскажет свою задачу, мы форумом попробуем предложить её решение средствами git, а он потом может решить, удобнее ли или нет.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
W>Слегка не в тему вопрос. Допустим я пилил ветку и слил ее в ремот. Там она была смержена куда надо и удалена. Потом я тоже у себя ее удалил. W>Как понять в рамках какой ветки изначально был запилен тот или иной коммит?
Не совсем понятно зачем, но да ладно.
При мерже обычно создается мерж комит в котором есть информаци какая ветка куда была замержена.
Здравствуйте, ·, Вы писали:
_>>Конечно самый частый и поэтом за него у mercurial отвечает просто "commit", а у git зачем-то "commit -a". А вот аналогом "commit -A" из mercurial будет уже "add . ; commit" из git. Хотя на самом деле все эти различия в параметрах — это естественно мелочи. Но я в любом случае не понимаю смысла существования такой штуки как stage в git. ·>Удобно. Коммит можно собирать по частям, серией различных команд. ·>Ещё удобно при разрешении конфликтов — при мерже неконфликтующие файлы идут в индекс, а кофликтующие не идут. Потом удобно по мере разрешения конфликтов добавлять разрешенное в индекс. ·>В общем, попробуешь — понравится.
Чтобы сделать частичную фиксацию эта сущность точно не нужна (hg commit -i тому доказательство). А какие ещё полезные сценарии могут быть? )
_>>Короче, вариант с именами в удалённом репозитории по числу команд сокращаем до аналога из Maercurial, а вариант с локальными именами нет. Можешь сам повычислять, на своих же примерах (я прямо по ним и смотрю, а не где-то ещё). ·>Все push можно сделать одной командой. Тогда и получится столько же или даже меньше. ·>Например можно сделать так так: ·>... ·>В итоге в начальном репозитории будет две ветки — одна master — с замерженным решением и вторая alternativeUnmergedSolution.
Да, но тогда во втором репозитории будет некая ересь. ) Причём степень её бредовости будет зависеть от выбранного варианта.)
P.S. Вообще не очень понимаю смысл этих твоих дальнейших упражнений, после того как правильное решение уже было найдено. )
Здравствуйте, vovkab, Вы писали:
V>Не совсем понятно зачем, но да ладно. V>При мерже обычно создается мерж комит в котором есть информаци какая ветка куда была замержена.
Там нет информации что входило в эти ветки.
В ответе на стеке автор полагает что "Your example shows that the branch feature is still available."
А в моем вопросе это не так.
Да и сам ответ жесть какая-то. Такая куча буков и мешанина команд чтобы просто найти что Вася пилил в своей ветке месяц назад.
как мне тут советуют в соседней ветке и на стеке Ведь это гит для нас, а не мы для гита
·>Если надо поместить какую-то информацию в коммит, скажем bug id — просто добавь это в сообщение коммита. И не ограничивай себя только именем ветки, а добавляй что надо — номер спринта, идентификатор истории, фамилию проджект-менеджера, уровень алкоголя в крови, и т.п.
Проще в экселе это записывать. А исходники архивировать и на дискету. Удобней гита всяко
Здравствуйте, alex_public, Вы писали:
_>Mercurial лучше — абсолютно те же самые технические возможности, но при этом более удобно. Хотя если делать всё через GUI или вообще из какой-нибудь IDE, то скорее всего разницы не увидишь.
Здравствуйте, netch80, Вы писали:
N>В этом примере не разное понимание, а одна мелочь — фиксация имени ветки в коммите hg. Да, я действительно не понимаю, зачем это настолько нужно, чтобы выдвигать на киллер-фичу, при том, что реально ни одна другая SCM это не ведёт.
Вот для меня это возможно и есть киллер фича которой не хватает в гите
Взять и посмотреть быстро и удобно все что Петя делал 3 недели в рамках своих ковыряний фичи ХХХ.
Да это отвал башки просто если меркуриал позволяет это делать не выковыривая пятистрочными командами всякую срань из гитлога
N>Добавить принудительно имя ветки в сообщение тривиально за счёт локального хука, но накойхер? Там лучше держать, например, герритовский change-id.
А накойхер держать геррит, если работаешь в visual studio?
Ради одного неудобного инструмента (гит) добавлять костыли в виде других неудобных инструментов (геррит) ?
AK>в итоге мне для меня неясен подход гита в отношении контроля версий файла. его выходит как бы и нет... AK>а blame это больше похоже на костыль ну или я вообще не догоняю философию гита
Весь гит это по сути красивое нутро (реально лаконичная и простая архитектура) и ворох костылей чтобы это операции с этим нутром наложить на ежедневные потребности разрабов. Каждый релиз допиливают новые опции и команды которые по сути являются юзкейсами.
Здравствуйте, netch80, Вы писали:
_>> Кстати, аналогичного можно добиться и проще (как раз более практичный вариант) — фиксация своих изменений несколькими разработчиками в одну и ту же ветку, с последующей синхронизацией.
N>Пофиг, как ветка называется у каждого конкретного разработчика,
Не пофиг. Ветки именуются по фичам\багам. Смотришь откуда пришел коммит — сразу видишь что хотел сказать автор.
N> важно, в какую в общем репо они вливают
? W>Всегда бесила работа с ветками в гите которые были удалены.
В Maercurial для работы с ветвлением можно использовать один из трёх (а можно и все вместе кстати) инструментов: анонимные ветки, именованные ветки, закладки (практически полный аналог веток git'a). Так вот, если использовать за основу именованные ветки, то это полностью решает описанную проблему.
Здравствуйте, willie, Вы писали:
w> _>Mercurial лучше — абсолютно те же самые технические возможности, но при этом более удобно. Хотя если делать всё через GUI или вообще из какой-нибудь IDE, то скорее всего разницы не увидишь.
w> Интересно сравнить. Меркуриал может решить проблему описаную тут http://rsdn.ru/forum/flame.comp/6352935.1
? w> Всегда бесила работа с ветками в гите которые были удалены.
А можно описать для чего это? Вот например была ветка feature1,которая потом влилась в ветку megafeatureX, которая в итоге влилась в ветку release2016.1, которая потом стала как бы "read only"(тагом например). Что нам дает то что мы знаем что коммит X был в рамках ветки feature1, а коммит Y только в рамках ветки megafeatureX?
Здравствуйте, willie, Вы писали:
w> W>>Как понять в рамках какой ветки изначально был запилен тот или иной коммит? w> ·>Никак. w> Очень плохо. А в hg так можно? Тогда стоит его посмотреть на замену гиту w> ·>А зачем? w> Например чтобы откатить все что наваял нерадивый юниор. Для начала надо все это как-то найти. Желательно удобнее чем с помощью команды w>
w> как мне тут советуют в соседней ветке и на стеке Ведь это гит для нас, а не мы для гита
Хм, а зачем тогда такие аттрибуты коммита как Author и Committer(не знаю есть ли такое в mercurial)?
Здравствуйте, alex_public, Вы писали:
_>>>Конечно самый частый и поэтом за него у mercurial отвечает просто "commit", а у git зачем-то "commit -a". А вот аналогом "commit -A" из mercurial будет уже "add . ; commit" из git. Хотя на самом деле все эти различия в параметрах — это естественно мелочи. Но я в любом случае не понимаю смысла существования такой штуки как stage в git. _>·>Удобно. Коммит можно собирать по частям, серией различных команд. _>·>Ещё удобно при разрешении конфликтов — при мерже неконфликтующие файлы идут в индекс, а кофликтующие не идут. Потом удобно по мере разрешения конфликтов добавлять разрешенное в индекс. _>·>В общем, попробуешь — понравится. _>Чтобы сделать частичную фиксацию эта сущность точно не нужна (hg commit -i тому доказательство). А какие ещё полезные сценарии могут быть? )
commit -i заставляет сделать всё одной командой — выбирать сразу. серия команд "add", "add -p" упрощает жизнь.
Например, IDEA не поддерживает (интересно, а какие поддерживают?) интерактивный коммит, может добавлять только файлы. У меня есть возможность добавить какие-то файлы из UI, а какие-то по-hunk-ово из командной строки.
_>·>Все push можно сделать одной командой. Тогда и получится столько же или даже меньше. _>·>Например можно сделать так так: _>·>... _>·>В итоге в начальном репозитории будет две ветки — одна master — с замерженным решением и вторая alternativeUnmergedSolution. _>Да, но тогда во втором репозитории будет некая ересь. ) Причём степень её бредовости будет зависеть от выбранного варианта.)
Что значит ересь? Граф истории — идентичен. Только имена веток отличаться будут.
_>P.S. Вообще не очень понимаю смысл этих твоих дальнейших упражнений, после того как правильное решение уже было найдено. )
Я вначале привёл решения наиболее осмысленные, более юзер-френдли, поэтому чуть больше команд. Если же делать по минимуму — то команд будет меньше, результат тот же, смысла столько же как и с анонимными ветками в hg.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, willie, Вы писали:
W>>>Как понять в рамках какой ветки изначально был запилен тот или иной коммит? W>·>Никак. W>Очень плохо. А в hg так можно? Тогда стоит его посмотреть на замену гиту
Можно, для небольшого проекта с центральным репозиторием, как CVCS hg ещё ок, в качестве альтернативы svn. Хотя в случае централизованной разработки лучше взять gerrit.
W>·>А зачем? W>Например чтобы откатить все что наваял нерадивый юниор. Для начала надо все это как-то найти. Желательно удобнее чем с помощью команды
Найти точку нерадивого мержа, заревертить её. Не вижу проблемы.
W>·>Если надо поместить какую-то информацию в коммит, скажем bug id — просто добавь это в сообщение коммита. И не ограничивай себя только именем ветки, а добавляй что надо — номер спринта, идентификатор истории, фамилию проджект-менеджера, уровень алкоголя в крови, и т.п. W>Проще в экселе это записывать. А исходники архивировать и на дискету. Удобней гита всяко
Если у тебя такой небольшой простой проект, что имени ветки хватает — то экзель вполне серьёзный конкурент.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Но я пока не натыкался на внятное описание такой.
ну или я вообще не догоняю философию гита