Меню
Что нового?

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

  • Автор темы Автор темы AmdY
  • Дата начала Дата начала
AmdY

AmdY

Пью пиво
Команда форума
fixxxer написал(а):
как думаешь, может стоит для начала привести оформление сорцов в порядок, в соответствии с кодинг-стандартами php? Там щас какой-то бардак, половина пробелами, половина табами, уродский ts=2 без которого вообще все едет и пр. Бесит =)
Нажмите для раскрытия...
О, кстати, вопрос, как быть, если старый код уже на VCS, а с форматированием бордак. Просто взять и поменять форматирование во всём проекте ЦЕЛИКОМ незя, даже в файлике который правишь тоже, потому что потом потеряешь историю.


p.s. Перенёс из http://phpclub.ru/talk/threads/Кэшеры-байткода.71550/page-2#post-640324
 
а почему теряется история при форматировании файла? что это за vcs?
 
не потеряется история.
просто blame будет показывать на коммит, который поменял форматирование, что довольно бессмысленно.
 
grigori
vcs - система контроля версий. в моём случае это git
а проблемы несколько
- сдвиг строк, особенно когда разный расстановки {
- потеря авторства
- если несколько веток проекта, то проблемы с pull request-ами и патчами, который нужно метать от нового кода к старому.
и т.д.


tony2001 написал(а):
хотя, вот тут подсказывают, что есть `git blame -w`.
Нажмите для раскрытия...
это только пробелы лечит, есть ещё переносы строк.
 
Дисциплина не поможет?
Автор проекта должен скомандовать всем соавторам - "быстро скинули все комиты". После чего отформатировать распространенным автоформатом все сорцы и "забирайте сорцы и больше не грешите", не?
 
ksnk
в том то и дело, что нельзя, о чём и писал выше
 
я так понимаю, что рыть в сторону git filter-branch + git rebase
 
AmdY написал(а):
- сдвиг строк, особенно когда разный расстановки {
- потеря авторства
- если несколько веток проекта, то проблемы с pull request-ами и патчами, который нужно метать от нового кода к старому.
это только пробелы лечит, есть ещё переносы строк.
Нажмите для раскрытия...
че-то я не понимаю
1. хистори таки не теряется.
2. т.к. проект был заброшен, указатель последнего изменения в git неважно, автора все-равно не спросить
3. нормальные IDE и программы удобно показывают историю любого файла, и потеря blame особой проблемы не представляет,
4. ветки - да, пусть народ в своих ветках смерджится, с пробелами проблем не возникает.
а когда вам надо дописать служебные классы, вы же не боитесь, что всем надо будет смерджиться?
 
>1. хистори таки не теряется.
не теряется, но перезаписывается сверху.

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

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

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

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

когда вам надо дописать служебные классы, вы же не боитесь, что всем надо будет смерджиться?
Нажмите для раскрытия...
Это отдельная беда. У нас очень большие ограничения по изменениям в ядре, связанные как с обратной совместимостью так и с видением архитектуры.
 
AmdY написал(а):
grigori
Соответственно, когда нужно что-то делать с сомнительным кодом, то смотришь зачем и кто его туда засунул. Любые глобальные изменения по форматированию превратят историю в непонятную кашу, новые изменения будут так же привязаны к новому положению строк в проекте и в старые ветки их будет ацки трудно вмерживать.

Мы сейчас форматируем только тот код, который пишем сами, чтобы мерж затрагивал минимальное количество строк, отосящихся лишь к заданию. Выглядит всё просто ужасно, как белый лебедь в стае утят, но иначе получаем хаус. Вот такая дилемма.
Нажмите для раскрытия...
может просто стоит не париться ?! ;) я уже представляю войну коммитов с затиранием неугодных пробелов и табов :) вообще зачем тебе понадобилось менять текущий стиль кода, если я правильно понимаю твои слова про "лебедя" - то ты посчитал то, что текущий стиль УГ и решил привнести свой?!
 
я бы пожалуй действовал так.
1. Обозначил для всех кодинг стандарт.
2. Очень убедительно попросил бы приводить к этому стандарту те файлы которые правятся после выполнения п.1

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