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

N>>Это забавно звучит в контексте темы про Git, но предположим. В таком случае второй махонький вопрос: каким образом ты собрался в обстановке, где, грубо говоря, 30 активных разработчиков на одной репе, всех сдвинуть разрабатывать ветку начиная с одного конкретного коммита? В терминах Hg, насколько я помню — как всем задать новый tip? И чем это будет отличаться от Git'овых мер типа "всем сделать pull этого коммита как master", если всё равно всем на местах надо что-то сделать самим и явно?
_>Вот как раз в Mercurial вообще ничего со всем этим делать не надо — всё работает автоматически. И tip сам скакнёт на новые ревизии в новом ответвление.
git работает ровно точно так же в обсуждаемом сценарии. Единственная разница с hg — это то что hg не умеет в rebase.

_>Единственное, о чём надо позаботиться при таком решение, это о том, чтобы никто не присылал свои апдейты в тупиковую ветку.
А что этот кто-то будет делать, если кто-то уже сделал у себя локальные коммиты на этой ветке, ставшей внезапно тупиковой? А потом ещё этими коммитами с кем-то ещё поделился?
Более того, как это вообще можно просто даже теоретически запретить в _distributed_ vcs?

_>Это можно сделать как административным путём (скажем на совещание),
Вот потому hg и не выжил, т.к. он не является полноценной DVCS и требует централизованных совещаний. Иначе полный абзац.

_>так и банальным техническим средствами, в DVCS. Для этого в Mercurial достаточно написать что-то типа: hg commit --close-branch -m "Тупиковая ветка развития — неудачная попытка применения умножения".
Мде. А git revert <неудачный коммит> слишком просто, да? Не... лучше создадим ещё одну супер-пупер нахрен ненужную фичу чтобы были поводы устраивать совещания.

_>Ну или если в проекте используются bookmarks, то можно их просто переставить. )
Это анриал для команды более N человек, где N ничтожно мало.

_>Git в этом смысле действительно намного ограничен, что неоднократно обсуждалось уже давным давно. Например вот https://habr.com/ru/post/123700/ или https://www.b-list.org/weblog/2010/feb/02/branching/ и ещё много много таких обсуждений можно найти за последние 10 лет.
Это просто чувак пришел с CVS/SVN, не понимает что значит distributed, тащит свои привычки. 10 лет назад такие статейки ещё можно понять... но сейчас это просто агрессивное невежество.

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

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

2. Мне нужно знать какое изменение было первым в ветке «release», потому что я хочу начать новую тематическую ветку с этого изменения в качестве начальной точки так...

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

3. Мне нужно знать где началась ветка «topic» для того, чтобы я мог сложить все патчи вместе и отослать их своим коллегам для рецензии.

PR? gerrit changesets? "git format-patch" в конце концов?

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

_>>Ну да, мы уже все поняли, что в твоём особом мирке разработчики никогда не ошибаются, можешь не повторяться. )
·>Он имеет в виду, что те ошибки, которые у тебя засоряют публичную историю и требуют разборы полётов всей командой, в его мирке отлавливаются на раз автоматически через CI, являются личным делом каждого разработчика и не видны другим. Быстро и незаметно исправленная ошибка допущенной не считается.

Угу, а уж тесты точно даны нам свыше и не способны пропустить ни одной ошибки (про ошибки в написание самих тестов я уже молчу — это просто ересь!).

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

_>>Вот как раз в Mercurial вообще ничего со всем этим делать не надо — всё работает автоматически. И tip сам скакнёт на новые ревизии в новом ответвление.
·>git работает ровно точно так же в обсуждаемом сценарии. Единственная разница с hg — это то что hg не умеет в rebase.

Rebase что в Git, что в Mercurial работает одинаково. В этой темке шло обсуждение именно недостатков самого подхода сплошных rebase'ов в коде, вне привязки к конкретной DVCS.

_>>Единственное, о чём надо позаботиться при таком решение, это о том, чтобы никто не присылал свои апдейты в тупиковую ветку.
·>А что этот кто-то будет делать, если кто-то уже сделал у себя локальные коммиты на этой ветке, ставшей внезапно тупиковой? А потом ещё этими коммитами с кем-то ещё поделился?
·>Более того, как это вообще можно просто даже теоретически запретить в _distributed_ vcs?

А главный защитник Git в этой темке наоборот говорил, что без центрального репозитория нормальной работы нет. Более того, поверх него надо ещё повесить совсем централизованную веб-хрень (типа Gerrit) и только тогда нормальная работа пойдёт... )))

_>>Это можно сделать как административным путём (скажем на совещание),
·>Вот потому hg и не выжил, т.к. он не является полноценной DVCS и требует централизованных совещаний. Иначе полный абзац.

Похоже у кого-то проблемы с базовым чтением и понимаем текста. )))

