Там опять Go ругают

Мне кажется, что ты забыл свои собственные слова:

И для «сложных» смертных, которым нужны ещё и merge, rebase и чери-пик (особенно).

Если ты работаешь один или кто-то редко пушит в твой репо, то тебе хватит и pull/commit/push.

Если людей много, то ещё и ветки.

Если конфликты при работе – это сложный случай и нужно мержить ултилитой или как-то.

Те сложности о которых говришь ты (бисект и встроенный веб-сервер) – не нужны никому. Ну бисект нужен, если ты ищешь дыру в чём-то большом. Тут скорее лучше разбить на на подмодули. Получается, что бисект нужен только для неразделяемых монсторов типа ядра Linux. Хотя и это вопрос. Никто не хочет париться с разделением – оттого и бисект. Для ядра может бисект и проще. А вообще, это звоночек.

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

А ещё git имеет экспорт из некоторых (?) других VCS, что сильно упрощает миграцию на него.

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

И только Git удалось создать реакцию «ЧТО ЭТО? ЧТО МНЕ ВООБЩЕ С ЭТИМ ДЕЛАТЬ?»

Этим людям наверное забыли провести инструктаж на работе

Но я не хочу вносить эти локальные правки из Makefile в общую репу

Создаешь ветку, коммитишь туда свои изменения, и ребейзишь когда надо. stash - это для временного хранения мелочей, которые в общем не жалко потерять

Вижу ты алиасами активно пользуешься, кинь свои, хочу что нибудь полезное найти для себя.

Так я профессионально копипащу их с интернета по запросу в гугле git aliases (напр.: https://githowto.com/ru/aliases).

P.S. Где как не в теме про Go это спросить? :)

InstadOf для Go =)

[core]
	editor = nano
[alias]
	co = checkout
	ci = commit
	st = status
	br = branch
	hist = log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short
	type = cat-file -t
	dump = cat-file -p
	cm = commit -a -m
	ignore = update-index --skip-worktree
	unignore = update-index --no-skip-worktree
	ignored = !git ls-files -v | grep \"^S\"

[url "ssh://git@github.com/"]
    insteadOf = https://github.com/

Надо бы для стэша что-то придумать…

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

«Вот, ты правильно хихихикаешь»

Это не наш инструмент — негибкое говно, а мы неправильно организуем наш проект. Давайте лучше покрошим цельный функционал на мелкие-мелкие файлы по 20-50-100 строк, да еще и раскидаем их по разным папкам, чтобы с большой вероятностью не было конфликтов. Я лично был свидетелем такого. И что вы думаете? Конфликты все равно были. Я добавил одну строчку в файл на 5 строчек, а кто-то добавил другую строчку в этот же файл, и вуаля — конфликт правок в файле на 5-6 строк. В одном из тысячи файлов из проекта на 50 тысяч строк.

А решалось всё просто — выкидыванием Git на помойку и применением любого другого удобного решения.

Еще раз повторюсь: эта реакция коррелирует с опросом 4000 пользователей Git в 2014, которые тоже в большинстве считали, что интерфейс и доки у Git плохие.

Это да. Потому что доки довольно обширны. Краткая вводная была бы проще. Я лично осваивал по главе из Railstutorial.

Если ты работаешь один или кто-то редко пушит в твой репо, то тебе хватит и pull/commit/push

Мне хватало «tar -cvf». О чем и начинался разговор.

А ещё git имеет экспорт из некоторых (?) других VCS, что сильно упрощает миграцию на него

Mercurial поддерживает даже подпроекты на SVN и Git.

Я добавил одну строчку в файл на 5 строчек, а кто-то добавил другую строчку в этот же файл, и вуаля — конфликт правок в файле на 5-6 строк.

Ну и? Ты просто пушишь и всё сливается. Если есть конфликты, то их нужно разрешать. И если какой-то инструмент их решает сам, значит и git это может. В других же случаях – решать всё равно приходится вручную. И VCS тут никак не поможет. Если ты коммитишь 5, а Васян 3 на то же место, то что по твоему должна делать VCS? Затереть? Ну так пушь фаст-форвардом, но это вообще не тот путь. Сама разрешить? Как, чёрт побери? Тебе Git даже функцию перехавшую в другой файл показывает – откуда она и всё про неё. Чего тебе ещё не хавтает?

Мне хватало «tar -cvf». О чем и начинался разговор.

