Как стать автором
Обновить

Комментарии 48

Да, рекомендую тот ретрочатик

Продублирую ссылку, чтобы в тексте не искать. Тоже рекомендую, тепло и лампово.
Отличная работа. Отдельное спасибо за раздел «Оформление изменений в чужой проект» — теперь эту статью можно как мануал другим показывать!
Спасибо. В общем-то так и старался написать, чтобы была готовая мурзилка-мануал.

Только у вас там что-то странное написано:


но когда вы делаете коммит, то не создаёте новый, а добавляете изменения в старый коммит, так чтобы его hash не менялся.

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


И, если честно, мне как принимающему изменения не хотелось бы видеть amend'нутые коммиты после ревью — сложнее увидеть, что еще изменилось. Если мейнтейнер репозитория так уж не хочет иметь несколько коммитов после одного PR, то он может вместо мерджа squash'нуть.


Короче, в этом случае аменд лучше не делать.

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

Сделать ещё один коммит с исправлениями поверх первого. А потом обычный пуш (без `--force`). Pull request привязывается к ветке, а не к коммиту. После этого в нём появится оба коммита, и будет возможно увидеть как суммарные изменения по обоим коммитам, так и сам отдельный фикс.

Ещё один вариант - автор не принимает ваш пуллоеквест, не просит сделать изменения, а по "образу и подобию" делает коммит от своего имени. Вот от такого поведения желание делать пуллреквесты быстро угасает.

Да ладно, главное конечный результат — код правильный. А ЧСВ почесать это мы в другом месте успеем.

Да ладно, главное конечный результат — код правильный.

А как же это ваше:

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

Сейчас время такое, что нет абсолютно никаких причин тратить время на то, что никто не увидит и не оценит. Т.е. трата времени на абсолютно бесполезные задачи на каком ни будь letcode, более полезна (потому что ссылку на профиль можно куда-нибудь вставить для очередного "упоротого" на олимпиадном программировании - мы типа одной крови: ты и я, как в Маугли).

Лучший способ научиться программировать, который я знаю: это устроиться на работу программистом и начать программировать. Да, не все этому могут научится, но и не все могут научиться водить самолёт, например. Вот сейчас мне приходиться переделывать проект после "новичка", который он пилил пол года: ощущение такое, что у него за время написания проекта развился рак головного мозга. :)

Лучший способ научиться программировать, который я знаю: это устроиться на работу программистом и начать программировать.

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

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

Тут напрашивается аналогия с ножом и маньяком убийцей: виноват ли нож в том, что кто-то им режет колбасу, а кто им режет людей? Бизнес модель подобных фирм обычно предполагает низкий уровень разделения труда, за счёт чего достигается определённая "гибкость", что опять же не позволяет им использовать наиболее эффективные методики написания кода. Это обычно формирует дополнительную прибыль, потому что позволяет экономить на качестве разработчиков. Очевидно, что люди, которые достаточно долго поварились в этом "бульоне", на своём месте приносили дохода больше, чем была их зарплата и пр. издержки т.е. они были эффективны (даже, не смотря на то, что своей работой увеличивали энтропию вселенной). Да, сейчас, очень много не обучаемых людей (начальство обычно подкидывает мне раз в год юного подавана и за последние 6 лет ни один не смог - все почему-то говорят, что это слишком сложно), но это же не повод всех мазать одной краской. :)

Если отбросить форму беседы, как спор, то скажу так:

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

Толковые ребята всегда обучают себя сами.

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

Лучше git push --force-with-lease .Это тоже форс, но он не позволит случайно переписать чужой коммит

Видимо потому, что я гуглил, гуглил и не нашёл эту чудесную утилиту. Ну и чтобы был хороший пример :).

Спасибо, гляну при случае.

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

Я даже нашел сорс и скомпилированный исполнимый коммандник. Но, к сожалению, запустить даже из под DOSBox не получилось - не реагирует на горячие клавиши. Видимо, в DOSBox нельзя перехватить клавиатурное прерывание 16H. Да и вообще нельзя подменять/перехватывать вызов обработчиков.

Ну у меня задача именно на реальном железе. Тем более, что ДОС можно накатить на виртуальную машину.

Могу выслать командник и сорс. Правда, не уверен, что именно это та версия, которая с графикой работает корректно. Вернее, работает только с EGA - VGA, когда это писалось, еще не были широко распространены.

Не, спасибо, мне в сути для моих задачек хватит этой утилиты. Тут вот ещё одну посоветовал fk0.

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

Была же готовая программа для этих целей, не помню название.

Artmoney?

Да, именно она.

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

Вы вносите эти изменения точно так же локально, но когда вы делаете коммит, то не создаёте новый, а добавляете изменения в старый коммит, так чтобы его hash не менялся.

Это утверждение не совсем корректно. git commit --amend создаст новый коммит, и хэш у него будет новый.

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

В общем-то можно и без --amend, засквошить коммиты можно и непосредственно перед слиянием.