_>>так и банальным техническим средствами, в DVCS. Для этого в Mercurial достаточно написать что-то типа: hg commit --close-branch -m "Тупиковая ветка развития — неудачная попытка применения умножения".
·>Мде. А git revert <неудачный коммит> слишком просто, да? Не... лучше создадим ещё одну супер-пупер нахрен ненужную фичу чтобы были поводы устраивать совещания.


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

_>>Ну или если в проекте используются bookmarks, то можно их просто переставить. )
·>Это анриал для команды более N человек, где N ничтожно мало.

Речь была естественно про shared bookmarks, а не local. Так что всё спокойно работало бы автоматом. Но вообще это всё слишком похожий на Git путь, который не нужен при нормальной разработке с использованием более удобных branches.

_>>Git в этом смысле действительно намного ограничен, что неоднократно обсуждалось уже давным давно. Например вот https://habr.com/ru/post/123700/ или https://www.b-list.org/weblog/2010/feb/02/branching/ и ещё много много таких обсуждений можно найти за последние 10 лет.
·>Это просто чувак пришел с CVS/SVN, не понимает что значит distributed, тащит свои привычки. 10 лет назад такие статейки ещё можно понять... но сейчас это просто агрессивное невежество.

Это всё очень похоже на некоторых фанатиков из мира Apple. Которые годами говорили, что некая возможность просто не нужна и всё. Правда как только она появлялась и в их устройствах, то тут же от этих же товарищей слышалось о суперудобстве этой новейшей возможности! Правда в случае Git боюсь мы такого никогда не услышим, т.к. там не видно намерения развиваться. Так и будем слышать только вечные "да это просто не нужно!"...

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

_>·>Он имеет в виду, что те ошибки, которые у тебя засоряют публичную историю и требуют разборы полётов всей командой, в его мирке отлавливаются на раз автоматически через CI, являются личным делом каждого разработчика и не видны другим. Быстро и незаметно исправленная ошибка допущенной не считается.
_>Угу, а уж тесты точно даны нам свыше и не способны пропустить ни одной ошибки (про ошибки в написание самих тестов я уже молчу — это просто ересь!).
Способны, конечно. И будет ошибка. Но опять же — быстро и незаметно исправленная ошибка допущенной не считается.
Более того, ты применяешь софистический приём: "раз мы можем пропустить хоть одну ошибку, значит это всё ересь". Нет, конечно, это просто нежелание признать свою неправоту. Если быстро и незаметно отлавливается 99 из 100 ошибок — это уже невероятно круто.

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

_>>>Вот как раз в Mercurial вообще ничего со всем этим делать не надо — всё работает автоматически. И tip сам скакнёт на новые ревизии в новом ответвление.
_>·>git работает ровно точно так же в обсуждаемом сценарии. Единственная разница с hg — это то что hg не умеет в rebase.
_>Rebase что в Git, что в Mercurial работает одинаково. В этой темке шло обсуждение именно недостатков самого подхода сплошных rebase'ов в коде, вне привязки к конкретной DVCS.
В mercurial он неюзабельный. По крайней мере уж точно был таковым на момент когда git побеждал.

_>·>А что этот кто-то будет делать, если кто-то уже сделал у себя локальные коммиты на этой ветке, ставшей внезапно тупиковой? А потом ещё этими коммитами с кем-то ещё поделился?
_>·>Более того, как это вообще можно просто даже теоретически запретить в _distributed_ vcs?
_>А главный защитник Git в этой темке наоборот говорил, что без центрального репозитория нормальной работы нет. Более того, поверх него надо ещё повесить совсем централизованную веб-хрень (типа Gerrit) и только тогда нормальная работа пойдёт... )))
Про централизацию это ты сам додумал. netch80 писал не про централизацию, а про "peer review, интеграция с CI и прочая" — это и есть основная цель всяких веб-хренеий. И это верно для любой vcs.
Более того, один и тот же проект в git может быть разделён между командами и "центров" будет несколько.

_>>>так и банальным техническим средствами, в DVCS. Для этого в Mercurial достаточно написать что-то типа: hg commit --close-branch -m "Тупиковая ветка развития — неудачная попытка применения умножения".
_>·>Мде. А git revert <неудачный коммит> слишком просто, да? Не... лучше создадим ещё одну супер-пупер нахрен ненужную фичу чтобы были поводы устраивать совещания.
_>
_>Ты бы хоть прочитал о чём речь была в данной темке, прежде чем так гордо в неё врываться и нести чушь. Задача как раз в том и стояла, чтобы сохранить неудачную ревизию в репозитории,
_> при этом исключив её из основной ветки разработки.
А подумать? Куда по-твоему исчезнет неудачная ревизия после git revert?

_>>>Ну или если в проекте используются bookmarks, то можно их просто переставить. )
_>·>Это анриал для команды более N человек, где N ничтожно мало.
_>Речь была естественно про shared bookmarks, а не local. Так что всё спокойно работало бы автоматом.
Это фантазии теоретега. Букмарки неюзабельны, я это уже раскрывал выше

Автор: ·
Дата: 12.11.19

.