«Я хочу чтобы в мою поделку никто другой не пушил», это называется.

Спасибо!

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

Не знаю, кто сбежал. SVN до сих пор достойный варик для централизованной разработки, которая актуальная для многих закрытых проектов. Google использует Perforce вместо SVN, потому что Perforce пошустрее будет, особенно для больших файлов, и тулзы у него попроработаннее.

Этим людям наверное забыли провести инструктаж на работе

Пардон, что на работе должны были делать? Проводить месячный курс по пользованию Git? Мои аргументы сводятся к тому, что VCS должен помогать, но Git слишком мешает в своем помогании.

Создаешь ветку, коммитишь туда свои изменения, и ребейзишь когда надо. stash - это для временного хранения мелочей, которые в общем не жалко потерять

Изменения из stash не пропадают после drop/pop/clear, то есть, в этом плане подобны коммитам, потому механизм хранения локальных правок в stash на самом деле весьма близок к хранению их же локально в коммитах на ветке с последующим rebase+squash.

SVN до сих пор достойный варик для централизованной разработки

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

Еще помню что люди могли несколько дней (и даже неделю) работать над кодом не комитя изменения пока все не завершат. Сейчас это кажется стремным.

Я добавил одну строчку в файл на 5 строчек, а кто-то добавил другую строчку в этот же файл, и вуаля — конфликт правок в файле на 5-6 строк.

Ну и? Ты просто пушишь и всё сливается

Неа, не сливается. Пруф:

$ echo "more 1" >> Makefile

$ git commit -a -m "more 1"
[master 26808c5] more 1
 1 file changed, 1 insertion(+)

$ cd ../test2
$ echo "more 2" >> Makefile
$ git commit -a -m "more 2"
[master f1a4c05] more 2
 1 file changed, 1 insertion(+)

$ git pull ../test
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ../test
 * branch            HEAD       -> FETCH_HEAD
Auto-merging Makefile
CONFLICT (content): Merge conflict in Makefile
Automatic merge failed; fix conflicts and then commit the result.

И это довольно частая ситуация: я добавил, ты добавил, наши правки независимы, но — упс, Git не может это слить автоматически.

Мне хватало «tar -cvf». О чем и начинался разговор.

«Я хочу чтобы в мою поделку никто другой не пушил», это называется

Кинь мне патч - я добавлю и выдам тарбол. Это не так уж и сложно. И это — нулевая точка отсчета, полностью ручное управление ревизиями. VCS должно давать какие-то преимущества относительно этого нуля, чтобы ее применение стало обоснованным.

tar -cvf это годный VCS, первый год освоения git я без него ни одной команды в git не делал :)

Изменения из stash не пропадают после drop/pop/clear

Только после drop или clear их придется искать с собаками

механизм хранения локальных правок в stash на самом деле весьма близок к хранению их же локально в коммитах на ветке с последующим rebase+squash.

да, но возни больше

Проводить месячный курс по пользованию Git?

Я своим одну лекцию прочитал, и все все поняли. Если что-то непонятно, у меня спрашивают. Ни разу не видел, чтобы кто-то делал такую дичь как архивные копии репы, reflog смотреть умеют

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

Да, ветки как бы являются отдельными папками в SVN. Патч можно достать без скачивания всех сорцов через svn diff, применяется через svn patch с отслеживанием созданий и удалений (но не перемещений), а «git rebase» по сути то же самое делает. В Mercurial аналогичная задача решается при помощи «hg diff; hg import», либо расширением «Rebase».

Еще помню что люди могли несколько дней (и даже неделю) работать над кодом не комитя изменения пока все не завершат. Сейчас это кажется стремным

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

Нубы ворчат, а меж тем Git уже дефакто давно стандарт отрасли.

Изменения из stash не пропадают после drop/pop/clear

Только после drop или clear их придется искать с собаками

gitk --all $( git fsck --no-reflog | awk '/dangling commit/ {print $3}' )

Потом поиск по «index on». На моей 2.21 прокатывает.

механизм хранения локальных правок в stash на самом деле весьма близок к хранению их же локально в коммитах на ветке с последующим rebase+squash.

да, но возни больше

Ты хочешь сказать, что «git rebase -i» проще работает, что ли? Если конфликтов нету, то патчи для SVN отработают быстро и тихо.

Стрёмно, если нет резервного копирования.

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

