Пошук мейнтейнера

[hedrok]

На превеликий жаль часу на проєкт у мене немає.

В моїх великих планах лишалося все перечитати, узгодити (хоч більшість розділів перекладена мною, але зовсім не всі, узгодження не було), перекласти зображення тощо.
Але головна перепона зараз у тому, що в оригіналі були зміни генерації і українська версія зараз взагалі не генерується.
Ну і взагалі в оригіналі багато змін.
Я пробував почати прямо merge з оригіналу, але не здолав.

Якщо хтось має бажання взятися й

1. Оновити відповідно до оригіналу, зокрема, щоб почало генеруватися.
2. Перечитати все й повиправляти помилки й узгодити терміни.
3. Перекласти зображення.

Чи хоча б тільки 1й пункт, я можу дати такій людині права запису до репозиторія, допоможу чим можу, але часу в мене мало.

Можливо, @burlakvo @zmiimz

[burlakvo]

@hedrok, спробую погратися із 1м пунктом. Спробую завтра і тоді відпишу про результати

[burlakvo]

Щодо п. 1 є прогрес. Книга генерується. Створив чорнетку Запиту на злиття #206

Чорнетку, бо там вилазять попередження про неправильні якорі. Це не заважає генеруванню, проте це впливає на вигляд. Я ще не розібрався що із ними не так

[hedrok]

Класно, що хтось щось робить - дякую :)

Схвалив запуск перевірок на твоєму PR: #206
На жаль, зараз виявив, що я не мейнтейнер цього сховища :) Тож щоб тобі дати права девелопера треба кликати мейнтейнерів оригіналу. Мені достатньо, щоб ти просто підтвердив свою готовність приділяти цьому час - покличу.
Поки можу просто заливати що скажеш і коли скажеш (з мінімальним ревʼю).

[Мовна хвилинка: "чЕрнетка", а не "чОрнетка"]

[burlakvo]

По-перше, дякую за мовну хвилинку )

Там все впало, бо не були оновлені робочі процеси. Оновив, запустив у своєму відсадку - [тут я відволікся і ти вже в PR відписав] працює, хоч і з помилками

[hedrok]

@burlakvo Вітаю й дуже дякую: книжка знову генерується й сайт оновлюється!

[hedrok]

@burlakvo я залив #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, але найгірше, що якщо не завершиш, то теж буде просто змарнований час.

[burlakvo]

Я стягнув з англійського репозиторію майстер гілку і звіряв із нею. Обирав два файли у VS Code і порівнював. Воно виділяє відмінності

Я планував порівняти які файли є, яких нема. А тоді по файлу порівнювати. І так поступово оновлювати сторінки
Але так, відстеження версії потрібне. Цього не враховував

word-diff виглядає як магія якась :)
Вирішив з цікавості просто злити і найлегше було видалити видалені файли. Тоді збагнув, що окрім різниці форматування треба ж одразу і переклад вичитувати, а місцями і робити. Звісно, можна спробувати, але це скоріше затягнеться і вийде, що одна людина перекладатиме всі зміни (скоріше за все, так і буде, але якщо є варіант віддавати у світ це шматочками, а не все одним шматом через хто зна скільки часу)

Можна клонувати нашу майстер гілку і злити в неї англійську, але із мінімальними правками (форматування, посилання, що не потребує перекладу). А тоді вже виправляти і висмикувати до майстра опрацьовані сторінки.
Я до того, що, можливо, зробити word-diff, як ти кажеш, і надіслати це сюди окремою гілкою, аби не тільки локально це було. Може ще хто захоче доєднатися, а підґрунтя вже готове ))

Тож чекаю на твій план :)
Давай це зробимо

А поки ще трохи понаступаю на твої граблі із тим злиттям ))

[hedrok]

Та зробімо правильно, я все підготую. Нащо на граблі наступати.
Підготую файли діфів, план тощо. Потихеньку виправлятимеш, я потихеньку ревʼюватиму.

[burlakvo]