_>Но вообще это всё слишком похожий на Git путь, который не нужен при нормальной разработке с использованием более удобных branches.
Такие бранчи не дают никакой практической ценности. Они хороши лишь тактически, для переезжающих с cvcs, чтобы не так сразу ломать привычные подходы, но стратегически идут в топку.

_>>>Git в этом смысле действительно намного ограничен, что неоднократно обсуждалось уже давным давно. Например вот https://habr.com/ru/post/123700/ или https://www.b-list.org/weblog/2010/feb/02/branching/ и ещё много много таких обсуждений можно найти за последние 10 лет.
_>·>Это просто чувак пришел с CVS/SVN, не понимает что значит distributed, тащит свои привычки. 10 лет назад такие статейки ещё можно понять... но сейчас это просто агрессивное невежество.
_>Это всё очень похоже на некоторых фанатиков из мира Apple. Которые годами говорили, что некая возможность просто не нужна и всё. Правда как только она появлялась и в их устройствах, то тут же от этих же товарищей слышалось о суперудобстве этой новейшей возможности! Правда в случае Git боюсь мы такого никогда не услышим, т.к. там не видно намерения развиваться. Так и будем слышать только вечные "да это просто не нужно!"...
Ничего подобного. Это типичный подход новичков и некомпетентных товарищей, которые путают цель и средство. Погляди как построены его хотелки "мне нужно X, чтобы получить Y" — типичное заблуждение — Y можно получить другими способами.
Классика же, отсюда:

Вопрос: Как можно с помощью X сделать Y?
Ответ: Если вы хотите сделать Y, надо так и спрашивать, не предполагая заранее использование метода, который может вовсе не подходить. Вопросы такого вида часто задают те, кто не просто ничего не знает об X, но сбит с толку решаемой проблемой Y и слишком сконцентрирован на деталях своей конкретной ситуации. Обычно лучше игнорировать таких людей, пока они не сформулируют свою проблему лучше.

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

_>>Угу, а уж тесты точно даны нам свыше и не способны пропустить ни одной ошибки (про ошибки в написание самих тестов я уже молчу — это просто ересь!).
·>Способны, конечно. И будет ошибка. Но опять же — быстро и незаметно исправленная ошибка допущенной не считается.
·>Более того, ты применяешь софистический приём: "раз мы можем пропустить хоть одну ошибку, значит это всё ересь". Нет, конечно, это просто нежелание признать свою неправоту. Если быстро и незаметно отлавливается 99 из 100 ошибок — это уже невероятно круто.

Вообще то ересью я тут назвал мысль о том, что в тесты может закрасться ошибка. И это был естественно сарказм, видимо слишком тонкий. )))

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

_>>
_>>Ты бы хоть прочитал о чём речь была в данной темке, прежде чем так гордо в неё врываться и нести чушь. Задача как раз в том и стояла, чтобы сохранить неудачную ревизию в репозитории,
_>> при этом исключив её из основной ветки разработки.
·> А подумать? Куда по-твоему исчезнет неудачная ревизия после git revert?

Так, ты похоже вообще не понял о чём речь. Давай разберёмся, если уж ты настаиваешь. И так, у нас есть такой https://github.com/rabovik/RebaseVSMergeExample репозиторий. В нём есть две ветки, для демонстрации различия двух разных подходов (merge и rebase) при одной и той же ошибке. Соответственно последняя ревизия в каждой ветке сломана, вследствие ошибки (невнимательности) человека. Причём ошибка происходит из-за слияния двух абсолютно не совместимых решений по коду и соответственно её исправление выражается в устранение неподходящего кода. В данном примере неверным решением является ревизия Пети (применение умножения), а правильным кодом (во всяком случае в ветке merge ) является ревизия Васи (там где в коде написано 2+3=5 — так и должно быть по ТЗ), которая и должна оказаться итоговой в репозитории.

Теперь собственно задачка: исправить ситуацию, средствами DCVS (т.е. не залезая в редакторы кода и т.п.). При этом надо чтобы ошибочная ревизия Пети всё же осталась в репозитории (так сказать уроком на будущее), но никак не влияла на основную ветку развития.

Так вот, на мой взгляд в случае ветки rebase это сделать невозможно в принципе, ни в какой DCVS. В случае ветки merge, это сделать возможно и в git и в mercurial. Только в последней намного удобнее. )

_>>Речь была естественно про shared bookmarks, а не local. Так что всё спокойно работало бы автоматом.
·>Это фантазии теоретега. Букмарки неюзабельны, я это уже раскрывал выше

Автор: ·
Дата: 12.11.19

.

Согласен, не особо нужная хрень, полезная в основном для эмуляции кривых подходов git'а, тем кто к ним привык...

_>>Но вообще это всё слишком похожий на Git путь, который не нужен при нормальной разработке с использованием более удобных branches.
·>Такие бранчи не дают никакой практической ценности. Они хороши лишь тактически, для переезжающих с cvcs, чтобы не так сразу ломать привычные подходы, но стратегически идут в топку.

