LINUX.ORG.RU

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

 , ,


4

9

сабж

Статья вызвала бурю эмоций на HN.

Сама статья мне очень понравилась. Очень красочно описывает моё отношение к Go.

This fake “simplicity” runs deep in the Go ecosystem. Rust has the opposite problem - things look scary at first, but it’s for a good reason. The problems tackled have inherent complexity, and it takes some effort to model them appropriately.

Ну или как я люблю говорить: Go примитивный, а не простой.

PS: Работа со строками в Go напомнила недавний холивар (C рулит и педалит.). @grem’у понравится. Путь к файлу содержит недопустимые символы? Та забей!

@WitcherGeralt

Ответ на: комментарий от byko3y

Вообще всё делается через ветки.

git co -b my-feature-x
touch one.txt
git add ./
git cm "add one.txt"
git co master
git merge my-feature-x
git push
# [on conflict]
git pull
<resolve>
git push

И ветка у тебя только локально. И в приницпе co -b можно сделать всегда. Ну и так далее. И есть ещё git pull --rebase ну и так далее.

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

kostyarin_ ★★ ()
Ответ на: комментарий от kostyarin_

Ну так это ты хочешь всё усложнить. Вообще-то никто так не делает

Конечно не делает — на stackoverflow и в туториалах советуют придерживаться схемы с чистой репой и единственным сценарием коммитов; шаг в сторону — расстрел. Ну, то есть не расстрел, а «любись как хочешь — твои проблемы». Большинство даже не рискуют в итоге сходить с проторенной дорожки. В итоге, спустя время они привыкают и даже не задумываются над тем, что им на самом деле неудобно.

byko3y ★★ ()
Ответ на: комментарий от kostyarin_

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

Вот мои:

br = branch
co = checkout
st = status -sb
l = log --graph --pretty=format:'%Cred%h%Creset %C(bold blue)<%an>%Creset%C(yellow)%d%Creset %s %Cgreen(%cr)' --abbrev-commit --date=relative 

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

Aber ★★★★ ()
Ответ на: комментарий от Aber

Всего N лет назад разные проекты использовании разные VCS, у одно это bazzar, другого svn, у третьего mercular, разве от этого было проще? Надо было знать CLI всех этих тулов, хотяб чтоб скачать исходники, найти изменения в истории, понять концепцию используемого бранчинга в конкретном VCS чтоб знать где искать

К абсолютно любому из упомянутых инструментов привыкаешь очень быстро. У меня вообще никогда не возникало реакции «блин, тут свн используется. Как же я теперь с ним буду работать?». И только Git удалось создать реакцию «ЧТО ЭТО? ЧТО МНЕ ВООБЩЕ С ЭТИМ ДЕЛАТЬ?». Еще раз повторюсь: эта реакция коррелирует с опросом 4000 пользователей Git в 2014, которые тоже в большинстве считали, что интерфейс и доки у Git плохие.

byko3y ★★ ()
Ответ на: комментарий от byko3y

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

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

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

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

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

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

kostyarin_ ★★ ()
Ответ на: комментарий от Aber

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

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

kostyarin_ ★★ ()
Ответ на: комментарий от byko3y

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

annulen ★★★★★ ()
Ответ на: комментарий от byko3y

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

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

annulen ★★★★★ ()
Последнее исправление: annulen (всего исправлений: 1)
Ответ на: комментарий от byko3y

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

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

annulen ★★★★★ ()
Последнее исправление: annulen (всего исправлений: 1)
Ответ на: комментарий от Aber

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

Так я профессионально копипащу их с интернета по запросу в гугле 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/

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

kostyarin_ ★★ ()
Ответ на: комментарий от kostyarin_

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

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

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

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

byko3y ★★ ()
Ответ на: комментарий от byko3y

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

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

kostyarin_ ★★ ()
Ответ на: комментарий от kostyarin_

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

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

byko3y ★★ ()
Ответ на: комментарий от kostyarin_

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

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

byko3y ★★ ()
Ответ на: комментарий от byko3y

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

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

kostyarin_ ★★ ()
Ответ на: комментарий от byko3y

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

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

kostyarin_ ★★ ()
Ответ на: комментарий от annulen

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

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

byko3y ★★ ()
Ответ на: комментарий от annulen

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

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

byko3y ★★ ()
Ответ на: комментарий от annulen

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

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

byko3y ★★ ()
Ответ на: комментарий от byko3y

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

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

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

Aber ★★★★ ()
Ответ на: комментарий от kostyarin_

Я добавил одну строчку в файл на 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 не может это слить автоматически.

byko3y ★★ ()
Ответ на: комментарий от kostyarin_

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

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

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

byko3y ★★ ()
Ответ на: комментарий от byko3y

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

Aber ★★★★ ()
Ответ на: комментарий от byko3y

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

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

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

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

annulen ★★★★★ ()
Ответ на: комментарий от byko3y

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

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

annulen ★★★★★ ()
Ответ на: комментарий от Aber

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

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

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

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

byko3y ★★ ()
Ответ на: комментарий от byko3y

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

peregrine ★★★★★ ()
Ответ на: комментарий от annulen

Изменения из 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 отработают быстро и тихо.

byko3y ★★ ()
Ответ на: комментарий от byko3y

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

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

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

Aber ★★★★ ()
Последнее исправление: Aber (всего исправлений: 1)
Ответ на: комментарий от byko3y

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

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

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

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

annulen ★★★★★ ()
Ответ на: комментарий от annulen

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

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

byko3y ★★ ()
Ответ на: комментарий от byko3y

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

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

annulen ★★★★★ ()
Последнее исправление: annulen (всего исправлений: 1)
Ответ на: комментарий от byko3y

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

annulen ★★★★★ ()
Ответ на: комментарий от annulen

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

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

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

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

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

byko3y ★★ ()
Ответ на: комментарий от byko3y

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

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

annulen ★★★★★ ()
Ответ на: комментарий от byko3y

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

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

annulen ★★★★★ ()
Ответ на: комментарий от annulen

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

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

byko3y ★★ ()
Ответ на: комментарий от byko3y

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

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

annulen ★★★★★ ()
Ответ на: комментарий от byko3y

И это довольно частая ситуация: я добавил, ты добавил, наши правки независимы, но — упс, 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 не происходит – так просто быстрее. И, к тому же, как ты будет разрешать конфликт на удалённом репозитории. Опять всё клонить себе – двойная работа.

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


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

kostyarin_ ★★ ()
Ответ на: комментарий от annulen

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

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

byko3y ★★ ()
Ответ на: комментарий от annulen

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

grem ★★★★★ ()
Ответ на: комментарий от annulen

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

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

byko3y ★★ ()
Ответ на: комментарий от byko3y

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

maloi ★★★★★ ()
Ответ на: комментарий от grem

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

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

kostyarin_ ★★ ()
Ответ на: комментарий от kostyarin_

Ну и как по твоему он их должен слить? 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», только эти скрипты уже написаны со всеми обработками опасных и ошибочных состояний, и оттестированы.

byko3y ★★ ()
Ответ на: комментарий от annulen

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

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

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

grem ★★★★★ ()
Ответ на: комментарий от byko3y

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

annulen ★★★★★ ()
Ответ на: комментарий от byko3y

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

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

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

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

kostyarin_ ★★ ()
Ответ на: комментарий от byko3y

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

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

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

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

annulen ★★★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)