Ну и пушить лучше через git push --force-with-lease — это безопаснее. Всё ещё не слишком хорошо, но в свою личную ветку можно.

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

Под рукой pull request-а на GitHub не оказалось, чтобы проверить. Разве у GitHub нет возможности squash-нуть все коммиты в MR в один merge коммит и не использовать хак с force push?

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

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

Если ветка в едином репозитории, то да. Тут залив происходит из одной репы в другую.

Не возьмусь утверждать что это сейчас именно так, но насколько я помню, там что с форка, что с другой ветки - работает одинаково.
последние несколько лет, работал с единым репозиторием. до этого год через форк.
(А несколько месяцев назад сменил работу и тут гитлаб. Так вот у меня перманентная фрустрация: какого хера и для кого это сделано вообще? это как комент к вашему "gitlab, он сделан людьми для людей", так что дело привычки, надеюсь и я в какой-то момент привыкну к гитлабу)

А зачем вы сами делаете мердж? Это обязанность того, кто принимать будет, а не ваша

Есть конечно


  • простой мердж, со своим сообщением
  • squash всего, объединение всех сообщений коммитов в список
  • ребейз поверх цели и встраивание коммитов без мерджа (fast-forward)
  • обязательный мердж (даже когда можно сделать fast-forward)

не использовать хак с force push?

Почему вы называете это хаком?

Если в настройках сменить кодировку на CP866 (в моём случае это кириллица),

Эм… а что, есть другие варианты?


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

Вы из какого века пишете? Ничего не стирается, на GitHub-е уже лет 5 как все ваши force-push-и ничего не забывают и даже кнопочка рядом с каждым есть, чтобы посмотреть различия force-push-нутого от того, что было раньше (любуйтесь: https://github.com/pegjs/pegjs/pull/399). Может только если вы зайдете в репозиторий и принудительно запустите в нем git gc, ну так кто ж в этом виноват...


И что сложного в создании PR? После пуша там висит уведомление о том, что вы только что ветку протолкнули, хотите сделать PR? Не заметить просто нереально. Не говоря уж о том, что при пуше новой ветки git возвращает сообщение с url-ом для создания PR, только кликай и все (может в консольном и нет такого, никогда не пробовал, но что-то я сомневаюсь, что это самодеятельность TortoiseGit)
Так что нечего дурить молодежи голову


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

А вот это действительно очень и очень ценная мысль.

Скачал и запустил ваш исправленный бинарник и запустил во FreeDOS.

Спасибо за замечание, лучше было в личном сообщении. Пожалуйста проверьте ещё раз, должно всё работать. Заменил на рабочий.

А вот вопрос из практики, пока нерешенный. Есть проект А, и его форк Б. Владелец Б делает пулл-реквест в А, который фиксит багу, которая лично мне очень мешает. Автор А этот пулл-реквест не принимает, а автор Б уходит в закат и не ребейзит его на свежий мастер А. Ребейз там несложный, но автоматом не поребейзит - А развивается довольно динамично. Я сдуру форкнул Б и поправил ПР, но теперь могу его отправить только в Б, а там никакой активности. Форкнуть А теперь не дает гитхаб, говорит уже есть форк.

Внимание, вопрос: как мне нормально закоммитить рабочий ПР, желательно не снося свой форк репы? Ну и чтобы не обидеть автора Б, который собственно основной автор патча?

Весь вечер думал над вашим вопросом, элегантного решения нет. Я бы сделал так, сделал форк от действющего A, сделал бы ребейз вашего форка от Б и смерджил его туда, а потом бы уже этот форк добавил бы в А. Но если у вас будет скваш коммитов, то работа того товарища потеряется.
Я бы сделал так, сделал форк от действющего A

Сказано же, что GitHub не даёт сделать форк, потому что уже есть форк от форка:


Форкнуть А теперь не дает гитхаб, говорит уже есть форк.
Ну в локальной репе-то можно делать всё что душе угодно, а там отребейзить всё локально и сделать всё по уму.

Я вижу 2 варианта:


  • Можете написать в поддержку GitHub-а, чтобы ваш форк сделали самостоятельным репозиторием. Затем форкните заново
  • Можете слить себе все нужные ветки локально, удалить свой форк на гитхабе, сделать новый форк от правильного репозитория

В конце обоих вариантов проталкиваете изменения из вашей локальной копии в новый форк. Авторство коммитов сохранится.

Гитхаб же вроде должен давать выбрать вообще любой форк при оформлении ПР, разве нет в выпадающем списке?


Заголовок спойлера

image

Был Game wizard. О возможностях не знаю, а название вспомнил.

В досовские времена пользоался программой hiew, довольно удобном hex-редакторе и дизассемблере файлов. Я написал резедентную программу, которая перехватывала попытки открытия файлов ¨mem¨ и ¨all¨, которые позволяли редактировать с помощью hiew память и диск, было очень удобно.

По-немецки цацки-пецки...

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.