Очень аргументированное мнение...)))

_>>>>Git в этом смысле действительно намного ограничен, что неоднократно обсуждалось уже давным давно. Например вот https://habr.com/ru/post/123700/ или https://www.b-list.org/weblog/2010/feb/02/branching/ и ещё много много таких обсуждений можно найти за последние 10 лет.
_>>·>Это просто чувак пришел с CVS/SVN, не понимает что значит distributed, тащит свои привычки. 10 лет назад такие статейки ещё можно понять... но сейчас это просто агрессивное невежество.
_>>Это всё очень похоже на некоторых фанатиков из мира Apple. Которые годами говорили, что некая возможность просто не нужна и всё. Правда как только она появлялась и в их устройствах, то тут же от этих же товарищей слышалось о суперудобстве этой новейшей возможности! Правда в случае Git боюсь мы такого никогда не услышим, т.к. там не видно намерения развиваться. Так и будем слышать только вечные "да это просто не нужно!"...
·>Ничего подобного. Это типичный подход новичков и некомпетентных товарищей, которые путают цель и средство. Погляди как построены его хотелки "мне нужно X, чтобы получить Y" — типичное заблуждение — Y можно получить другими способами.

Ну да, только в данном контексте X — это удобство. И конечно никто не спорит, что с помощью git можно решить большинство задач, ставящихся перед DVCS. Просто некоторым желательно ещё и удобство, помимо просто решения.

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


_>Теперь собственно задачка: исправить ситуацию, средствами DCVS (т.е. не залезая в редакторы кода и т.п.). При этом надо чтобы ошибочная ревизия Пети всё же осталась в репозитории (так сказать уроком на будущее), но никак не влияла на основную ветку развития.
Это я всё понял. Ты лучше объясни чем тебя не устраивает git revert <ревизия Пети> как решение этой задачки? (И пофиг — rebase или merge)

_>Так вот, на мой взгляд в случае ветки rebase это сделать невозможно в принципе, ни в какой DCVS. В случае ветки merge, это сделать возможно и в git и в mercurial. Только в последней намного удобнее. )
Объясни подробнее какое удобство ты имеешь ввиду.

_>>>Но вообще это всё слишком похожий на Git путь, который не нужен при нормальной разработке с использованием более удобных branches.
_>·>Такие бранчи не дают никакой практической ценности. Они хороши лишь тактически, для переезжающих с cvcs, чтобы не так сразу ломать привычные подходы, но стратегически идут в топку.
_>Очень аргументированное мнение...)))
А что тут я могу аргументировать? Это ты заявляешь о наличии преимуществ, тебе и доказывать их наличие. Более того, ещё важно отсутствие недостатков, которые сведут преимущества в ноль.
Впрочем, практика — критерий истины, и hg практически умер.

_>Ну да, только в данном контексте X — это удобство. И конечно никто не спорит, что с помощью git можно решить большинство задач, ставящихся перед DVCS. Просто некоторым желательно ещё и удобство, помимо просто решения.
Это ты сам додумал. В данном контексте X это наличие hg-like бранчей. И перечисленные в той статье хотелки решаются точно так же просто без них.

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

N>>О, опять пошла художественная резьба по аргументам.
_>Ну да, такая вот интересная художественная резьба, в которой почему-то всё твоё сообщение процитировано целиком и дословно...

Не по тексту, а по аргументам. Это надо, да, прочитать, чтобы увидеть разницу

N>>Сначала уничижаешь "красивую историю" (обязательно в кавычках, чтобы обиднее было), сводя идею чёткого, полного и однозначного выражения мысли и сути изменения к украшательствам.
N>>Потом вводишь какую-то "проверку" ошибочного пути, хотя ~99% подобных промежуточных состояний не являются чем-то, "проверка" чего стоит внимания — это просто тупые человеческие ошибки типа недоработки 1 случая из 20, "глаз замылился" и всё такое. Случай статьи с кривым мержем входит в это множество случаев, там нет ничего ценного для истории.
_>В случае примера из статьи, полезным для будущего тупиковым вариантом является естественно не ошибочное слияние, а ревизия Пети, в которой имеется попытка использования в проекте умножения, вместо сложение. Как видно, умножение в этом проекте не подходит, что крайне полезно зафиксировать на будущее.

"Полезно зафиксировать на будущее" — твои домыслы, которым нет никакого реального обоснования или даже намёка в статье.

N>>Наконец, добавляешь аргумент в пользу своего любимого тула.
N>>А теперь ма-ахонький вопрос: кто и когда вообще будет заглядывать в эту побочную ветку в поисках великой мудрости ошибочных путей? Что подвигнет его смотреть именно в это место, или выбирать хотя бы десяток таких из тысяч других?
_>Напомню, что у ревизий имеется такая вещь, как описание. Это, если ты забыл, такое текстовое поле... ))) А ещё, существуют удобные GUI средства (типа TortoiseHg), которые позволяют эффективно просматривать графы репозитория...

