Как быть, если старый код уже на VCS, а с форматированием бордак?

[AmdY]

как думаешь, может стоит для начала привести оформление сорцов в порядок, в соответствии с кодинг-стандартами php? Там щас какой-то бардак, половина пробелами, половина табами, уродский ts=2 без которого вообще все едет и пр. Бесит =)

О, кстати, вопрос, как быть, если старый код уже на VCS, а с форматированием бордак. Просто взять и поменять форматирование во всём проекте ЦЕЛИКОМ незя, даже в файлике который правишь тоже, потому что потом потеряешь историю.


p.s. Перенёс из http://phpclub.ru/talk/threads/Кэшеры-байткода.71550/page-2#post-640324

 

[grigori]

а почему теряется история при форматировании файла? что это за vcs?

 

[tony2001]

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

 

[tony2001]

хотя, вот тут подсказывают, что есть `git blame -w`.

 

[AmdY]

grigori
vcs - система контроля версий. в моём случае это git
а проблемы несколько
- сдвиг строк, особенно когда разный расстановки {
- потеря авторства
- если несколько веток проекта, то проблемы с pull request-ами и патчами, который нужно метать от нового кода к старому.
и т.д.

хотя, вот тут подсказывают, что есть `git blame -w`.

это только пробелы лечит, есть ещё переносы строк.

 

[ksnk]

Дисциплина не поможет?
Автор проекта должен скомандовать всем соавторам - "быстро скинули все комиты". После чего отформатировать распространенным автоформатом все сорцы и "забирайте сорцы и больше не грешите", не?

 

[AmdY]

ksnk
в том то и дело, что нельзя, о чём и писал выше

 

[fixxxer]

я так понимаю, что рыть в сторону git filter-branch + git rebase

 

[grigori]

- сдвиг строк, особенно когда разный расстановки {
- потеря авторства
- если несколько веток проекта, то проблемы с pull request-ами и патчами, который нужно метать от нового кода к старому.
это только пробелы лечит, есть ещё переносы строк.

че-то я не понимаю
1. хистори таки не теряется.
2. т.к. проект был заброшен, указатель последнего изменения в git неважно, автора все-равно не спросить
3. нормальные IDE и программы удобно показывают историю любого файла, и потеря blame особой проблемы не представляет,
4. ветки - да, пусть народ в своих ветках смерджится, с пробелами проблем не возникает.
а когда вам надо дописать служебные классы, вы же не боитесь, что всем надо будет смерджиться?

 

[tony2001]

>1. хистори таки не теряется.
не теряется, но перезаписывается сверху.

>2. т.к. проект был заброшен, указатель последнего изменения в git неважно, автора все-равно не спросить
мы не говорим про какой-то конкретный проект сейчас.
кроме того, у AndY вряд ли что-то там заброшено.

>3. нормальные IDE и программы удобно показывают историю любого файла, и потеря blame особой проблемы не представляет,
ээ?..
я это оставлю без комментария пока.

>4. ветки - да, пусть народ в своих ветках смерджится, с пробелами проблем не возникает.
>а когда вам надо дописать служебные классы, вы же не боитесь, что всем надо будет смерджиться?
шито?

 

[AmdY]

grigori
в том то и дело, что проект не заброшен, а активно развивается очень-очень большой распределённой командой. Соответственно у нас каждый коммит-бранч привязан к таску-дефекту. Так как проект имеет несколько веток и при этом update safe, то изменения мержатся сразу в несколько основных бранчей из которых собирается ядро, которым пользуются клиенты.
Соответственно, когда нужно что-то делать с сомнительным кодом, то смотришь зачем и кто его туда засунул. Любые глобальные изменения по форматированию превратят историю в непонятную кашу, новые изменения будут так же привязаны к новому положению строк в проекте и в старые ветки их будет ацки трудно вмерживать.

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

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

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

 

[grigori]

дык вот ты сам и ответил

 

[DYPA]

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

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

может просто стоит не париться ?! я уже представляю войну коммитов с затиранием неугодных пробелов и табов вообще зачем тебе понадобилось менять текущий стиль кода, если я правильно понимаю твои слова про "лебедя" - то ты посчитал то, что текущий стиль УГ и решил привнести свой?!

 

[Mols]

я бы пожалуй действовал так.
1. Обозначил для всех кодинг стандарт.
2. Очень убедительно попросил бы приводить к этому стандарту те файлы которые правятся после выполнения п.1

Так вы более менее плавно и спокойно придёте к общему знаменателю. (будете приводить к общему стандарту изменяемые файлы)
А если вы что-то не правите годами, то наверное можно забить на эти файлы))
Кодинг стандарты важны для людей, а не для интерпретатора.

 

[magic]

2. Очень убедительно попросил бы приводить к этому стандарту те файлы которые правятся

Можно сделать принудительно через git pre-receive hook и phpcs. Файлы, не приведенные к стандарту, просто не попадут в git.