Здравствуйте, ·, Вы писали:
V>>Ложь. Столько файлов не могут одновременно разрабатываться. ·>В течение ~10 лет.
V>>25K / 20 = 1K файлов. Такое не один разработчик не потянет. ·>Не суди других по себе.
Не лги другим.
V>>>>Не понимаю вопроса. Патч сохранил, патч применил. Какие проблемы? V>>·>Комаду в студию. _Всё_ что надо сделать в git я привёл выше. V>>TortoiseSVN->patch/apply ·>А дальше? Какой-то диалог нарисовался. Что куда я должен ввести?
Чё ты всё под дурочка косишь?
V>>>>Он и лучше гита работает. V>>·>Нет. V>>Да. ·>Нет.
Да. Да. ДА.
V>>>>Бранч это хлам? V>>·>Да, особенно если в публичном репе. V>>Бранч для того и сделан чтобы туда помещали. Какая разница публичный он или непубличный? ·>Большая.
Никакой.
V>>>>На флешке как раз я никаких реп не размешаю. А сразу запаковываю ибо флешки не хватит. V>>·>git репозиторий уже хранит всё запакованное. V>>Оно версионное хранит, которое в разы больше, чем просто запаковать последнюю ревизию. ·>Ты не измерял — не знаешь.
Измерял. К примеру, гит проваливается в дупу на добавление 100500 бинарников.
V>>>>Изменение комментов это часть воркфлоу. V>>·>Ээээ... Каким образом? V>>Таким как и всё остальное. В чём вопрос? ·>Разберись что такое воркфлоу.
Не задавай глупых вопросов.
V>>>>Самое первое моё сообщение прочитай. V>>·>Я о конкретной статье спрашиваю: In short: Git will do it correctly, Hg will break the result, and SVN and others will simply mess up the whole thing.. V>>Да мне как-то плевать вообще что там гит решает. ·>Балабол.
П-бол.
V>>·>В ней описан сценарий, когда git, используя более умные алгоритмы, позволяет упростить мерж. Ты мне на это заявил "гит и создаёт этот геморрой" — но так и не сказал какой именно геморрой был создан гитом. Балабол. V>>Если ты слепой и глухой, то это исключительно твои проблемы. ·>Балабол.
П-бол.
V>>>>Да неужели, а гите значит хеши не предлагают к вводу в команды? V>>·>А давай я предложу тебе дарить мне $1000, да почаще. V>>А давай ты прекратишь балаболить. ·>Балабол.
П-бол.
V>>·>И что? Другие люди имеют право иметь мнение совпадающее с твоим. Фактов он правда так никаких и не привёл, как и ты. V>>История это факт? Или историю тебе надо доказывать? Раз так, то я даже утруждать себя не буду. ·>Да, история доказывается историческими документами.
И какие тебе документы по истории интернета подойдут, если ты уже уверовал в чушь?
V>>>>Чем докажешь что также используют? V>>·>Любой хостинг svn будет таким доказательством. Ну, например, sf.net V>>Где доказательство что также? ·>Ты слова "также" и "так же" не путаешь?
Осталось только к орфографии придраться, когда сказать нечего.
V>>>>·>Рекурсивно (что svn не умеет вообще никак) — субмодули могут тоже иметь свои субмодули и т.д. V>>>>Похоже ты с свн знаком чуть менее чем никак. V>>·>Ты нихрена не понял. Перечитай что я написал и ознакомся с документацией submodule. V>>Я понял что ты в свн 0 раз заявляешь такое. Этого достаточно. Тыкать мне в документацию submodule ни к чему, потому-что она неприменима к subtree и т.п. ·>Ты нихрена не понял. Мракобес.
П-бол.
V>>>>Ну так вот в свн не надо ничего забирать специально. V>>·>Я же привёл тебе команду чтобы всё работало как в svn: "git clone --recursive <url>". V>>Это команда только для первого взятия, для последующего надо явно писать `git submodule update`: https://stackoverflow.com/questions/3796927/how-to-git-clone-including-submodules ·>Специально для идиотов неумеющих читать сделаю квоту из твоей ссылки: ·>
И кстати, чтобы удалить это поделие нужно квест пройти: https://stackoverflow.com/questions/29850029/what-is-the-current-way-to-remove-a-git-submodule
Проще сразу сабмодули на помоечку отнести.
V>>>>Там билд номер ещё есть: Версия 63.0.3239.132. Где здесь только 50/60? V>>·> Как номер билда относится к количеству коммитов? V>> Это относится к продакшн билд серверу, напрямую. ·>Не относится.
Нахрена там писать число, которое не связано с билдом?
V>>·>Билдить можно раз в неделю, а коммитить каждые пол часа. V>>Ну так в свн оно номеру коммита и соответствуют. Это только в гите оно неприменимо. ·>Не всегда соответсвует. Применимо и в git (читай git describe).
git-describe — Give an object a human readable name based on an available ref
Это же не то же самое, а очередной костыль, которым нужно подпирать прокол по дизайну.
V>>>>Как это не валидные, если тот кто будет коммитить будет иметь свою ключ? V>>·>А какой идиот будет специально коммитить backdoor, подписывая его своим личным ключом?! V>>Как такой же идиот будет коммитить в свн под своим аккаунтом. ·>Неужели дошло наконец-то!? Поэтому под своим аккаунтом коммитить не будут.
Кто мене там про хакеров заявлял? Они же могут всё? Значит в гите с чужим ключом будут коммитить.
V>>>>С чего ты взял что он будет коммитить в середину? V>>·>Потому что последние коммиты всегда тщательно просматриваются и анализируются, попадают в changelogs, проходят аудит и т.п. V>>Просмотр последних коммитов также и в свн возможен. ·>Неужели дошло наконец-то!? Поэтому будут коммитить в середину.
В свн это невозможно. Во-первых, нет такой функциональности. Во-вторых, нужно отредактировать базу напрямую, получив прямой доступ к базе. В-третьих, можно всё поломать, т.к. свн хранит дельту от предыдущей версии, которая будет подменена и соответственно сломает базу.
V>>Какое это имеет отношение к защищённости гит или свн? Тоже самое возможно в любой репе. К тому необходимость анализа толпами народа это минус а не плюс. ·>Прямое. В git коммиты защищены от модификации "блокчейном".
Как это защищает от коммита в конец блокчейна?
·>Я свн давно на помоечку отправил. Если и приходится использовать, то через git-svn.
git-svn ещё большее говнище, чем сам гит.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, vdimas, Вы писали:
V>V>>>>Потому что коммиты имеют однонаправленную связь и эта связь строго одна у исходящей стороны. V>>>·>Чё? Коммит внутри имеет sha1 родителя(ей). V> >>>Это соглашение или возражение? V>·>Я не понял к чему ты сказал и попытался телепатировать, похоже безуспешно.
V>Так я выделил. V>Еще раз — это было соглашение или возражение?
"Чё?" означало "я нихрена не понял". А дальше моя интерпретация того, что мне казалось ты хотел сказать.
V>Т.е. я пока просто пытаюсь понять — что тобой движет. V>По тону — возражение, по-сути — соглашение. V>Так зачем ты это всё пишешь?
Чтобы выражался ты повнятнее, ибо телепатия у мнея плохо развита.
V>>>Прикинь, как ты знатно в лужу сел. V>·>А ты нихрена не понял. V>Увы, не понял ты, поэтому влез не туда и стал говорить не о том.
Nike тут
всё чётко объяснил с картинками, а ты тут не в тему "cherry pick не хуже rebase".
V>>>Rebase лишь меняет коммиты местами, то бишь изменяет их порядок, связи, либо двигает текущую "голову" списка коммитов. V>>>Это и дословный перевод и суть происходящего. V>·>Блин. Ты можешь использовать общепринятую терминологию? Что ты тут под списком коммитов подразумеваешь? V>Дык, я и пользую общепринятую. V>А ты напираешь на тонкости организации данных в гит. V>Commit по-русски (и в данном контексте) — это "вводить в дело".
Нет, конечно. Это опять твоя фантазия. Но допустим. Попробуем применить это к твоему же высказыванию выше: Rebase лишь меняет вводить в дела местами, то бишь изменяет их порядок, связи, либо двигает текущую "голову" списка вводить дел.
По-моему фигня получилась. Давай нафантазируй что-нибудь более вменяемое.
V>В общем, такое сложилось историческое название для этой операции в системах VCS за дестяки лет до git.
Исторически коммит это "фиксация текущего состояния системы". И потом значение несколько изменилось с появлением distributed систем.
V>Но даже напирая на тонкости хранения информации в git, ты всё-равно не прав, когда рассуждая об "иммутабельности" говоришь о создании "совсем другого коммита" и даже предлагал посмотреть на аппострофы идентификаторов на картинках. V>Во-первых, это опять букварь и соответствующее букварное хамство.
Не хамство, а ликбез.
V>Во-вторых, коммит не обязательно "совсем другой". У новой сущности совсем другой идентификатор, но может быть фактически то же "содержимое". Т.е. не "копия содержимого", а именно унутре оно же самое, т.к. содержимое коммитов и других объектов активно шарятся.
Опять какое-то словоблудие. Что значит фактически? А юридически как может быть? И что значит может быть, А что не может быть? Шаринг тут вообще детали имплементации — просто оптимизация места под хранение, к сути это не относится.
V>Коммит "унутре" состоит из пар ключ-значение и т.д. по иерархии, это тоже своеобразное дерево. V>Поэтому, создаётся лишь новый узел связи, но он может включать ссылки на те же или уже изменённые (в процессе слияния) данные. V>Т.е. если патч меняется в процессе rebase или структура файлов меняется — поменяется и содержимое нового "узла", если нет — нет. Будет переиспользовано это же содержимое. В любом случае содержимое переиспользуется по-максимуму даже в случае каких-либо отличий.
Жуть какая. Вроде бы и что-то по теме, но полный squash. При большом желании и небольшом запасе сов это может и можно натянуть под действительность, но у этого столько интерпретаций, что даже не знаю с чего начать... Что такое своеобразное дерево? Иерархия чего? Какие пары ключ-значение? Где их увидеть? Что такое изменение патча и изменение структуры файлов? Какой узел?
V>>>А по cherry-pick в общем случае можно только продублировать содержимое коммита. V>·>Верно. И то что делает cherry-pick можно добиться с помощью rebase V>В общем случае — через серию команд rebase.
rebase -i и нужные тебе коммиты (cherry) выбираешь (pick). Никакой серии не надо в "высокоуровневом сценарии".
V>Собсно, я всегда и говорю, что любые манипуляции с графом комитов "унутре" происходят через rebase.
Нет, "унутре" git этот самый rebase простой отдельный bash-скрипт, выполняющий всякие patch, commit и прочее в хитром порядке. Я не помню, чтобы какие-то другие команды его использовали.
V>Ты уже заметил, что я поддался на твою провокацию и от обсуждения сценариев верхнего уровня скатился на обсуждение механики происходящего?
Скатился ты тут
, противопоставляя cherrypic и rebase в зависимости от наличия конфликтов (причём там они вообще?), даже намёки Nike не помогли.
[словоблудие поскпиано]
V>·>Что я имею в виду более менее формально: делаем изменение и проверяем — по двум графам истории (до и после изменения) невозможно будет сказать — был ли применён rebase или cherry-pick, только в reflog можно будет увидеть разницу. V>И это абсолютно пофик.
Верно. Теперь в этом свете объясни суть "Например, при отсутствии конфликтов простой cherry pick не хуже rebase".
V>Основное назначение reflog — это иметь возможность найти потерянные экземпляры указанной выше структуры данных.
Притом это твоё личное дело, т.к. твой reflog есть только у тебя в локальном репе.
V>>>И я имено затем оговорился про "общий случай", что если отбираемый коммит ссылается на текущую нашу "голову", то делать копию коммита НЕ надо, ес-но. V>·>Но git всё равно делает копию, меняя как минимум timestamp. Попробуй сам. Я пробовал. V>В прошлое большое обсуждение я тебе уже напоминал про --ff для cherry-pick.
Это вырожденный сценарий (кто его вообще использует? по-моему этот флажок добавили для удобства скриптования) для cherry-pick. В rebase он бессмысленнен, ибо ff делать некуда.
А rebase тупо вообще ничего не делает. Но если тебе так хочется закопаться в мелочные отличия в вырожденных случаях — то почитай про флажок --no-ff у rebase.
V>В описанном сценарии "копия коммита" (даже в твоей терминологии) не содаётся, а просто курсор с именем HEAD прокручивается на имеющийся коммит.
Т.е. двигает текущую "голову" списка коммитов.? То что ты писал про rebase?
V>>>При любом изменении порядка коммитов могут быть как созданы новые коммиты, так и оставлены старые. V>>>Это зависит от того, поменялся ли хеш патча при манипулировании с ним или нет. V>·>От patch-id это не зависит. rebase и cherry-pick всегда создают новые коммиты. Или я опять не понял что ты имеешь в виду со своей особой терминологией. Покажи пример когда остаются, а когда не остаются старые/новые коммиты при rebase/cherry-pick чтобы я понял что ты имеешь в виду. V>"Официалльная терминология" пойдёт? V>https://git-scm.com/docs/git-cherry-pick V>
V>--ff
V>If the current HEAD is the same as the parent of the cherry-pick’ed commit, then a fast forward to this commit will be performed.
Ты написал что "Это зависит от того, поменялся ли хеш патча". А ВНЕЗАПНО оказывается это следовало понимать как "if ... as same parent".
V>>>Но принципиальная разница при rebase такая, что если хеш поменялся, то старый коммит уже нигде не участвует, он пропадает (оказывается в мусоре и через некоторое время подчищается), но если ты делаешь cherry-pick, то создаётся копия коммита. V>·>Пропадаемость коммита зависит от того reachable он или нет V>Разумеется. Но почему каждый божий раз, когда речь о высокоуровневом сценарии, тебе требуется, чтобы коллега расписывал, что при этом происходит "унутре"? V>Это профанация дележа опытом. Мы же здесь опытом делимся, верно?
В данном случае надо делиться знаниями, а не опытом, судя по тому какие ты тут байки рассказываешь — не самым удачным. Называл бы ты вещи своими именами — не вводил бы в заблуждение.
V>>>>>Нарисуй себе, если плохо понимаешь происходящее. V>>>·>Я прекрасно понимаю. V>>>Вот чиста при взгляде со стороны, как от Васи с улицы говорю — ты явно плаваешь. V>>>У тебя какое-то превратное как представление о происходящем, так о терминологии. V>·>Твои утверждения тупо расходятся с наблюдаемыми фактами. V>Угу, а судьи кто? )) V>Ты не видишь себя со стороны.
Мои высказывания хоть как-то совпадают по смыслу с документацией.
[словоблудие поскпиано]
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Vain, Вы писали:
V>>>25K / 20 = 1K файлов. Такое не один разработчик не потянет. V>·>Не суди других по себе. V>Не лги другим.
В смысле? У нас в репе действительно лежит ~25к файлов. Ты правда уверен, что таких реп не бывает или что? Какие у тебя причины обвинять меня в лжи?
V>>>>>Не понимаю вопроса. Патч сохранил, патч применил. Какие проблемы? V>>>·>Комаду в студию. _Всё_ что надо сделать в git я привёл выше. V>>>TortoiseSVN->patch/apply V>·>А дальше? Какой-то диалог нарисовался. Что куда я должен ввести? V>Чё ты всё под дурочка косишь?
Я тебе привёл команду в git, которая делает всё что надо. А ты мне опцию в меню. Эквивалент давай. Ну и заодно чтобы на моей ubuntu заработало.
V>>>>>Он и лучше гита работает. V>Да. Да. ДА.
А доказать? Или как обычно, балабольство?
V>>>>>Бранч это хлам? V>>>·>Да, особенно если в публичном репе. V>>>Бранч для того и сделан чтобы туда помещали. Какая разница публичный он или непубличный? V>·>Большая. V>Никакой.
Публичные бранчи означают публичные линии развития проекта, а не для того, чтобы туда помещали всё что поместится.
V>>>Оно версионное хранит, которое в разы больше, чем просто запаковать последнюю ревизию. V>·>Ты не измерял — не знаешь. V>Измерял. К примеру, гит проваливается в дупу на добавление 100500 бинарников.
Ну не делай так. А я знаю 100500 способов свалить в дупу svn. И что?
V>>>>>Изменение комментов это часть воркфлоу. V>>>·>Ээээ... Каким образом? V>>>Таким как и всё остальное. В чём вопрос? V>·>Разберись что такое воркфлоу. V>Не задавай глупых вопросов.
А что тебе непонятно в вопросе? Попробую переформулировать. Вот тебе некоторые примеры воркфлоу. Теперь объясни какой частью воркфлоу является изменение комментов коммитов?
V>>>·>Я о конкретной статье спрашиваю: In short: Git will do it correctly, Hg will break the result, and SVN and others will simply mess up the whole thing.. V>>>Да мне как-то плевать вообще что там гит решает. V>·>Балабол. V>П-бол.
У тебя где-то стала повышаться температура? Аргументы, вижу, стали жарче.
V>>>·>И что? Другие люди имеют право иметь мнение совпадающее с твоим. Фактов он правда так никаких и не привёл, как и ты. V>>>История это факт? Или историю тебе надо доказывать? Раз так, то я даже утруждать себя не буду. V>·>Да, история доказывается историческими документами. V>И какие тебе документы по истории интернета подойдут, если ты уже уверовал в чушь?
Начни хоть с каких-нибудь. Пока ничего от тебя не видел.
V>>>>>Чем докажешь что также используют? V>>>·>Любой хостинг svn будет таким доказательством. Ну, например, sf.net V>>>Где доказательство что также? V>·>Ты слова "также" и "так же" не путаешь? V>Осталось только к орфографии придраться, когда сказать нечего.
Задавай вопросы внятно. Что узнать-то хотел?
V>Специально для идиотов которые недочитывают до конца: V>For already cloned repos, or older Git versions, use:
А теперь для идиотов которые забывают какие вопросы задают: "Как выяснить 100% набор команд чтобы сразу всё взять без квеста?". Ответ "git clone --recursive <url>" даёт верный и однозначный ответ на этот вопрос. Если у тебя остались ещё вопросы — задавай.
Если ты намекаешь на older versions — это этим версиям лет 10 или даже больше. Где ты нашел такую?
V>>>>>Там билд номер ещё есть: Версия 63.0.3239.132. Где здесь только 50/60? V>>>·> Как номер билда относится к количеству коммитов? V>>> Это относится к продакшн билд серверу, напрямую. V>·>Не относится. V>Нахрена там писать число, которое не связано с билдом?
Мне пофиг на билды. Ты их тут сам придумал. Я говорил о версиях и количестве коммитов между ними. Билды не относятся к вопросу вообще никак.
V>·>Не всегда соответсвует. Применимо и в git (читай git describe). V>
git-describe — Give an object a human readable name based on an available ref
V>Это же не то же самое, а очередной костыль, которым нужно подпирать прокол по дизайну.
Ага-ага.
V>>>Как такой же идиот будет коммитить в свн под своим аккаунтом. V>·>Неужели дошло наконец-то!? Поэтому под своим аккаунтом коммитить не будут. V>Кто мене там про хакеров заявлял? Они же могут всё? Значит в гите с чужим ключом будут коммитить.
Я тебе уже объяснял про чужие ключи. Попробуй описать модель атаки с уводом чужих клучей и сравни с тем что я описал.
V>>>·>Потому что последние коммиты всегда тщательно просматриваются и анализируются, попадают в changelogs, проходят аудит и т.п. V>>>Просмотр последних коммитов также и в свн возможен. V>·>Неужели дошло наконец-то!? Поэтому будут коммитить в середину. V>В свн это невозможно. Во-первых, нет такой функциональности.
И кого это когда-то останавливало?
V>Во-вторых, нужно отредактировать базу напрямую, получив прямой доступ к базе.
Это относительно несложно. Все админы имеют, как минимум.
V>В-третьих, можно всё поломать, т.к. свн хранит дельту от предыдущей версии, которая будет подменена и соответственно сломает базу.
А можно и не поломать. Я так делал. Не ломалось.
V>>>Какое это имеет отношение к защищённости гит или свн? Тоже самое возможно в любой репе. К тому необходимость анализа толпами народа это минус а не плюс. V>·>Прямое. В git коммиты защищены от модификации "блокчейном". V>Как это защищает от коммита в конец блокчейна?
"Потому что последние коммиты всегда тщательно просматриваются и анализируются, попадают в changelogs, проходят аудит и т.п."
V>·>Я свн давно на помоечку отправил. Если и приходится использовать, то через git-svn. V>git-svn ещё большее говнище, чем сам гит.
Полностью согласен. Но всё-таки гораздо лучше чем svn.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>Еще раз — это было соглашение или возражение? ·>"Чё?" означало "я нихрена не понял". А дальше моя интерпретация того, что мне казалось ты хотел сказать.
Ну и какие тут могут быть альтернативные интерпретации?
коммиты имеют однонаправленную связь и эта связь строго одна у исходящей стороны
V>>По тону — возражение, по-сути — соглашение. V>>Так зачем ты это всё пишешь? ·>Чтобы выражался ты повнятнее, ибо телепатия у мнея плохо развита.
Это не телепатия плохо развита, это или специфические черты характера или особенности соображалки.
V>>Увы, не понял ты, поэтому влез не туда и стал говорить не о том. ·>Nike тут
всё чётко объяснил с картинками, а ты тут не в тему "cherry pick не хуже rebase".
Смотреть надо раньше, где я отвечал не тебе.
Ты отвечаешь людям невпопад.
V>>Дык, я и пользую общепринятую. V>>А ты напираешь на тонкости организации данных в гит. V>>Commit по-русски (и в данном контексте) — это "вводить в дело". ·>Нет, конечно. Это опять твоя фантазия.
Вот. Ты уводишь людей в оффтоп через примитивную технику — через провокации.
Так ломаешь тему разговора, что коллегам, вместо обсуждения исходных прикладных вещей, необходимо тебя или проигнорить, или явным образом послать, ну или доказывать, что не верблюд. Г-но манеры это.
"Фантазии"...
Ты глаза-то открой. ))
А то натурально ситуация "мне из подвала виднее".
·>Но допустим. Попробуем применить это к твоему же высказыванию выше: Rebase лишь меняет вводить в дела местами, то бишь изменяет их порядок, связи, либо двигает текущую "голову" списка вводить дел. ·>По-моему фигня получилась. Давай нафантазируй что-нибудь более вменяемое.
ЧТД — особенности или соображалки или характера, бо это или торможение или троллинг. Бо когда говорят о каких либо дейстиях в виде сущности (т.е. существительного), то используется либо "отглагольное существительное" (при его наличии в языке), либо это действие описывание с помощью дополнительных существительных: "действие", "операция", "процесс" и т.д. (смотря какая форма исходного глагола нужна — совершенная или не совершенная).
В общем, попробуй еще раз.
V>>В общем, такое сложилось историческое название для этой операции в системах VCS за дестяки лет до git. ·>Исторически коммит это "фиксация текущего состояния системы". И потом значение несколько изменилось с появлением distributed систем.
Коммит — это свершение пользователем некоей операции над системой. В дальнейших логических рассуждениях мы к этой операции привязываемся. Причём, даже ты чаще рассуждаешь о коммитах в общепризнанном смысле, а не в смысле тонкостей их хранения в git. И только когда тебе нечего сказать по-сути, включаешь свою шарманку об "апострофах" и прочем "вы ничего не понимаете, я несу вам светоч знаний".
Ты трепешь коллегам нервы букварными истинами, а не нечёшь светоч знаний.
Потому что, даже если напирать на "механику", как ты тут напираешь, то проблем-то в любом случае нет:
— объекты могут иметь "identity", а могут иметь "значение";
— если с прикладной точки зрения больше интересует "значение", то запросто создаются мутабельные структуры на иммутабельных типах данных.
Это ж классика жанра, иначе бы не существовали языки со встроенной иммутабельностью.
Получается, что ты плаваешь еще и по этим несложным вещам.
V>>Но даже напирая на тонкости хранения информации в git, ты всё-равно не прав, когда рассуждая об "иммутабельности" говоришь о создании "совсем другого коммита" и даже предлагал посмотреть на аппострофы идентификаторов на картинках. V>>Во-первых, это опять букварь и соответствующее букварное хамство. ·>Не хамство, а ликбез.
Ликбез — это сообщение новой информации.
А без новой информации это будет лишь сочетание неспособности въехать суть обсуждения с банальным хамством.
А чо, как просто-то!
Нечего ответить по теме — быстрее обвини окружающих в некомпетентности!
V>>Во-вторых, коммит не обязательно "совсем другой". У новой сущности совсем другой идентификатор, но может быть фактически то же "содержимое". Т.е. не "копия содержимого", а именно унутре оно же самое, т.к. содержимое коммитов и других объектов активно шарятся. ·>Опять какое-то словоблудие. Что значит фактически? А юридически как может быть? И что значит может быть, А что не может быть? Шаринг тут вообще детали имплементации — просто оптимизация места под хранение, к сути это не относится.
Вот, ЧТД. Ты выбрал себе некий уютненький уровень механики. В итоге генерируешь бесконечные руки-лица. ))
Ни дай боже рассуждать о происходящем на уровне чуть выше выбранного тобой — "вы ничего не понимаете!".
Начни рассждать чуть подробнее, чем ты себе выбрал — "а это уже детали имплементации!".
А по-мне — жестокое нубство в обоих случаях.
Если ты претендуешь на понимание системы (а ты тщательно претендуешь, чем нехило доставляешь, кста), то надо уметь рассуждать о её работе на любом из уровней абстракций. Но ты не умеешь. Значит, толком не понимаешь работу системы. Не понимая высокоуровневые сценарии, ты не поймёшь "почему именно так" был выполнен следующий, подчинённый слой абстракции.
Одним из самых твоих залётов, как по мне, является упор на "всемогутность rebase", где я тебе уже многократно говорил, что практически любые манипуляции с графом данных к нему сводятся, но талдычить об этом как минимум глупо.
По-сути, твои аргументы из этой области выглядят примерно так:
— идёт обсуждение некоего императивного алгоритма;
— ты такой влетаешь: "Здесь самой важной операцией является операция присвоения!";
— тебе отвечают: "Разве? Мы же не об этом...";
— ты опять: "Ну конечно да, невежды! Вам стоит внимательно меня слушать, а не возражать! Без операции присвоения тут ничего не будет работать! В базе-то сидит операция присвоения, неужели вы НЕ ПОНИМАЕТЕ ТАКИХ ЭЛЕМЕНТАРНЫХ ВЕЩЕЙ??? Вот смотрите, всё, что вы тут расписали — это БАНАЛЬНАЯ ПОСЛЕДОВАТЕЛЬНОСТЬ ОПЕРАЦИЙ ПРИСВОЕНИЯ!!! Теперь ПОНЯЛИ ХОТЬ ЧТО_ТО???".
Не подскажешь, случаем, как, не нарушая правил форума, дать понять человеку о величине проблем вообще со всем, что у него происходит в голове? ))
В языке готовые для этого слова есть, ну тут за такое банят.
Поэтому, остаётся простое: "Коллега, вы как минимум хамите всем этим, не говоря уже, ммм, об остальном (о чём говорить нелья)..."
Здравствуйте, ·, Вы писали:
·>Тут терминологический спор, каждый может понимать под "поднялся" зависимости от контекста ровно то укладывается в личную картину мира. Для меня увеличение скорости в два раза — это крутой подъём.
Этого увеличения не было.
·>Любая компания за такое увеличение потока клиентов хоть маму продаст.
И далее пошли рассуждения на основании ложных предпосылок.
·>Если удвоенная скорость тебя не убеждает и я переформулирую так "А sourceforge на хайпе cvs значит не поднимался?"
Нет. Потому что первые годы существования sourceforge он не занимался хостингом никакой из VCS.
Народ туда просто выкладывал архивы исходников и бинарников.
·>"А collabnet/tigris на хайпе svn значит не поднимался?" — более правдоподобно?
Тоже нет.
collabnet стал популярен из-за развитых ср-в управления проектами, которые тогда были вновинку в такой именно организации.
Тогда эти ср-ва в основном шли как self-hosting, с наборами серверов и десктопных клиентов.
Т.е. хайп был по этим ср-вам, т.к. эта функциональность удачно заехала в "чистый веб".
·>Чем эти заявления отличаются от "github/gitlab которые неплохо так поднялись на гит хайпе" (кстати, вообще никак не подтверждённое заявление)?
А это правда.
Потому что никто не давал такую мощную поддержку всего, что связано с git, как github.
Более того, по-началу были мало GUI-утилит для git, а github сразу же выпустил свою неплохую GUI-утилиту.
Но работать эта утилита может только с github.
Это было "чертовски умно" ))
·>Т.е. момент просто случайно совпал с временем добавления svn в sf. Да, доказывать что-то основанное на исторических событиях я вряд ли смогу, всё что не укладывается в вашу картину мира — всегда можно свалить на случайные совпадения.
Здравствуйте, vdimas, Вы писали:
V>·>А кому и svn система контроля версий. V>Дык, в целой россыпи сценариев svn банально удобней. V>Меньше телодвижений.
Нет уж, спасибо. Проходили, не надо.
V>Простейшая операция — в рабочей копии с незакоммиченными своими изменениями я хочу забрать с сервака изменение только одного файла. V>Причём, я тоже уже вносил в этот файл изменения и хочу, чтобы эти мои изменения еще никуда не коммитились, но в него уже зашли изменения с сервака. Это весьма популярный "рабочий" сценарий при коллективной работе над некоей задачей.
Вот за такие операции svn и не любят. Ибо в итоге у тебя в репозитории появляется кровавое неуправляемое месиво из ревизий и классический детский сад "а у меня всё работает". К тому же, хорошая СКВ должна обеспечивать обратимость изменений, а вот после такого магического апдейта-мержа вернуться к предыдущему состоянию просто невозможно.
Это мне напоминает флеймы прошлого века clipper/foxpro/etc vs oracle/mssql — мол, "накой нам acid транзакции, да не запорется база, ну у меня же ещё ничего не запарывалось, у меня же ups есть с аккумулятором от камаза"...
V>А в git надо выполнить кучу приcеданий для такой тривиальщины.
Апдейт всего работает достаточно быстро и надёжно, что так изгаляться просто не приходится.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vdimas, Вы писали:
V>>>Еще раз — это было соглашение или возражение? V>·>"Чё?" означало "я нихрена не понял". А дальше моя интерпретация того, что мне казалось ты хотел сказать. V>Ну и какие тут могут быть альтернативные интерпретации? V>
V>коммиты имеют однонаправленную связь и эта связь строго одна у исходящей стороны
V>
Некоторые или все коммиты? Связь parent-child или "узел графа истории"-"снапшот рабочей копии"?
И вообще, к чему ты это всё говоришь? Тезис сформулируй.
V>·>Чтобы выражался ты повнятнее, ибо телепатия у мнея плохо развита. V>Это не телепатия плохо развита, это или специфические черты характера или особенности соображалки.
Твоё мнение мне очень интересно. Спасибо.
V>·>Нет, конечно. Это опять твоя фантазия. V>Вот. Ты уводишь людей в оффтоп через примитивную технику — через провокации.
А ты — через обычное словоблудие. Наговорить что-нибудь "своими словами" и потом придираться к каждому моменту когда выбрали неверную интерпретации.
[словоблудие проигнорировано]
V>·>По-моему фигня получилась. Давай нафантазируй что-нибудь более вменяемое. V>ЧТД — особенности или соображалки или характера, бо это или торможение или троллинг. Бо когда говорят о каких либо дейстиях в виде сущности (т.е. существительного), то используется либо "отглагольное существительное" (при его наличии в языке), либо это действие описывание с помощью дополнительных существительных: "действие", "операция", "процесс" и т.д. (смотря какая форма исходного глагола нужна — совершенная или не совершенная). V>В общем, попробуй еще раз.
Надоело. Если есть что сказать — говори сразу. А в угадайку играть я не хочу.
V>>>В общем, такое сложилось историческое название для этой операции в системах VCS за дестяки лет до git. V>·>Исторически коммит это "фиксация текущего состояния системы". И потом значение несколько изменилось с появлением distributed систем. V>Коммит — это свершение пользователем некоей операции над системой. В дальнейших логических рассуждениях мы к этой операции привязываемся. Причём, даже ты чаще рассуждаешь о коммитах в общепризнанном смысле, а не в смысле тонкостей их хранения в git. И только когда тебе нечего сказать по-сути, включаешь свою шарманку об "апострофах" и прочем "вы ничего не понимаете, я несу вам светоч знаний".
Не "некой", а вполне конкретной. Опять насловоблудил.
[словоблудие проигнорировано]
V>>>Но даже напирая на тонкости хранения информации в git, ты всё-равно не прав, когда рассуждая об "иммутабельности" говоришь о создании "совсем другого коммита" и даже предлагал посмотреть на аппострофы идентификаторов на картинках. V>>>Во-первых, это опять букварь и соответствующее букварное хамство. V>·>Не хамство, а ликбез. V>Ликбез — это сообщение новой информации. V>А без новой информации это будет лишь сочетание неспособности въехать суть обсуждения с банальным хамством.
Новой инфы у меня достаточно. Например, если бы для тебя инфа что rebase это простой bash-скрипт была не новой. ты бы чушь типа "любые манипуляции с графом комитов "унутре" происходят через rebase" не писал бы изначально. Я прекрасно понимаю, что всю новую инфу ты тупо игнорируешь, гордость не позволяет, но этот форум могут читать и другие люди.
V>>>Во-вторых, коммит не обязательно "совсем другой". У новой сущности совсем другой идентификатор, но может быть фактически то же "содержимое". Т.е. не "копия содержимого", а именно унутре оно же самое, т.к. содержимое коммитов и других объектов активно шарятся. V>·>Опять какое-то словоблудие. Что значит фактически? А юридически как может быть? И что значит может быть, А что не может быть? Шаринг тут вообще детали имплементации — просто оптимизация места под хранение, к сути это не относится.
[восторженный интерес к моей персоне проигнорирован]
Если тебе так интересно пообсуждать мою личность — добро пожаловать в мой личный блог.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>Не лги другим. ·>В смысле? У нас в репе действительно лежит ~25к файлов. Ты правда уверен, что таких реп не бывает или что? Какие у тебя причины обвинять меня в лжи?
Зачем ты выделенное удалил. Опять прикидываешься?
V>>·>А дальше? Какой-то диалог нарисовался. Что куда я должен ввести? V>>Чё ты всё под дурочка косишь? ·>Я тебе привёл команду в git, которая делает всё что надо. А ты мне опцию в меню. Эквивалент давай.
Ставишь TortoiseSVN и проверяешь. Чем не эквивалент?
·>Ну и заодно чтобы на моей ubuntu заработало.
Бегу спотыкаться.
·>А доказать? Или как обычно, балабольство?
Это ты пришёл с балабольством про свн сюда. Тебе и доказывать что свн хуже.
V>>Никакой. ·>Публичные бранчи означают публичные линии развития проекта, а не для того, чтобы туда помещали всё что поместится.
Публичность этому не мешает и даже помогает. А вот при закрытой форме можно нагородить такой огород, что никакой мерж не справиться.
V>>Измерял. К примеру, гит проваливается в дупу на добавление 100500 бинарников. ·>Ну не делай так. А я знаю 100500 способов свалить в дупу svn. И что?
И нахрена тогда там хранить бинарники и гордиться их быстром коммитом? Мисье знает толк в извращениях.
·>А что тебе непонятно в вопросе? Попробую переформулировать. Вот тебе некоторые примеры воркфлоу. Теперь объясни какой частью воркфлоу является изменение комментов коммитов?
Такое что это практическая необходимость исправить и дополнить комментарий. Ты будешь ещё с этим спорить?
V>>·>Балабол. V>>П-бол. ·>У тебя где-то стала повышаться температура? Аргументы, вижу, стали жарче.
Твои жареные аргументы меня не интересуют.
V>>И какие тебе документы по истории интернета подойдут, если ты уже уверовал в чушь? ·>Начни хоть с каких-нибудь. Пока ничего от тебя не видел.
Тебе уже сказали, толку то от этого? Не вижу смысла повторяться.
V>>Специально для идиотов которые недочитывают до конца: V>>For already cloned repos, or older Git versions, use: ·>А теперь для идиотов которые забывают какие вопросы задают: "Как выяснить 100% набор команд чтобы сразу всё взять без квеста?". Ответ "git clone --recursive <url>" даёт верный и однозначный ответ на этот вопрос. Если у тебя остались ещё вопросы — задавай.
Не не даёт потому-что сразу ругается на непустой каталог.
·>Если ты намекаешь на older versions — это этим версиям лет 10 или даже больше. Где ты нашел такую?
Ты явно игнорируешь написанное.
V>>Нахрена там писать число, которое не связано с билдом? ·>Мне пофиг на билды. Ты их тут сам придумал.
Я ничего не придумывал. Это устаявшая практика в версии продукта писать номер билда или коммита.
·>Я говорил о версиях и количестве коммитов между ними. Билды не относятся к вопросу вообще никак.
Ещё как относятся. Приходит отчёт с ошибкой связанной именно с версией у пользователя, по-которому ищется тот самый билд или коммит, как минимум чтобы воспроизвести проблему.
V>>Это же не то же самое, а очередной костыль, которым нужно подпирать прокол по дизайну. ·>Ага-ага.
Угу-гу-гу.
V>>Кто мене там про хакеров заявлял? Они же могут всё? Значит в гите с чужим ключом будут коммитить. ·>Я тебе уже объяснял про чужие ключи. Попробуй описать модель атаки с уводом чужих клучей и сравни с тем что я описал.
Зачем мене ещё что-то описывать? Я как оппонент заявлю: "хакеры могут всё", этого достаточно.
V>>В-третьих, можно всё поломать, т.к. свн хранит дельту от предыдущей версии, которая будет подменена и соответственно сломает базу. ·>А можно и не поломать. Я так делал. Не ломалось.
Сначала объясни что ты делал.
V>>>>Какое это имеет отношение к защищённости гит или свн? Тоже самое возможно в любой репе. К тому необходимость анализа толпами народа это минус а не плюс. V>>·>Прямое. В git коммиты защищены от модификации "блокчейном". V>>Как это защищает от коммита в конец блокчейна? ·>"Потому что последние коммиты всегда тщательно просматриваются и анализируются, попадают в changelogs, проходят аудит и т.п."
Причём здесь блокчейн? В свн может быть абсолютно также!
·>Полностью согласен. Но всё-таки гораздо лучше чем svn.
Само существование git-svn с жуткими кастылями доказывает обратное.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>>>Не лги другим. V>·>В смысле? У нас в репе действительно лежит ~25к файлов. Ты правда уверен, что таких реп не бывает или что? Какие у тебя причины обвинять меня в лжи? V>Зачем ты выделенное удалил. Опять прикидываешься?
"одновременно разрабатываться." — это что-ли? Я не знаю что это означает для тебя. Могу немного подробнее рассказать. У нас несколько сотен приложений (что-то типа soa архитектуры), которые постоянно меняются. Скажем, в прошлом году были изменения для MiFID II и это затронуло практически каждое приложение. А ещё плюс тут же всяческие тесты, конфиги и т.п. вот 25к и набежало.
V>>>Чё ты всё под дурочка косишь? V>·>Я тебе привёл команду в git, которая делает всё что надо. А ты мне опцию в меню. Эквивалент давай. V>Ставишь TortoiseSVN и проверяешь. Чем не эквивалент?
Ты мне толком скажи. Я привёл точную команду "git commit -am wip & git push" всё. А ты мне что-то невнятное мычишь про клики мышой, да "ставишь и проверяешь".
V>·>Ну и заодно чтобы на моей ubuntu заработало. V>Бегу спотыкаться.
Давай, не задерживайся.
V>·>А доказать? Или как обычно, балабольство? V>Это ты пришёл с балабольством про свн сюда. Тебе и доказывать что свн хуже.
Нет. Ты заявил "Он и лучше гита работает." бездоказательно. Какое доказательство и с чего это вдруг ты с меня требуешь — для меня тайна.
V>>>Никакой. V>·>Публичные бранчи означают публичные линии развития проекта, а не для того, чтобы туда помещали всё что поместится. V>Публичность этому не мешает и даже помогает. А вот при закрытой форме можно нагородить такой огород, что никакой мерж не справиться.
Каким образом помогает? Никто просто не будет заглядывать в эти ветки и городи что хочешь. А от "никакой мерж не справится" — мержся почаще и будет тебе щастьё.
V>>>Измерял. К примеру, гит проваливается в дупу на добавление 100500 бинарников. V>·>Ну не делай так. А я знаю 100500 способов свалить в дупу svn. И что? V>И нахрена тогда там хранить бинарники и гордиться их быстром коммитом? Мисье знает толк в извращениях.
Ты меня с кем-то попутал.
В любом случае, наличие бинарников (картинки, например, в вебсайте или тестовые данные) не означает что их сразу непременно 100500.
V>·>А что тебе непонятно в вопросе? Попробую переформулировать. Вот тебе некоторые примеры воркфлоу. Теперь объясни какой частью воркфлоу является изменение комментов коммитов? V>Такое что это практическая необходимость исправить и дополнить комментарий. Ты будешь ещё с этим спорить?
А в киеве дядька. Практическая необходимость это, конечно, круто. Но зачем ты её ввернул в разговор о воркфлоу? Как обычно, с темы съехать?
V>>>П-бол. V>·>У тебя где-то стала повышаться температура? Аргументы, вижу, стали жарче. V>Твои жареные аргументы меня не интересуют.
Если мои аргументы что-то там у тебя жарят, я тут непричём.
V>>>Специально для идиотов которые недочитывают до конца: V>>>For already cloned repos, or older Git versions, use: V>·>А теперь для идиотов которые забывают какие вопросы задают: "Как выяснить 100% набор команд чтобы сразу всё взять без квеста?". Ответ "git clone --recursive <url>" даёт верный и однозначный ответ на этот вопрос. Если у тебя остались ещё вопросы — задавай. V>Не не даёт потому-что сразу ругается на непустой каталог.
Ну задай другой каталог или удали тот, который мешается. В чём вопрос-то? Ты конкретно сформулируй проблему, а не заставляй меня телепатировать.
V>·>Если ты намекаешь на older versions — это этим версиям лет 10 или даже больше. Где ты нашел такую? V>Ты явно игнорируешь написанное.
То что не относится к теме обсуждения — да, стараюсь игнорировать, чтобы не поддаваться на провокации сведения темы в говно.
V>>>Нахрена там писать число, которое не связано с билдом? V>·>Мне пофиг на билды. Ты их тут сам придумал. V>Я ничего не придумывал. Это устаявшая практика в версии продукта писать номер билда или коммита.
Пусть, и что? Какое это имеет отношение к обсуждаемой теме? Опять съезжаешь в сторону?
V>·>Я говорил о версиях и количестве коммитов между ними. Билды не относятся к вопросу вообще никак. V>Ещё как относятся. Приходит отчёт с ошибкой связанной именно с версией у пользователя, по-которому ищется тот самый билд или коммит, как минимум чтобы воспроизвести проблему.
Ок. Проблему воспроизвели. В версии X проблема воспроизводится, в версии Y — не воспроизводится. Между версиями X и Y — тысячи коммитов, тысячи изменённых файлов. Дальше что?
V>>>Кто мене там про хакеров заявлял? Они же могут всё? Значит в гите с чужим ключом будут коммитить. V>·>Я тебе уже объяснял про чужие ключи. Попробуй описать модель атаки с уводом чужих клучей и сравни с тем что я описал. V>Зачем мене ещё что-то описывать? Я как оппонент заявлю: "хакеры могут всё", этого достаточно.
Верно, достаточно чтобы свести обсуждение в говно. Собственно, как я понял, у тебя это и есть цель дискуссии.
V>>>В-третьих, можно всё поломать, т.к. свн хранит дельту от предыдущей версии, которая будет подменена и соответственно сломает базу. V>·>А можно и не поломать. Я так делал. Не ломалось. V>Сначала объясни что ты делал.
Да я уж объяснял — правил старые коммиты (не с целью хака, конечно, к сожалению, а чтобы историю мержей и правок сделать чуть более вменяемой) путём отката до нужной ревизии и перепроигрывания чуть подправленных коммитов. Но это был самый первый способ что я нашел. Если повнимательнее покопаться в формате
V>>>>>Какое это имеет отношение к защищённости гит или свн? Тоже самое возможно в любой репе. К тому необходимость анализа толпами народа это минус а не плюс. V>>>·>Прямое. В git коммиты защищены от модификации "блокчейном". V>>>Как это защищает от коммита в конец блокчейна? V>·>"Потому что последние коммиты всегда тщательно просматриваются и анализируются, попадают в changelogs, проходят аудит и т.п." V>Причём здесь блокчейн? В свн может быть абсолютно также!
Ты просто не читаешь что тебе пишут. Я пишу _коммиты_ защищены от _модификации_. Коммит в конец блокчейна не может никак модифицировать уже существующий коммит. Коммит в конце блокчейна окажется под тщательным анализом, в отличие от незаметной модификации каких-то уже давно забытых.
V>·>Полностью согласен. Но всё-таки гораздо лучше чем svn. V>Само существование git-svn с жуткими кастылями доказывает обратное.
Доказывает что именно? С какими именно костылями?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>·>А кому и svn система контроля версий. V>>Дык, в целой россыпи сценариев svn банально удобней. V>>Меньше телодвижений. ·>Нет уж, спасибо. Проходили, не надо.
Просто ты не разобрался с ним.
V>>Простейшая операция — в рабочей копии с незакоммиченными своими изменениями я хочу забрать с сервака изменение только одного файла. V>>Причём, я тоже уже вносил в этот файл изменения и хочу, чтобы эти мои изменения еще никуда не коммитились, но в него уже зашли изменения с сервака. Это весьма популярный "рабочий" сценарий при коллективной работе над некоей задачей. ·>Вот за такие операции svn и не любят.
Просто ты не разобрался с ним.
·>Ибо в итоге у тебя в репозитории появляется кровавое неуправляемое месиво
Эмоции, эмоции, эмоции.
Во все времена лишние эмоции были признаком глупости.
·>из ревизий и классический детский сад "а у меня всё работает".
А это уже не просто эмоции, а натуральная истерика. ))
·>К тому же, хорошая СКВ должна обеспечивать обратимость изменений
Изменения обратимы, будучи зарегестрированы в системе.
Разумеется, всё важное "сохраняется", т.е. коммитится.
А если ты редактировал документ (это просто аналогия) но решил какие-то изменения не сохранять — это ж твоё право, верно?
Ну вот ты что-то заметил, решил исправить, рядом за столом сидит другой коллега и говорит: "это уже исправлено, 5 сек забирай".
Закидывает только этот файл, ты тоже забираешь только этот файл.
10 сек на всё.
А в git — хрен там.
В гит вокруг тривиальщины происходят такие пляски с бубном, что ПЕРЕД началом любой совместной разработки принято договариваться, чтобы не слишком задевать крылом друг друга. А это, называя вещи своими именами, — профанация совместной разработки.
·>а вот после такого магического апдейта-мержа вернуться к предыдущему состоянию просто невозможно.
В этом и состоит цель такой операции — "запороть" только один какой-то файл или поддиректорию.
·>Это мне напоминает флеймы прошлого века clipper/foxpro/etc vs oracle/mssql — мол, "накой нам acid транзакции, да не запорется база, ну у меня же ещё ничего не запарывалось, у меня же ups есть с аккумулятором от камаза"...
Я тоже это нубство наблюдал тыщщи раз, типа такой же низкопробной демагогии. ))
Ведь часто, действительно, никакие транзакции не нужны.
Намного чаще, чем думает твоё "поколение next".
Спорить можно лишь о том — нужны ли транзакции в некоем конкретном сценарии или нет.
Любая другая постановка вопроса выдаёт упоротого дилетанта с головой.
Почему упоротого? Потому так слишком далеко можно уехать, если принимать технические решения не путём его синтеза из исходных данных, а сугубо через некое собственное "чувство прекрасного"...
В общем, очередной твой пипец на марше.
V>>А в git надо выполнить кучу приcеданий для такой тривиальщины. ·>Апдейт всего работает достаточно быстро и надёжно, что так изгаляться просто не приходится.
Апдейт всего практически никогда не нужен при активной совместной разработке.
Более того — он сильно вреден, т.к. ведёт к распылению внимания и трате в 3-5 раз большего времени, т.к. при "обновлении всего" вытягивается слишком много изменений по многим зависимостям.
В итоге, чтобы суметь в git работать совместно и при этом оперативно, как в svn, надо будет создавать примерно 5-7 подветок в день и коллеги должны тянуть друг у друга конкретные эти подветки, что само по себе является идиотизмом.
Собсно, на твою близорукость в этом вопросе (и не только на твою) я уже указывал — git НЕ предназначен для организации коллективной realtime-разработки. Он заточен ровно наоборот — на неспешную независимую offline-разработку. Да еще и желательно над разными частями системы. А м/у этими сценариями пропасть, неужели сам не видишь?
Тут даже просто спорить и пытаться сравнивать эти сценарии м/у собой (как тебя постоянно пробивает) — это уже залёт, это типа как сравнивать вкусы клубники и мяса.
Имено поэтому Mercurial популярен до сих пор в некоторых активно развивающихся проектах — ведь он умеет быть и как svn и как git в самых популярных сценариях разработки.
Здравствуйте, vdimas, Вы писали:
V>>>Меньше телодвижений. V>·>Нет уж, спасибо. Проходили, не надо. V>Просто ты не разобрался с ним.
В своё время я был фанатом svn и против git агитировал...
V>>>Простейшая операция — в рабочей копии с незакоммиченными своими изменениями я хочу забрать с сервака изменение только одного файла. V>>>Причём, я тоже уже вносил в этот файл изменения и хочу, чтобы эти мои изменения еще никуда не коммитились, но в него уже зашли изменения с сервака. Это весьма популярный "рабочий" сценарий при коллективной работе над некоей задачей. V>·>Вот за такие операции svn и не любят. V>Просто ты не разобрался с ним.
...а потом слишком хорошо разобрался.
V>·>К тому же, хорошая СКВ должна обеспечивать обратимость изменений V>Изменения обратимы, будучи зарегестрированы в системе. V>Разумеется, всё важное "сохраняется", т.е. коммитится. V>А если ты редактировал документ (это просто аналогия) но решил какие-то изменения не сохранять — это ж твоё право, верно? V>Ну вот ты что-то заметил, решил исправить, рядом за столом сидит другой коллега и говорит: "это уже исправлено, 5 сек забирай". V>Закидывает только этот файл, ты тоже забираешь только этот файл. V>10 сек на всё.
Х-як, Х-як И В Продакшн™. А где хотя бы один успешный прогон тестов CI?
V>А в git — хрен там. V>В гит вокруг тривиальщины происходят такие пляски с бубном, что ПЕРЕД началом любой совместной разработки принято договариваться, чтобы не слишком задевать крылом друг друга. А это, называя вещи своими именами, — профанация совместной разработки.
Бред. Если у тебя возникают какие-то такие сложности, добро пожаловать в Управление Проектами или Средства Разработки — опиши проблему, решим.
V>·>а вот после такого магического апдейта-мержа вернуться к предыдущему состоянию просто невозможно. V>В этом и состоит цель такой операции — "запороть" только один какой-то файл или поддиректорию.
Спасибо, но я не хочу ничего запарывать.
[стандартное словоблудие поскипано]
V>>>А в git надо выполнить кучу приcеданий для такой тривиальщины. V>·>Апдейт всего работает достаточно быстро и надёжно, что так изгаляться просто не приходится. V>Апдейт всего практически никогда не нужен при активной совместной разработке. V>Более того — он сильно вреден, т.к. ведёт к распылению внимания и трате в 3-5 раз большего времени, т.к. при "обновлении всего" вытягивается слишком много изменений по многим зависимостям.
Не понял. Ты вручную что-ли мешки тягаешь? Нажал кнопочку "Update" и собственно всё.
V>В итоге, чтобы суметь в git работать совместно и при этом оперативно, как в svn, надо будет создавать примерно 5-7 подветок в день и коллеги должны тянуть друг у друга конкретные эти подветки, что само по себе является идиотизмом.
Я понимаю, с т.з. svn 5 веток это кашмар и ужас. Но в git это тривиальные pull requests, changesets, etc.
V>Собсно, на твою близорукость в этом вопросе (и не только на твою) я уже указывал — git НЕ предназначен для организации коллективной realtime-разработки. Он заточен ровно наоборот — на неспешную независимую offline-разработку. Да еще и желательно над разными частями системы. А м/у этими сценариями пропасть, неужели сам не видишь?
Бред. Факты показывают обратное.
V>Имено поэтому Mercurial популярен до сих пор в некоторых активно развивающихся проектах — ведь он умеет быть и как svn и как git в самых популярных сценариях разработки.
Потому что слезть дорого.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>Вот. Ты уводишь людей в оффтоп через примитивную технику — через провокации. ·>А ты — через обычное словоблудие.
Конкретно в том сообщении я дал оценку злостному оффтоперу.
V>>В общем, попробуй еще раз. ·>Надоело. Если есть что сказать — говори сразу. А в угадайку играть я не хочу.
Хы, сначала ты попытался поумничать через нарушение правил русского языка при формулировании предложений.
А когда тебе указали на столь, сорри, дешевый трюк (троллинг, то бишь), так тебе резко "надоело". ))
А чего не "надоело" ДО того, как решил потролльничать?
V>>Коммит — это свершение пользователем некоей операции над системой. В дальнейших логических рассуждениях мы к этой операции привязываемся. Причём, даже ты чаще рассуждаешь о коммитах в общепризнанном смысле, а не в смысле тонкостей их хранения в git. И только когда тебе нечего сказать по-сути, включаешь свою шарманку об "апострофах" и прочем "вы ничего не понимаете, я несу вам светоч знаний". ·>Не "некой", а вполне конкретной. Опять насловоблудил.
Хы-хы.
Я лишь вернул тебя на грешную землю — ты же сам чаще используешь слово "коммит" ровно в том смысле, который использовал я.
Т.е., как ни крути, но твои придирки, возникающие в удобные же для тебя моменты, — это нечистоплотность в споре.
V>>А без новой информации это будет лишь сочетание неспособности въехать суть обсуждения с банальным хамством. ·>Новой инфы у меня достаточно. Например, если бы для тебя инфа что rebase это простой bash-скрипт была не новой. ты бы чушь типа "любые манипуляции с графом комитов "унутре" происходят через rebase" не писал бы изначально.
ЧТД. ))
Разбираем очередное откровение:
rebase это простой bash-скрипт
1. Оказывается, rebase — это часть программы, написанная на некотором языке программирования.
Сногсшибательная информация, спасибо.
2. А будешь ли есть свою шляпу, если найдутся реализации git, где это действие НЕ является bash-скриптом, а является обычной подпрограммой на C/C++, используемой для реализации практически любых манипуляций с графом? Как и другие операции, типа diff, apply patch и т.д. тоже являются обычными подпрограммами, а не внешними утилитами? Так что тогда, ы?
Итого, ты опять во всей красе — сообщил с важным видом некую информацию, которая (1) абсолютно не важная и (2) абсолютно не верная.
·>Я прекрасно понимаю, что всю новую инфу ты тупо игнорируешь, гордость не позволяет, но этот форум могут читать и другие люди.
Я не игнорирую новую информацию, я просто не вижу её от тебя.
Я вижу непрерывную последовательность технических ошибок, совершаемых с особой помпезностью, что лишь усиливает эффект.
·>[восторженный интерес к моей персоне проигнорирован] ·>Если тебе так интересно пообсуждать мою личность — добро пожаловать в мой личный блог.
Твоя личность мне не интересна.
Дело не в ней, а в твоих манерах вести технический спор.
Ты не соблюдаешь правила хорошего тона, руинишь тем самым предмет спора, в итоге продолжать техническую часть обсуждения становится бессмысленным. Обычно в таких случаях я говорю "фе" и удаляюсь. Как в предыдущих обсуждениях с тобой же, например.
Но, устав от злостности совершаемых тобой нарушений этих правил, был вынужден расписать суть твоих нарушений целиком.
Считай это проявлением альтруизма с моей стороны.
В принципе, если тебя опять будет заносить, то всегда можно будет дать ссылку на это сообщение: http://www.rsdn.org/forum/job/7050222.1
с просьбой пройтись по последним двум абзацам.
Здравствуйте, ·, Вы писали:
V>>Зачем ты выделенное удалил. Опять прикидываешься? ·>"одновременно разрабатываться." — это что-ли? Я не знаю что это означает для тебя. Могу немного подробнее рассказать. У нас несколько сотен приложений (что-то типа soa архитектуры), которые постоянно меняются. Скажем, в прошлом году были изменения для MiFID II и это затронуло практически каждое приложение. А ещё плюс тут же всяческие тесты, конфиги и т.п. вот 25к и набежало.
Набежать может за много много лет, но одновременно разрабатывается какой-то мелкий процент.
V>>Ставишь TortoiseSVN и проверяешь. Чем не эквивалент? ·>Ты мне толком скажи. Я привёл точную команду "git commit -am wip & git push" всё. А ты мне что-то невнятное мычишь про клики мышой, да "ставишь и проверяешь".
Я использую гуйню для выбора того из чего надо сделать патч. Это быстро и удобно. Как ты будешь выбирать какие файлы добавлять в патч через консоль? Мисье извращенец?
·>Нет. Ты заявил "Он и лучше гита работает." бездоказательно. Какое доказательство и с чего это вдруг ты с меня требуешь — для меня тайна.
Я уже тебе доказал это количеством команд, которое надо запоминать. Пезупречно лучше по этому параметру.
V>>Публичность этому не мешает и даже помогает. А вот при закрытой форме можно нагородить такой огород, что никакой мерж не справиться. ·>Каким образом помогает? Никто просто не будет заглядывать в эти ветки и городи что хочешь.
Как раз заглядывают.
·>А от "никакой мерж не справится" — мержся почаще и будет тебе щастьё.
Всех со всеми через глубокие деревья которые ты по ссылкам приводил? Неа, спасибо.
V>>·>А что тебе непонятно в вопросе? Попробую переформулировать. Вот тебе некоторые примеры воркфлоу. Теперь объясни какой частью воркфлоу является изменение комментов коммитов? V>>Такое что это практическая необходимость исправить и дополнить комментарий. Ты будешь ещё с этим спорить? ·>А в киеве дядька. Практическая необходимость это, конечно, круто. Но зачем ты её ввернул в разговор о воркфлоу? Как обычно, с темы съехать?
Потому-что это часть процесса коммита. Что ты всё дурачком прикидываешься?
V>>>>П-бол. V>>·>У тебя где-то стала повышаться температура? Аргументы, вижу, стали жарче. V>>Твои жареные аргументы меня не интересуют. ·>Если мои аргументы что-то там у тебя жарят, я тут непричём.
У тебя температура а жарят у меня?
V>>Не не даёт потому-что сразу ругается на непустой каталог. ·>Ну задай другой каталог или удали тот, который мешается. В чём вопрос-то?
·>То что не относится к теме обсуждения — да, стараюсь игнорировать, чтобы не поддаваться на провокации сведения темы в говно.
Нет, ты игнорируешь факты, чтобы не пришлось отдуваться за overbloat гит.
V>>>>Нахрена там писать число, которое не связано с билдом? V>>·>Мне пофиг на билды. Ты их тут сам придумал. V>>Я ничего не придумывал. Это устаявшая практика в версии продукта писать номер билда или коммита. ·>Пусть, и что? Какое это имеет отношение к обсуждаемой теме? Опять съезжаешь в сторону?
Сначало ты спихнул тему на то, что я что-то там придумал. Теперь "пускай так". Это имеет прямое отношение. Ещё раз для слепых и глухих повторяю: по номеру билда/коммита локализуется место в исходниках без всяких бисектов.
V>>·>Я говорил о версиях и количестве коммитов между ними. Билды не относятся к вопросу вообще никак. V>>Ещё как относятся. Приходит отчёт с ошибкой связанной именно с версией у пользователя, по-которому ищется тот самый билд или коммит, как минимум чтобы воспроизвести проблему. ·>Ок. Проблему воспроизвели. В версии X проблема воспроизводится, в версии Y — не воспроизводится. Между версиями X и Y — тысячи коммитов, тысячи изменённых файлов. Дальше что?
Место нашли, але. Какой нафик Y?
V>>>>Кто мене там про хакеров заявлял? Они же могут всё? Значит в гите с чужим ключом будут коммитить. V>>·>Я тебе уже объяснял про чужие ключи. Попробуй описать модель атаки с уводом чужих клучей и сравни с тем что я описал. V>>Зачем мене ещё что-то описывать? Я как оппонент заявлю: "хакеры могут всё", этого достаточно. ·>Верно, достаточно чтобы свести обсуждение в говно. Собственно, как я понял, у тебя это и есть цель дискуссии.
·>Воинствующее мракобесие.
·>Чем доказал, тем что его на помоечку отправляют?
·>Балабол.·>Балабол.·>Балабол.
Зеркало не мешает?
V>>>>В-третьих, можно всё поломать, т.к. свн хранит дельту от предыдущей версии, которая будет подменена и соответственно сломает базу. V>>·>А можно и не поломать. Я так делал. Не ломалось. V>>Сначала объясни что ты делал. ·>Да я уж объяснял — правил старые коммиты (не с целью хака, конечно, к сожалению, а чтобы историю мержей и правок сделать чуть более вменяемой) путём отката до нужной ревизии и перепроигрывания чуть подправленных коммитов. Но это был самый первый способ что я нашел. Если повнимательнее покопаться в формате
И ты решал что хакеры могут использовать это во зло, я угадал? А чего ты взял что можно закоммитить туда какой-то бакдор?
·>Ты просто не читаешь что тебе пишут. Я пишу _коммиты_ защищены от _модификации_. Коммит в конец блокчейна не может никак модифицировать уже существующий коммит. Коммит в конце блокчейна окажется под тщательным анализом, в отличие от незаметной модификации каких-то уже давно забытых.
Приведи пример модификации на обычной базе из 3х коммитов.
V>>·>Полностью согласен. Но всё-таки гораздо лучше чем svn. V>>Само существование git-svn с жуткими кастылями доказывает обратное. ·>Доказывает что именно? С какими именно костылями? https://public-inbox.org/git/1187166615.20170604023631@inbox.ru/t/
* одна команда несовместима с другой
* реализация пустых каталогов через Ж, вместо того чтобы сделать пустые каталоги частью дизайна (постоянно кучу каких то пустых варнингов выдает)
* невозможность клонировать часть репы с теми же хешами
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, vdimas, Вы писали:
V>·>Надоело. Если есть что сказать — говори сразу. А в угадайку играть я не хочу. V>Хы, сначала ты попытался поумничать через нарушение правил русского языка при формулировании предложений. V>А когда тебе указали на столь, сорри, дешевый трюк (троллинг, то бишь), так тебе резко "надоело". ))
А ты надеялся я тут вечно в твой цирк играть буду?
V>А чего не "надоело" ДО того, как решил потролльничать?
По сути есть что сказать про своё "введение в дело" и перестановки коммитов? Или попортил лужу и убёг?
V>>>Коммит — это свершение пользователем некоей операции над системой. В дальнейших логических рассуждениях мы к этой операции привязываемся. Причём, даже ты чаще рассуждаешь о коммитах в общепризнанном смысле, а не в смысле тонкостей их хранения в git. И только когда тебе нечего сказать по-сути, включаешь свою шарманку об "апострофах" и прочем "вы ничего не понимаете, я несу вам светоч знаний". V>·>Не "некой", а вполне конкретной. Опять насловоблудил. V>Хы-хы. V>Я лишь вернул тебя на грешную землю — ты же сам чаще используешь слово "коммит" ровно в том смысле, который использовал я.
Опять со смыслами играешься, а по сути сказать нечего.
V>1. Оказывается, rebase — это часть программы, написанная на некотором языке программирования. V>Сногсшибательная информация, спасибо.
Для спасибо есть кнопочка в углу.
V>2. А будешь ли есть свою шляпу, если найдутся реализации git, где это действие НЕ является bash-скриптом, а является обычной подпрограммой на C/C++, используемой для реализации практически любых манипуляций с графом? Как и другие операции, типа diff, apply patch и т.д. тоже являются обычными подпрограммами, а не внешними утилитами? Так что тогда, ы?
Успехов.
[восторженный интерес к моей персоне проигнорирован]
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>В своё время я был фанатом svn и против git агитировал...
Так и запишем: упоротость является постоянной чертой характера.
))
А мне никогда не нравился svn, хотя я признаю удобство НЕКОТОРЫХ сценариев с ним.
Git мне нравится больше, хотя я признаю его неудобство для НЕКОТОРЫХ сценариев.
По-сути, мне пришлось поменять принципы разработки, чтобы подстроиться под специфику git.
И я способен объективно признать, что кое-какого ребенка по дороге выплеснул.
А ты не способен.
Здравствуйте, ·, Вы писали:
V>>·>Надоело. Если есть что сказать — говори сразу. А в угадайку играть я не хочу. V>>Хы, сначала ты попытался поумничать через нарушение правил русского языка при формулировании предложений. V>>А когда тебе указали на столь, сорри, дешевый трюк (троллинг, то бишь), так тебе резко "надоело". )) ·>А ты надеялся я тут вечно в твой цирк играть буду?
Т.е. слил?
V>>А чего не "надоело" ДО того, как решил потролльничать? ·>По сути есть что сказать про своё "введение в дело" и перестановки коммитов? Или попортил лужу и убёг?
Я уже говорил — при рассуждениях мы отталкиваемся от операции "ввода в дело" некоего набора изменений.
Мы даже даём этой операции осмысленное название — обязательный коммент к ней.
Как так вышло, что обязательность наличия осмысленного сообщения, привязанного к этой операции, не натолкнуло тебя на озарение, ы?
V>>Я лишь вернул тебя на грешную землю — ты же сам чаще используешь слово "коммит" ровно в том смысле, который использовал я. ·>Опять со смыслами играешься, а по сути сказать нечего.
По-сути я уже сказал — ты придрался ровно к тому же, что позволяешь сам себе в большинстве своих постов.
Итого — нечистоплотность.
V>>1. Оказывается, rebase — это часть программы, написанная на некотором языке программирования. V>>Сногсшибательная информация, спасибо. ·>Для спасибо есть кнопочка в углу.
Это была ирония, могу нажать на смайлик, если настаиваешь.
V>>2. А будешь ли есть свою шляпу, если найдутся реализации git, где это действие НЕ является bash-скриптом, а является обычной подпрограммой на C/C++, используемой для реализации практически любых манипуляций с графом? Как и другие операции, типа diff, apply patch и т.д. тоже являются обычными подпрограммами, а не внешними утилитами? Так что тогда, ы? ·>Успехов.
Т.е. слился?
·>[восторженный интерес к моей персоне проигнорирован]
Ну отчего же?
Ты же так тщательно руинил исходную тему, так давай же теперь просто трындеть и трындеть ни о чём!
Здравствуйте, vdimas, Вы писали:
V>·>В своё время я был фанатом svn и против git агитировал...
V>А мне никогда не нравился svn, хотя я признаю удобство НЕКОТОРЫХ сценариев с ним. V>Git мне нравится больше, хотя я признаю его неудобство для НЕКОТОРЫХ сценариев.
Эти сценарии либо чрезвычайно специфичны, либо показывают о серьёзных проблемах в организации разработки, которые надо фиксить.
А по поводу того сценария апдейта файла я так и не понял что в нём такого, что git не умеет или какие хитрые приседания ты имел в виду? "checkout -p" позволяет мержить нужное, вплоть до отдельной строки.
Но так делать всё равно не надо (по крайней мере в описанной тобой ситуации), ибо нефиг.
V>По-сути, мне пришлось поменять принципы разработки, чтобы подстроиться под специфику git.
Поменять в лучшую сторону.
V>И я способен объективно признать, что кое-какого ребенка по дороге выплеснул. V>А ты не способен.
Если только романтка, трава была зеленее.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vdimas, Вы писали:
V>>>·>Надоело. Если есть что сказать — говори сразу. А в угадайку играть я не хочу. V>>>Хы, сначала ты попытался поумничать через нарушение правил русского языка при формулировании предложений. V>>>А когда тебе указали на столь, сорри, дешевый трюк (троллинг, то бишь), так тебе резко "надоело". )) V>·>А ты надеялся я тут вечно в твой цирк играть буду? V>Т.е. слил? Да. Я позорно слил, а ты молодец. Можешь успокоиться.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>А мне никогда не нравился svn, хотя я признаю удобство НЕКОТОРЫХ сценариев с ним. V>>Git мне нравится больше, хотя я признаю его неудобство для НЕКОТОРЫХ сценариев. ·>Эти сценарии либо чрезвычайно специфичны, либо показывают о серьёзных проблемах в организации разработки, которые надо фиксить.
На этом воображение заканчивается?
Маловато привёл вариантов.
Когда я впервые знакомился с SVN, то он вызвал у меня отторжение из-за способа хранения бранчей и тегов. Мой инженерный опыт протестовал против такого нелепого промаха. Этот момент выглядел как эксперимент на коленке, которому перед запуском в продакшен забыли сделать ревью с соответствющей доработкой.
И, наоборот, когда я разбирался с устройством хранимых данных git, я обнаружил за собой реакцию "вот здесь отлично!".
Просто надо понимать некоторую ортогональность принципов хранения данных в системе vs поддерживаемых "изкаробки" сценариев инструмента-клиента. Одно не обязательно следует из другого. Но ты регулярно используешь первое как "аргумент" в пользу каких-то особенностей второго, что нехило доставляет. Выходит, плохо понимаешь связь первого со вторым.
·>А по поводу того сценария апдейта файла я так и не понял что в нём такого, что git не умеет или какие хитрые приседания ты имел в виду?
Я имел ввиду сценарий, когда один разработчик в один клик закидывает только один файл, а другой в один клик его же забирает.
Ну или в одну команду.
Разумеется, это можно повторить и в git сразу несколькими способами, но не в один клик или одну команду.
·>"checkout -p" позволяет мержить нужное, вплоть до отдельной строки.
Для простоты пойдёт и git checkout -f [<tree-ish>] [--] <pathspec>.
В любом случае это не будет первой командой в списке их для реализации описанного сценария.
Да еще надо помнить точное название удалённой (в смысле remote) ветки внутри собственного клона.
·>Но так делать всё равно не надо (по крайней мере в описанной тобой ситуации), ибо нефиг.
Ибо тебя забыли спросить, как надо делать, а как не надо.
V>>По-сути, мне пришлось поменять принципы разработки, чтобы подстроиться под специфику git. ·>Поменять в лучшую сторону.
Опять оценочные суждения даже без минимальных критериев?
Как знакомо-то.
Кто тебя вообще спрашивает о твоих субъективных оценках? ))
Что за, блин, манеры выскочки?
В технчиеских спорах ожидаются или аргументы или честное молчание.
V>>И я способен объективно признать, что кое-какого ребенка по дороге выплеснул. V>>А ты не способен. ·>Если только романтка, трава была зеленее.
Это называется "жить в своём собственном мире", бо на основе оценочных суждений можно нарисовать себе произвольную реальность. ))
Ты ведь не ставишь критерием эффективность, т.е. экономию времени и квантов внимания на всю эту шелуху.
Наоборот, ты призываешь уделять всей этой шелухе как можно больше внимания.
За счёт целевой работы, вестимо.
Как номер билда относится к количеству коммитов?
А чего ты взял что можно закоммитить туда какой-то бакдор?