Самый важный вопрос тут:

>> кто и когда вообще будет заглядывать в эту побочную ветку в поисках великой мудрости ошибочных путей?

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

Так всё-таки — кто и зачем будет смотреть в эту ревизию?

_>>>Хотя да, в git, если не дать этой ревизии отдельное имя ветки (типа "ошибочная попытка использовать умножение"), то со временем сборщик мусора её сотрёт. А вот в Mercurial всё автоматически сохранится и без этого — будет просто такой вот маленький анонимный отросток от основной ветки.
N>>Это забавно звучит в контексте темы про Git, но предположим. В таком случае второй махонький вопрос: каким образом ты собрался в обстановке, где, грубо говоря, 30 активных разработчиков на одной репе, всех сдвинуть разрабатывать ветку начиная с одного конкретного коммита? В терминах Hg, насколько я помню — как всем задать новый tip? И чем это будет отличаться от Git'овых мер типа "всем сделать pull этого коммита как master", если всё равно всем на местах надо что-то сделать самим и явно?
_>Вот как раз в Mercurial вообще ничего со всем этим делать не надо — всё работает автоматически. И tip сам скакнёт на новые ревизии в новом ответвление.

Ты не пробовал смотреть чуть дальше, чем на полшага вперёд?

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

_> Единственное, о чём надо позаботиться при таком решение, это о том, чтобы никто не присылал свои апдейты в тупиковую ветку. Это можно сделать как административным путём (скажем на совещание),

Именно, то есть технические средства тут не сработают.

_> так и банальным техническим средствами, в DVCS. Для этого в Mercurial достаточно написать что-то типа: hg commit --close-branch -m "Тупиковая ветка развития — неудачная попытка применения умножения".

Как романтично конечно, после того, как ввели множественные головы, надо закостылить, чтобы они не анноили всех. Ну это я даже поддержу — в том смысле, что если уж навязали чушь, то её хотя бы надо облагородить.

Но тогда возвращаемся к предыдущему вопросу. Кто и зачем и как будет смотреть в репозиторий в поиске тупиковых путей? Ты это реально пробовал при наличии хотя бы сотни таких заглушек? Ты понимаешь, что описания в коммитах (ты ведь публичные коммиты не меняешь, даже если они close-branch?) могут не соответствовать по стилю и даже по терминологии тому, что будет искаться позже, даже через пару лет? И зачем метить все тупиковые варианты, когда >99% из них вообще никогда дальше не будут пробоваться? Или ты таки не все предполагаешь так фиксировать, а только избранные?

_>Git в этом смысле действительно намного ограничен, что неоднократно обсуждалось уже давным давно. Например вот https://habr.com/ru/post/123700/ или https://www.b-list.org/weblog/2010/feb/02/branching/ и ещё много много таких обсуждений можно найти за последние 10 лет.

Очень смешные ссылки — показывают ограниченность мышления авторов:

>> Вот этот граф. Можете ли вы мне сказать, на какую ветку было зафиксировано изменение ab3e2afd?

На ту ветку (или может быть, не ветку), которая записана в сообщении коммита. Какая разница?
Вот вчера я закоммитил нечто на ветку master, потом черипикнул в mr81 и mr80. Изменение "мы не используем файл XXX уже год — коллега Дмитрий, снеся код неиспользуемого режима multi-process, пропустил этот файл". Имеет значение ветка? Нет, имеет значение, что сообщение коммита начинается с идентификатора тикета.
Или вы не верите надёжности трекера? OK, можно писать происхождение изменений туда же в любом пригодном к чтению виде, хоть в виде иерархии обозначений.

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

Или оно входит в дифф от предыдущего релиза, или не входит. Если входит, его надо описывать или нет — зависит от политики описания.

>> Я не показываю вам журнал изменений. Но поверьте мне, вы не захотите его видеть. Он не поможет. Вы думаете, одомашненные приматы[1] записали там полезные подсказки, которые ответили бы вам на эти вопросы, но они не сделали этого. Хуже того, иногда они врут.

Хорошее отношение к сотрудникам, нечего сказать. Но ещё непонятно, зачем вообще отдельный changelog. Можно было бы сказать, что он предполагает качественное ведение этого журнала, но зачем он при наличии VCS (даже не распределённой!)? Хотя, если там такие сотрудники, что пишут сообщения коммита только одним словом "update" или "fixed", понятно, зачем им автоподстановка ветки: это даёт хоть какую-то надежду, что будет понятно, зачем это изменение было нужно.

>> Какое было самое ранее изменение на ветке «release»?

И снова смотрим от точки форка от чего-то предыдущего.

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

Если "чистое слияние" это "от точки начала release"... oook. Чистоту это реально никак не даёт, но "блажен, кто верует".

>> Каждый узел в графе раскрашен, чтобы показать имя своей ветки в Mercurial. Всякая угадайка становится не нужна. Вы твёрдо знаете, что когда-то была ветка с именем «temp», которая затем влилась в ветку «release», а не «master».

