progit
Пошук мейнтейнера
На превеликий жаль часу на проєкт у мене немає.
В моїх великих планах лишалося все перечитати, узгодити (хоч більшість розділів перекладена мною, але зовсім не всі, узгодження не було), перекласти зображення тощо. Але головна перепона зараз у тому, що в оригіналі були зміни генерації і українська версія зараз взагалі не генерується. Ну і взагалі в оригіналі багато змін. Я пробував почати прямо merge з оригіналу, але не здолав.
Якщо хтось має бажання взятися й
- Оновити відповідно до оригіналу, зокрема, щоб почало генеруватися.
- Перечитати все й повиправляти помилки й узгодити терміни.
- Перекласти зображення.
Чи хоча б тільки 1й пункт, я можу дати такій людині права запису до репозиторія, допоможу чим можу, але часу в мене мало.
Можливо, @burlakvo @zmiimz
@hedrok, спробую погратися із 1м пунктом. Спробую завтра і тоді відпишу про результати
Щодо п. 1 є прогрес. Книга генерується. Створив чорнетку Запиту на злиття #206
Чорнетку, бо там вилазять попередження про неправильні якорі. Це не заважає генеруванню, проте це впливає на вигляд. Я ще не розібрався що із ними не так
Класно, що хтось щось робить - дякую :)
Схвалив запуск перевірок на твоєму PR: https://github.com/progit/progit2-uk/pull/206 На жаль, зараз виявив, що я не мейнтейнер цього сховища :) Тож щоб тобі дати права девелопера треба кликати мейнтейнерів оригіналу. Мені достатньо, щоб ти просто підтвердив свою готовність приділяти цьому час - покличу. Поки можу просто заливати що скажеш і коли скажеш (з мінімальним ревʼю).
[Мовна хвилинка: "чЕрнетка", а не "чОрнетка"]
По-перше, дякую за мовну хвилинку )
Там все впало, бо не були оновлені робочі процеси. Оновив, запустив у своєму відсадку - [тут я відволікся і ти вже в PR відписав] працює, хоч і з помилками
@burlakvo я залив https://github.com/progit/progit2-uk/pull/200. Ти там писав, що "звіряв з оригіналом". Але з оригіналом якої версії?
Я розповім, як я планував робити, і чому це не вийшло, і які в мене є зараз ідеї.
У нас є гілка english-version. Це та гілка, відповідно до якої мав би бути весь переклад. Проблема в тому, що їй 8 років уже.
У мене окреме віддалене сховище english:
english https://github.com/progit/progit2.git
Теоретично просто зробивши
git merge english/main
І розвʼязавши всі конфлікти можна було б оновити книжку. Два роки тому я зробив таку спробу, і насправді це доволі зручно, конфлікти мають такий вигляд:
<<<<<<< HEAD
Ми коротко розповідаємо про те, як ви можете змінити назву типової гілки ``master'' у <<ch03-git-branching#_remote_branches>>.
||||||| e17ba13a
We talk briefly about how you can change the default branch from ``master'' in <<ch03-git-branching#_remote_branches>>.
=======
We talk briefly about how you can change the default branch name from "`master`" in <<ch03-git-branching#_remote_branches>>.
>>>>>>> english/main
Також я собі підготував макроси, які перетворюють конфлікт внизу на word-diff:
<<<<<<< HEAD
Ми коротко розповідаємо про те, як ви можете змінити назву типової гілки ``master'' у <<ch03-git-branching#_remote_branches>>.
||||||| e17ba13a
We talk briefly about how you can change the default branch {+name+} from [-``master''-]{+"`master`"+} in <<ch03-git-branching#_remote_branches>>.
>>>>>>> english/main
Тоді стає взагалі очевидно, що виправляти.
Але я тоді просто завʼяз (дуже багато змін) і це тепер просто змарнований час: певен, ніж завершувати те злиття ліпше почати нове.
Зараз подумалося, що можна зробити інакше, зробити
git diff --word-diff origin/english-version 2.1.434 > full-word-diff
git diff origin/english 2.1.434 > full-diff
git merge 2.1.434
# Записати всі файли, де конфлікти
git merge --abort
Далі вносити зміни з full-word-diff та full-diff поступово, а коли завершимо з цим, то можна буде знову виконати merge, і для всіх файлів взяти ours. І нарешті все буде синхронізовано.
Якщо тебе цікавить цей варіант, я можу підготувати всі потрібні файли, розписати план тощо. Просто точково додавати щось з оригіналу оновленого вважаю поганою ідеєю, бо тоді неможливо встежити, переклад якої версії є.
Якщо вважаєш себе в силах, можеш натомість як і я кілька років тому просто зробити merge, але найгірше, що якщо не завершиш, то теж буде просто змарнований час.
Я стягнув з англійського репозиторію майстер гілку і звіряв із нею. Обирав два файли у VS Code і порівнював. Воно виділяє відмінності
Я планував порівняти які файли є, яких нема. А тоді по файлу порівнювати. І так поступово оновлювати сторінки Але так, відстеження версії потрібне. Цього не враховував
word-diff виглядає як магія якась :) Вирішив з цікавості просто злити і найлегше було видалити видалені файли. Тоді збагнув, що окрім різниці форматування треба ж одразу і переклад вичитувати, а місцями і робити. Звісно, можна спробувати, але це скоріше затягнеться і вийде, що одна людина перекладатиме всі зміни (скоріше за все, так і буде, але якщо є варіант віддавати у світ це шматочками, а не все одним шматом через хто зна скільки часу)
Можна клонувати нашу майстер гілку і злити в неї англійську, але із мінімальними правками (форматування, посилання, що не потребує перекладу). А тоді вже виправляти і висмикувати до майстра опрацьовані сторінки. Я до того, що, можливо, зробити word-diff, як ти кажеш, і надіслати це сюди окремою гілкою, аби не тільки локально це було. Може ще хто захоче доєднатися, а підґрунтя вже готове ))
Тож чекаю на твій план :) Давай це зробимо
А поки ще трохи понаступаю на твої граблі із тим злиттям ))
Та зробімо правильно, я все підготую. Нащо на граблі наступати. Підготую файли діфів, план тощо. Потихеньку виправлятимеш, я потихеньку ревʼюватиму.
У мене на вирішення конфліктів в 1 файлі пішло близько 35 хвилин. Ще 97 файлів (UPD: і купка файлів без конфліктів)
Я це роблю в IDE із графічним інтерфейсом для вирішення конфліктів. Я бачу файл в 3 колонках: як зараз, що буде, зовнішні зміни. Помітив, що IDE мені показує і word-diff. Є певні нюанси, але "жити можна"
Якщо цим поки тільки я буду займатися, то я, напевне, можу і без файлів діфів. Зливаю англійську версію, вирішую конфлікти у запланованих файлах, зберігаю ці файли на поличку, скасовую злиття, витягаю файли з полички, коміт, запит на злиття, повторюємо
Ок, роби, як тобі зручно.
Я додав план оновлення, коли оновлюєш файл, став +, будь ласка, тут: https://github.com/progit/progit2-uk/blob/master/update-plan/files.adoc
Ну і можеш прочитати https://github.com/progit/progit2-uk/blob/master/update-plan/plan.adoc?plain=1 - там у коментарях початок того, як я планував це пропонувати ) Може тобі зручніше буде все ж таким чином відтворювати стан конфлікту у файлі.
Як варіант, можна зробити проєкт на GitHub, аби відслідковувати поточний статус (наприклад, ось так)
Але це на випадок, якщо виправляти буде 2+ людини, аби можна було зарезервувати якусь частину роботи за собою, і не почати виправляти одне й те саме
Ознайомився із твоїм методом
Зручно, що маю тільки один змінений файл і IDE не тисне на мене купою конфліктів та рештою змінених файлів
Та все ж бракує магії word-diff. Намагався по різному зробити, але дійшов тільки того, що якщо додати до команди merge-file опцію --diff3, то можна буде порівнювати англійські версії вручну. Я трохи Галя, мені треба щоб підсвітка була, чи бодай виділено, а не порівнювати по слову 2 англійські рядки, щоб потім думати чи виправляти український. Я і з підсвіткою дужки пропустив, виправляти довелося ))
UPD: ще можна робити git merge-file --diff3 $f $f-old-english $f-cur-english і тоді не треба робити git show HEAD:$f > $f-ukrainian бо це один і той самий файл виходить. Або якийсь кейс є коли ні
Можливо, є якесь розширення, для спрощення цього процесу. Треба пошукати
UPD2: є така річ як git mergetool $f (після злиття файлу), але вона вперто переконана, що "No files need merging". Наявність маркування конфлікту (<<<<<<< ======= >>>>>>>) це не аргумент для неї
Отже має сенс дописати мою інструкцію ) На жаль, це сьогодні (та й завтра) навряд чи встигну, тож дуже стисла версія:
- Загалом дуже рекомендую додати
[merge]
conflictstyle = diff3
До ~/.gitconfig (наприклад, чемненько командою git config --global merge.conflictstyle diff3)
- Я активний користувач Vim та GNU/Linux, тож у мене просто були макроси на те, щоб взяти стару англійську версію, записати її до /tmp/english-old, нову - до /tmp/english-new та замінити нижню частину на результат
git diff --word-diff /tmp/english-old /tmp/english-new). Що ти не у Vim я зрозумів, напиши, чи хоча б під GNU/Linux?.. В принципі я можу просто в окремій гілці підготувати усі ці файли, щоб вони були в стані з word-diff, якщо так зручніше, тоді не морочитиму тобі голову різними командами, просто в тій гілці опрацьовуватимеш файли.
Цей макрос я застосовував на кожному конфлікті, якщо бачив, що ліпше word-diff. Підсвітку для word-diff мені теж довелося писати самому, я навіть не знайшов готової.
- Ааа, зрозумів, налаштував, дякую )
- О, я був близький до цього. Змушував ШІ згенерувати мені скрипт, який би брав файл з конфліктом і перетворював нижні частини конфліктів у word-diff вигляд. Легше було б підставляти word-diff який зробив git, а не вигадувати щось "самому"
Vim колись намагався опанувати. Особливо після того, як в чергове шукав, як його закрити 😅
Загалом я знайшов робочий варіант для себе:
- спочатку створюю з
git showтимчасові файли - тоді викликаю
phpstorm mergeз консолі і це відкриває GUI для злиття, а не просто додає символи конфлікту у файл - ну і вилучаю тимчасові файли
Так що не треба окремо готувати ці файли, дякую )
друзі, мейнтейнером я також бути не зможу, але якимись кусочками допомагати готовий
@zmiimz, я зробив перші 3 файли і далі поки не робив.
book/01-introduction/sections/about-version-control.asc book/01-introduction/sections/command-line.asc book/01-introduction/sections/first-time-setup.asc
Зробив скрипт, який сам знаходить наступний файл без +, ставить його, робить злиття файлів, а тоді підставляє word-diff замість англійської версії. Можу викласти, як ґіст, якщо цікавить
То можемо додатково тут "замовляти" файли, або таки треба щоб @hedrok створив проєкт чи щось подібне для синхронізації роботи
Між іншим, щойно подумав Я робив скрипт для того всього, знаходив як у PHPStorm ініціювати GUI для вирішення конфлікту поза злиттям... Можна ж зробити звичайне злиття, а тоді відхилити зміни в усіх файлах крім одного потрібного. Тоді Git знаходиться в стані злиття, а отже буде доступний mergetool
Але я не розумію, як при звичайному злитті (, а не коли ми явно вказуємо ці версії) 2.1.434 у origin/master за основу береться origin/english-version. Треба буде дослідити це питання )
Треба щось для синхронізації - пишіть. Ми перекладали втрьох оригінально, робили по задачі на кожен файл, здається... Чи розділ?.. В принципі було весело ці задачі закривати, але по факту, як на мене, файлу плану й домовитися просто хто який розділ бере цілком достатньо.
Щодо бази для злиття: усе дуже просто: при початку роботи я позначив гілкою english-version той коміт оригіналу, на якому ми базувалися. Подільші коміти йшли поверху нього. Мені здається кілька разів я навіть оновлював переклад, коли змін ще було мало й це було просто, коли ще не закинув проєкт )
Зараз коли все опрацюємо ми теж зробимо git merge 2.1.434, успішно завершимо це злиття, і зробимо
git checkout english-version
git merge --ff-only 2.1.4343
git push
І наступного разу, коли ми захочемо зливати нові зміни, у нас знову базою для злиття буде english-version (цього разу 2.1.4343). А щоб подивитися який коміт є базою злиття є команда
git merge-base english/main HEAD
Яка видала мені e17ba13a690c00878d4c2d92bb7125f9360877c4, що є новішим комітом за english-version :'(
Тут уся моя красива теорія посипалася... Бо він новіший аж на 3 роки.
Я перевірив, зміни справді враховані, і ось коміт оновлення:
* commit b567a36344f40485651e94109460a50f43bf6650
|\ Merge: 01f9b354 e17ba13a
| | Author: Kyrylo Yatsenko <[email protected]>
| | Date: Wed May 2 17:26:35 2018 +0300
| |
| | Оновлення перекладу до версії update-translation-2018-03-16
Оновив english-version до 2.1.44, далі усе має працювати як треба, дуже-дуже добре, що ти спитав, інакше б заново додавали й опрацьовували зміни за 3 роки + дивувалися, що частина вже ніби врахована...
Якщо по розділам, то я тоді буду завершувати перший ))
Дякую, за відповідь. Інформативно
Мені вже щось попадалося, що виглядало як переклад чогось середнього між english-version та 2.1.434.
Я почитав ваші обговорення і подивився відкритий ПР від @burlakvo, дуже корисно 👍 . Cьогодні надішлю ПР, резервуючи 2-ий розділ під себе.
PS Єдине, я не дуже зрозумів чи ми плануємо відкривати ПР з оновленими перекладами в master — чи будемо робити аля реліз-трейн, накопичуючи наші з @burlakvo зміни, довго-довго, в одній гілці?
Адже на пуш в master, мабуть, відбувається деплой на прод і оновлена книга стає доступною публічно (де частина книги перекладена відносно 2.1.434 а все інше — 8-ми річної давності, аж поки не перекладуть і і решту), так?
cc @hedrok
Так, виходить частково за старою версією, частково за новою. Але поки принаймні я не бачив жодних кардинальних змін, радше невеличкі зміни, тож не бачу з цим проблем.
Я цілком за такі оновлення плану, не те щоб я швидко ревʼювлю, але протягом кількох днів точно заллю. Ну і перед тим, як брати новий розділ можна подивитися, чи є відкриті PR, що починають з "Беру розділ X".
ping мені надсилати сенсу не бачу, ну хіба днів за 7... Точно не за 1-2 дні, я вважаю це нормальним часом для ревʼю.
Мені не проблема просити обом develop'ера, просто варто спершу домовитися як вирішуватимуться конфліктні ситуації (https://гпімр.укр/комікси/hadano-1.jpg https://гпімр.укр/комікси/hadano-2.jpg - то базується на реальній довгій суперечці). Бо мені щастило, і що тут, що в іншому великому проєкті було 3 основні людини, відповідно, можна було голосуванням вирішити. Коли дві - складно... Наприклад, можна домовитися, що коли ви не можете домовитися, то вже пінґаєте мене і мій третій голос - вирішальний.
ping мені надсилати сенсу не бачу, ну хіба днів за 7... Точно не за 1-2 дні, я вважаю це нормальним часом для ревʼю.
Почув.
Мені не проблема просити обом develop'ера, просто варто спершу домовитися як вирішуватимуться конфліктні ситуації
Для таких речей у проєкті мають бути прописаний документ Ways of working, який і мав би роз'яснювати як вирішуються такі питання без зайвих суперечок чи навіть образ. Також там можуть бути прописані якою мовою оформлюють запити на злиття, підписують коміти, ведуть комунікацію і таке інше.
Можу спробувати накидати чернетку, яку потім разом зможемо узгодити. Стосовно прав розробника в цьому проєкті — я б таки попросив мене додати. @burlakvo що скажеш?
@dev99problems так, накидай чернетку, будь ласка. Ще, будь ласка, зроби PR, в якому ти виправляєш словник на такий, який тобі подобається ("мітка" -> "теґ" тощо). Що раніше узгодимо, то ліпше.
@dev99problems так, накидай чернетку, будь ласка. Ще, будь ласка, зроби PR, в якому ти виправляєш словник на такий, який тобі подобається ("мітка" -> "теґ" тощо). Що раніше узгодимо, то ліпше.
Не думав, що така опція взагалі можлива, тому приємно здивований 🙂 Так, накидаю обидві чернетки до понеділка