У мене на вирішення конфліктів в 1 файлі пішло близько 35 хвилин. Ще 97 файлів (UPD: і купка файлів без конфліктів)

Я це роблю в IDE із графічним інтерфейсом для вирішення конфліктів. Я бачу файл в 3 колонках: як зараз, що буде, зовнішні зміни. Помітив, що IDE мені показує і word-diff. Є певні нюанси, але "жити можна"

Якщо цим поки тільки я буду займатися, то я, напевне, можу і без файлів діфів. Зливаю англійську версію, вирішую конфлікти у запланованих файлах, зберігаю ці файли на поличку, скасовую злиття, витягаю файли з полички, коміт, запит на злиття, повторюємо

[hedrok]

Ок, роби, як тобі зручно.
Я додав план оновлення, коли оновлюєш файл, став +, будь ласка, тут: 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 - там у коментарях початок того, як я планував це пропонувати ) Може тобі зручніше буде все ж таким чином відтворювати стан конфлікту у файлі.

[burlakvo]

Як варіант, можна зробити проєкт на GitHub, аби відслідковувати поточний статус (наприклад, ось так)

Але це на випадок, якщо виправляти буде 2+ людини, аби можна було зарезервувати якусь частину роботи за собою, і не почати виправляти одне й те саме

[burlakvo]

Ознайомився із твоїм методом

Зручно, що маю тільки один змінений файл і 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". Наявність маркування конфлікту (<<<<<<< ======= >>>>>>>) це не аргумент для неї

[hedrok]

Отже має сенс дописати мою інструкцію )
На жаль, це сьогодні (та й завтра) навряд чи встигну, тож дуже стисла версія:

1. Загалом дуже рекомендую додати

[merge]
	conflictstyle = diff3

До ~/.gitconfig (наприклад, чемненько командою git config --global merge.conflictstyle diff3)

2. Я активний користувач 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 мені теж довелося писати самому, я навіть не знайшов готової.

[burlakvo]

1. Ааа, зрозумів, налаштував, дякую )
2. О, я був близький до цього. Змушував ШІ згенерувати мені скрипт, який би брав файл з конфліктом і перетворював нижні частини конфліктів у word-diff вигляд. Легше було б підставляти word-diff який зробив git, а не вигадувати щось "самому"

Vim колись намагався опанувати. Особливо після того, як в чергове шукав, як його закрити 😅

Загалом я знайшов робочий варіант для себе:

• спочатку створюю з git show тимчасові файли
• тоді викликаю phpstorm merge з консолі і це відкриває GUI для злиття, а не просто додає символи конфлікту у файл
• ну і вилучаю тимчасові файли

Так що не треба окремо готувати ці файли, дякую )

[zmiimz]

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

[burlakvo]

@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 створив проєкт чи щось подібне для синхронізації роботи

[burlakvo]

Між іншим, щойно подумав
Я робив скрипт для того всього, знаходив як у PHPStorm ініціювати GUI для вирішення конфлікту поза злиттям... Можна ж зробити звичайне злиття, а тоді відхилити зміни в усіх файлах крім одного потрібного. Тоді Git знаходиться в стані злиття, а отже буде доступний mergetool

Але я не розумію, як при звичайному злитті (, а не коли ми явно вказуємо ці версії) 2.1.434 у origin/master за основу береться origin/english-version. Треба буде дослідити це питання )

[hedrok]

Треба щось для синхронізації - пишіть. Ми перекладали втрьох оригінально, робили по задачі на кожен файл, здається... Чи розділ?.. В принципі було весело ці задачі закривати, але по факту, як на мене, файлу плану й домовитися просто хто який розділ бере цілком достатньо.

Щодо бази для злиття: усе дуже просто: при початку роботи я позначив гілкою 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 роки + дивувалися, що частина вже ніби врахована...

[burlakvo]

Якщо по розділам, то я тоді буду завершувати перший ))

Дякую, за відповідь. Інформативно
Мені вже щось попадалося, що виглядало як переклад чогось середнього між english-version та 2.1.434.