Temp — кривое имя, но предположим, что это было какое-нибудь new_ui. Писать другим образом в сообщении коммита он тоже не умеет, ну пусть. Но откуда идея, что new_ui будет влито только в release, но не в master? Зачем такое ограничение?

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

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

>> The other problem I have with git’s branching is that it really overloads multiple meanings of “branch” in a way that isn’t particularly useful.

Смешно читать это при 4 разных смыслах branch в Hg

>> and so far as I know git doesn’t have a way to indicate to your colleagues that you’re done with a branch; the only way to do this is to delete it, or to hope they see the final merge commit and understand that the branch is closed to further development

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

Мне вот про этих авторов стало слегка интересно. Пока что массовые ссылки в твою сторону относились приблизительно к 2010-2011 (англоязычные) или до 2013 (русскоязычные). Сейчас эти авторы думают так же? Или они таки поняли, что их "концептуальный блок" квадратно-гнездовой разработки потерял актуальность?

S>>git почему-то является камнем предкновения для многих разработчиков

S>Он действительно не прост и выше я уже писал, что можно понять уровень кандидата обсуждая с ним работу гита: dag, абстракции(коммит, ветка, тэг), алгоритмы слияния и т.д.
S>Это действительно серьезный инструмент. Я до сих пор кучу вещей о нем не знаю и не понимаю, хотя работаю с ним кучу лет. Отчасти, потому что над кодовой базой
S>работаю один и со многими вещами просто не сталкивался, хотя в detached head регулярно влетаю.
Ты всегда спрашиваешь людей как работать с блокнотом или там умеет ли он ставить закладки в Хроме?
Это зранилище данных! Оно должно быть примитивно простым для юзверя.

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

S>>Он действительно не прост и выше я уже писал, что можно понять уровень кандидата обсуждая с ним работу гита: dag, абстракции(коммит, ветка, тэг), алгоритмы слияния и т.д.
S>>Это действительно серьезный инструмент. Я до сих пор кучу вещей о нем не знаю и не понимаю, хотя работаю с ним кучу лет. Отчасти, потому что над кодовой базой
S>>работаю один и со многими вещами просто не сталкивался, хотя в detached head регулярно влетаю.
В>Ты всегда спрашиваешь людей как работать с блокнотом или там умеет ли он ставить закладки в Хроме?
В>Это зранилище данных! Оно должно быть примитивно простым для юзверя.
Надо не забывать, что это распределённая многопользовательская система. Просто там не получится.
Так что надо сравнивать надо не с блокнотом, а, например, с google docs — как оно обеспечивает редактирование одного документа несколькими пользователями одновременно.

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

Б>Можно пример, что не так? И как это могло бы быть лучше.

В git нельзя сделать копию файла с сохранением истории.

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

BFE>В git нельзя сделать копию файла с сохранением истории.

А можно юзкейс когда это требуется?

Работал в одном проекте, в качестве VCS использовалась древняя версия SourceOffSite (версия 4.что-то-там).
В нескольких проектах использовались копии одного .h файла. SoS как раз умела распознавать, что несколько экземпляров файла это один и тот же файл.
Чооррррд, как же это было неудобно!
Если ты его checkout'ишь, то он лочится везде.
Если надо в него внести изменения, то надо руками поправить все файлы, чтобы все проекты собирались.
А коммитить надо только один файл (именно тот, которому сделал checkout), а остальные сперва отменить правку, а потом проапдейтить.

В общем копии это зло!
Проще вынести в отдельный каталог и настроить пути.

Здравствуйте, Stanislav V. Zudin, Вы писали:

BFE>>В git нельзя сделать копию файла с сохранением истории.
SVZ>А можно юзкейс когда это требуется?

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

SVZ>Работал в одном проекте, в качестве VCS использовалась древняя версия SourceOffSite (версия 4.что-то-там).
SVZ>В нескольких проектах использовались копии одного .h файла. SoS как раз умела распознавать, что несколько экземпляров файла это один и тот же файл.
SVZ>Чооррррд, как же это было неудобно!
SVZ>Если ты его checkout'ишь, то он лочится везде.
SVZ>Если надо в него внести изменения, то надо руками поправить все файлы, чтобы все проекты собирались.
SVZ>А коммитить надо только один файл (именно тот, которому сделал checkout), а остальные сперва отменить правку, а потом проапдейтить.

SVZ>В общем копии это зло!
SVZ>Проще вынести в отдельный каталог и настроить пути.

Это другой случай

Автор: B0FEE664
Дата: 29.10.19

, но и этот сценарий тоже должен нормально работать.

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