Git и подход принятый в команде может решить эту проблему. Например заставить пушить код в свои бранчи в конце рабочего дня, благо для этого ненужно решать конфликты, всего две команды git commit -m "EOD" и git push

gitk –all $( git fsck –no-reflog | awk ‘/dangling commit/ {print $3}’ )

Ну вот это я и имел в виду «искать с собаками». С веткой все в сто раз проще, так как есть рефлог и ее можно забэкапить

Ты хочешь сказать, что «git rebase -i» проще работает, что ли?

Если у тебя есть несколько локальных патчей, которые ты применяешь к «апстримной» ветке, то тебе не нужен -i, ты просто делаешь rebase (или даже pull –rebase, если лень создавать отдельную ветку)

Я своим одну лекцию прочитал, и все все поняли

Что «всё»? Я думаю, что тебе не нужно объяснять, насколько глубока эта кроличья нора. Мне вот вообще никто ничего не объяснял, но я сам обучился через гугль, stackoverflow, в меньшей степени через официальные доки. Насколько этот канал был востребован у твоих коллег?

Мне вот вообще никто ничего не объяснял, но я сам обучился через гугль, stackoverflow, в меньшей степени через официальные доки.

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

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

Ну вот это я и имел в виду «искать с собаками». С веткой все в сто раз проще, так как есть рефлог и ее можно забэкапить

Что в сто раз проще? Ты сделал rebase, не оставив ссылки на оригинальную ветку — и привет, «gitk –all $( git fsck –no-reflog | awk ‘/dangling commit/ {print $3}’ )».

Стэши при этом тоже прекрасно складируются, по сути выполняя тот же rebase во время «stash pop» или «stash apply».

Если у тебя есть несколько локальных патчей, которые ты применяешь к «апстримной» ветке, то тебе не нужен -i, ты просто делаешь rebase (или даже pull –rebase, если лень создавать отдельную ветку)

"-i" нужен для последующего сплющивания истории.

Вот эта штука в свое время мне помогла: https://vtk.org/Wiki/Git/Workflow/Topic.

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

Ты сделал rebase, не оставив ссылки на оригинальную ветку

Открыл reflog, зачекаутил предыдущий вариант ветки. Чтд.

Я поучаствовал в одном опенсорсном проекте и мне там быстро вправили мозги и отучили делать дичь

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

«-i» нужен для последующего сплющивания истории.

Если у тебя один «временный» коммит, то проще прямо в него коммитить из git gui

И это довольно частая ситуация: я добавил, ты добавил, наши правки независимы, но — упс, Git не может это слить автоматически.

С какой это стати они независимы, если следующая строка определяет следующую команду в Makefile? И git должен магическим образом определить какая из них перед какой?

Ну и как по твоему он их должен слить? 1-2 или 2-1? Если какая-то VCS такое сливает – то это отличный повод от неё избавиться.

Вот смотри. Есть коммит. Скажем так первая точка – отправная (1). Потом ты клонишь репо. Получается разделение на два. Потом коммитишь в основе (2). Потом комитишь в форке (3).

Получается дерево типа

(1)
 |   \
(2) (3)

Из которго тебе нужно получить типа

(1)
| 
(4) = union (2, 3)

Есть только точка от которой начинается. И точка в которой заканчивается.

Допустим, что там нормальный случай, когда несвязанные изменения действительно не связаны. Например два файла one.txt и two.txt.

И ты делаешь

$ git co -b feature-x # git co -b -f temporary
$ git co master
$ git pull --rebase
$ git merge feature-x 
$ git push

Ну или если совсем лень, то

git fetch origin master && git merge origin/master && git push

Можешь алиас на это сбиндить. Вытягивание orign/master, слияние с локальной master, выталкивание в origin/master – прозрачней и быть не может.

Git просто смотрит, что у удалённого репозитория другая голова и отказывает в слиянии. Если ты заметил, то counting objects не происходит – так просто быстрее. И, к тому же, как ты будет разрешать конфликт на удалённом репозитории. Опять всё клонить себе – двойная работа.

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

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

Если понять, что гит - это просто граф из коммитов, у некоторых могут есть «символические имена» (бранчи, теги), и как этот граф меняется ребейзами и мержами, то все становится практически очевидно

Эм-м-м... а ты gitk пробовал запускать? Там как бы даже нарисованы коммиты в виде тех самых графов. Даже в 2010 не пользоваться графическими инструментами для просмотра истории было для меня дичью, для Git даже в консоли сделали «git log --graph --oneline --decorate», чтобы ASCII графикой рисовать историю.