BFE>>>В git нельзя сделать копию файла с сохранением истории.
SVZ>>А можно юзкейс когда это требуется?
BFE>Например, нужно разделить класс на два класса: базовый и наследник. Получается, что один файл будет иметь историю, а другой — нет.
Типичное заблуждение. Для этого не нужно отслеживать историю файла, а нужно отслеживать историю контента. Ведь даже этом твоём сценарии "разделить класс на два" — какой файл должен скопирован/перемещён в какой и почему? А чуть более другой сценарий (например, слить два класса в один) — и вообще никак файловыми операциями не сделаешь.
А вот git как раз и позволяет отслеживать контент. Скажем, в IDEA есть такая фича "Show History for Selection" — выделяешь кусок кода (метод, например) и смотришь его полную историю, в т.ч. перемещение между файлами.

Другое дело, если криворукий программист вместо небольших коммитов с небольшими простыми рефакторингами делает одно супер-пупер изменение, которое меняет всё и сразу, то git отследить не сможет (да и сам программист тоже, наверняка).

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

BFE>>>>В git нельзя сделать копию файла с сохранением истории.
SVZ>>>А можно юзкейс когда это требуется?
BFE>>Например, нужно разделить класс на два класса: базовый и наследник. Получается, что один файл будет иметь историю, а другой — нет.
·>Типичное заблуждение. Для этого не нужно отслеживать историю файла, а нужно отслеживать историю контента. Ведь даже этом твоём сценарии "разделить класс на два" — какой файл должен скопирован/перемещён в какой и почему?

Что значит — "заблуждение"? Мне нужно видеть историю класса и знать, когда он был един и когда его разделили на два и какой код в каком файле оказался.

·>Ведь даже этом твоём сценарии "разделить класс на два" — какой файл должен скопирован/перемещён в какой и почему?

Это я сам решаю. Вот есть файл, скажем, Class.h, я делаю его копию ClassBase.h, после чего переименовываю Class.h в ClassDerived.h. после чего меняю код в ClassDerived.h и в ClassBase.h. Затем делаю коммит. Всё. У обоих файлов есть полная история и все изменения. В svn всё работает, а вот git, оказывается, мне это не нужно?

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

·>А чуть более другой сценарий (например, слить два класса в один) — и вообще никак файловыми операциями не сделаешь.
А причём тут файловые операции, если речь про операции системы контроля версий? Вы в курсе про git mv? Вот почему git mv есть, а git cp — нет?

Мне ни разу на практике не приходилось сливать два файла в один, но в принципе операция слияния может быть предусмотрена.

·>А вот git как раз и позволяет отслеживать контент. Скажем, в IDEA есть такая фича "Show History for Selection" — выделяешь кусок кода (метод, например) и смотришь его полную историю, в т.ч. перемещение между файлами.

Я не знаю про IDEA, но как в git отследить историю для скопированного файла?

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

BFE>>>Например, нужно разделить класс на два класса: базовый и наследник. Получается, что один файл будет иметь историю, а другой — нет.
BFE>·>Типичное заблуждение. Для этого не нужно отслеживать историю файла, а нужно отслеживать историю контента. Ведь даже этом твоём сценарии "разделить класс на два" — какой файл должен скопирован/перемещён в какой и почему?
BFE>Что значит — "заблуждение"? Мне нужно видеть историю класса и знать, когда он был един и когда его разделили на два и какой код в каком файле оказался.
Заблуждение в том, что история класса выражается в виде истории имени файла.

BFE>·>Ведь даже этом твоём сценарии "разделить класс на два" — какой файл должен скопирован/перемещён в какой и почему?
BFE>Это я сам решаю. Вот есть файл, скажем, Class.h, я делаю его копию ClassBase.h, после чего переименовываю Class.h в ClassDerived.h. после чего меняю код в ClassDerived.h и в ClassBase.h. Затем делаю коммит. Всё. У обоих файлов есть полная история и все изменения. В svn всё работает, а вот git, оказывается, мне это не нужно?
В git тоже всё будет работать, т.к. он отследит что в этом коммите _содержимое_ класса Class.h очень похоже на ClassDerived.h и/или ClassBase.h. Имя файла не важно, главное _содержимое_.

BFE>Я понимаю, что об истории заботятся не все и многие просто локально копируют файлы создавая новые и теряя историю изменений. Тогда, конечно, svn историю не отследит. Предлагаю не равнятся на таких ламеров.
Подход git будет работать и в таком случае.

BFE>·>А чуть более другой сценарий (например, слить два класса в один) — и вообще никак файловыми операциями не сделаешь.
BFE>А причём тут файловые операции, если речь про операции системы контроля версий? Вы в курсе про git mv? Вот почему git mv есть, а git cp — нет?

Git has a rename command git mv, but that is just a convenience. The effect is indistinguishable from removing the file and adding another with different name and the same content

По сути не нужно для истории, хотя вроде там есть ещё какие-то дополнительные safety checks и апдейтит индекс заодно.

BFE>Мне ни разу на практике не приходилось сливать два файла в один,
"значит это никому не нужно"?

А кусок кода из одного файла в другой перемещать приходилось? svn/whatever тебе в этом хоть как-то помог?

BFE>но в принципе операция слияния может быть предусмотрена.
Нет уж, оккамом такое надо резать.

BFE>·>А вот git как раз и позволяет отслеживать контент. Скажем, в IDEA есть такая фича "Show History for Selection" — выделяешь кусок кода (метод, например) и смотришь его полную историю, в т.ч. перемещение между файлами.
BFE>Я не знаю про IDEA, но как в git отследить историю для скопированного файла?
git log --follow <filename>

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

BFE>>Что значит — "заблуждение"? Мне нужно видеть историю класса и знать, когда он был един и когда его разделили на два и какой код в каком файле оказался.
·>Заблуждение в том, что история класса выражается в виде истории имени файла.
Я знаю текущее имя файла, значит я знаю, как посмотреть когда данный класс в нём появился.

·>В git тоже всё будет работать, т.к. он отследит что в этом коммите _содержимое_ класса Class.h очень похоже на ClassDerived.h и/или ClassBase.h. Имя файла не важно, главное _содержимое_.
Содержимое не будет очень похоже, так как класс переименован, например.

·>

Git has a rename command git mv, but that is just a convenience. The effect is indistinguishable from removing the file and adding another with different name and the same content

·>По сути не нужно для истории, хотя вроде там есть ещё какие-то дополнительные safety checks и апдейтит индекс заодно.
Тем хуже для git.

BFE>>Мне ни разу на практике не приходилось сливать два файла в один,
·>"значит это никому не нужно"?
·>А кусок кода из одного файла в другой перемещать приходилось?
Возможно, но припомнить не могу.

·>svn/whatever тебе в этом хоть как-то помог?
Так мне и git в этом не помогает.

BFE>>но в принципе операция слияния может быть предусмотрена.
·>Нет уж, оккамом такое надо резать.
Ох уж мне эти теоретики...
В git уже есть операция слияние для файлов из разных веток.

BFE>>·>А вот git как раз и позволяет отслеживать контент. Скажем, в IDEA есть такая фича "Show History for Selection" — выделяешь кусок кода (метод, например) и смотришь его полную историю, в т.ч. перемещение между файлами.
BFE>>Я не знаю про IDEA, но как в git отследить историю для скопированного файла?
·>git log --follow <filename>
Проверил. Не работает.
PS Хотя, может, я не правильно проводил проверку git log --follow, позже попробую проверить ещё раз.

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

BFE>>>Что значит — "заблуждение"? Мне нужно видеть историю класса и знать, когда он был един и когда его разделили на два и какой код в каком файле оказался.
BFE>·>Заблуждение в том, что история класса выражается в виде истории имени файла.
BFE>Я знаю текущее имя файла, значит я знаю, как посмотреть когда данный класс в нём появился.
Размещение классов по файлам в общем случае как попало.

BFE>·>В git тоже всё будет работать, т.к. он отследит что в этом коммите _содержимое_ класса Class.h очень похоже на ClassDerived.h и/или ClassBase.h. Имя файла не важно, главное _содержимое_.
BFE>Содержимое не будет очень похоже, так как класс переименован, например.
Неважно. Не нужно точное совпадение. Только похожесть.

BFE>·>По сути не нужно для истории, хотя вроде там есть ещё какие-то дополнительные safety checks и апдейтит индекс заодно.
BFE>Тем хуже для git.


BFE>·>svn/whatever тебе в этом хоть как-то помог?
BFE>Так мне и git в этом не помогает.
"Show History for Selection" же. git blame для строк отслеживает перемещения между файлами.

BFE>>>но в принципе операция слияния может быть предусмотрена.
BFE>·>Нет уж, оккамом такое надо резать.
BFE>Ох уж мне эти теоретики...
BFE>В git уже есть операция слияние для файлов из разных веток.
Прошу прощения, я неоднозначно выразился. Я имел в виду слияние двух файлов в один. Например слить СlassBase.h и СlassDerived.h в Сlass.h. Т.е. из двух классов сделать один.

BFE>>>Я не знаю про IDEA, но как в git отследить историю для скопированного файла?
BFE>·>git log --follow <filename>
BFE>Проверил. Не работает.
BFE>PS Хотя, может, я не правильно проводил проверку git log --follow, позже попробую проверить ещё раз.
Ещё -M и -C есть. Погляди доку, там всё расписано.

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

BFE>Часто встречающаеся задача: есть файл, который используется в двух проектах. Оба проекта лежат в своих каталогах. Как с помощью git обеспечить, чтобы этот файл был одним и тем же? Т.е. если его меняют в одном проекте, то при заборе новой версии другого проекта этот файл должен быть обновлён.

Завести отдельный репозитарий для этого файла и из обоих проектов использовать как репозитарий библиотеки...

Есть ещё другой частый случай. У меня есть какой-то проект, из которого я собираю не одну цель, а несколько.
И, в зависимости от цели, мне нужны разные проекции проекта.

Но "лучше" всего бывает, когда тебе нужно версионировать что-то большое бинарное и не всегда нужное. Ну, например, датасет для обучения модели Вот это совсем тяжко...