У меня коллегу почему-то раздражает (и не только его), что в git коммиты не содержат информации об имени ветки. Зачем это имя знать хз - у меня в рамках пул реквестов уже куча веток было с одинаковыми именами: как только изменения мерджили, я их просто удалял из своего фотка. Но даже в рамках работы одного репозитория в том же mercurial знание об имени ветки ничем не поможет при плохо написанных комментариях в коммитах.

Открыл reflog, зачекаутил предыдущий вариант ветки. Чтд

Ну. «git stash drop» тебе выводит хэш, по которому можно сразу же восстановить стэш. И чем оно сложнее коммитов?

И какое содержимое Makefile будет после автоматического сливания в hg?

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

Потому что выходцы с SVN боятся и боготворят ветки. А в git имя ветки у меня с моими изменениями может быть эквивалентна имени ветки у тебя с совсем другими твоими изменениями. И в любом случае ветка – кроткоживущая сущность имя котрой выдумывать не стоит по долгу. Фича-Икс. Фича-Икс-2.

Ну и как по твоему он их должен слить? 1-2 или 2-1? Если какая-то VCS такое сливает – то это отличный повод от неё избавиться

Я отвечал на твою претензию, и я оказался прав — в Git проблемы со слиянием возникают всегда, когда над репозиторием работает больше одного человека. Git вообще весь построен на частых слияниях. А это значит, что даже для довольно простого рабочего процесса кодерам придется изучать довольно солидное количество команд Git, которые, оказывается, ни разу не для избранных, а их вынуждены изучать все.

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

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

$ git co -b feature-x # git co -b -f temporary
$ git co master
$ git pull --rebase
$ git merge feature-x
$ git push

Примерно то же делает «hg pull; hg update -m», только эти скрипты уже написаны со всеми обработками опасных и ошибочных состояний, и оттестированы.

чтобы кто-то делал такую дичь как архивные копии репы

Я так изредка делал первый месяц освоения git, т.к. не знал о reflog. Но мне это быстро надоело.

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

Я не понял, это у тебя проблемы с пониманием гита или у меня? У меня с ним проблем нет

Я отвечал на твою претензию, и я оказался прав — в Git проблемы со слиянием возникают всегда, когда над репозиторием работает больше одного человека.

Пуль изменения и всё.

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

Если бы такой скрипт существовал, то его и без тебя написали бы. Но он существует только в твоей фантазии. И git тут совсем не при чём. Тебе нужна крёстная фея, которая будет магическим образом залазить в головы группы разрабов, потом к заказчику, и разрешат всё это и фиксить ошибки. Да – git такого не может, но он и не для этого. И Золушкой не нужно быть – я считаю, что это плюс.

Ну. «git stash drop» тебе выводит хэш, по которому можно сразу же восстановить стэш

В консоль. А рефлог живет в репозитории. Ращница понятна?

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

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

И какое содержимое Makefile будет после автоматического сливания в hg?

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

выходцы с SVN боятся и боготворят ветки

Он даже в какой-то момент думал, что если 80 человек из проекта создадут у себя в git ветку, то всё 80 веток окажутся в репе автоматически.

В mercurial, емнип, по умолчанию пушит все ветки :(

в любом случае ветка – кроткоживущая сущность имя котрой выдумывать не стоит по долгу. Фича-Икс. Фича-Икс-2.

А в рамках внесения изменений в дерево portage тем более.

Кинь мне патч - я добавлю и выдам тарбол. Это не так уж и сложно. И это — нулевая точка отсчета, полностью ручное управление ревизиями. VCS должно давать какие-то преимущества относительно этого нуля, чтобы ее применение стало обоснованным.

А зачем мне заморачиваться с этим, если проще делать clone/co -b/commit/commit/add/commit/rebase -i/push/compare and PR/delete repository.

И это выглядит в твоей системе примерно так:

• wget repo.tar
• wget checksum
• sha256 repo.tar
• use eyes to compare the sums
• tar -xf
• work-wokr-work (loose, repeat)
• tar -xf (we need origin to make a patch)
• make patch
• send the patch via email
• nobody know what’s next and how long

Да, отличная альтернатива, нечего сказать.

т.е. «Упс hg не может слить это автоматически»?