Кстати, читал где нибудь гипотезу, что длина жизни такая что можно было родить и вырастить детей. И поэтому позднее рождение детей приводит к удлинения жизни. И что в развитых странах, люди живут долго потому что рожают поздно. Жизнь, конечно удлиняется с замедлением в нескольких поколении.
Гипотеза интересная, но время прошло слишком мало, чтобы накопить статистику. Не знаю делал ли кто-нибудь опиты на мышах...
Ну, для меня программирование, это вид творчество. И поэтому я делаю коммит, тогда когда мне кажется, что время его сделать. Иногда, коммичу каждую строку, когда мне кажется что так надо. Иногда делаю бранч, потом мержу его. И вообще, как правило, у меня всегда активны по крайней мере 4..5 ветки разработки.
Вообще, "я художник, я так вижу". :D
Но предмет искусства, здесь именно программа. А история, это лог работы, который потом помогает разобраться и анализировать как я работал и как эту работу можно улучшить в будущем. Именно поэтому для меня точность и непричесанность истории очень важна.
Ну поиск есть. И еще там есть инструменты с которыми можно следить и работать над множество проектов, единым образом. Комментировать, рапортовать баги, делать пул-реквесты. Есть рейтинги и звездочки/лайки. Много чего есть. Но все это работает только если проект хостится на github.
Хотя (на первый взгляд) ничего не мешает сделать хаб с АПИ такое, чтобы можно было объединять репозитории которые хостятся независимо в другом месте. Конечно это намного сложнее, но все-таки....
Некоторые комментаторы наверх предлагали хостить такие проекты на отдельном сервере. Указывая, что услуги хостинга сейчас очень дешевы.
Но дело совсем не в деньгах. На github (а он в настоящем именно что монополист!) о проектах узнают очень большое количество людей. Тот же самый проект, как бы он не был интересным, и технически совершенным, если хостится где нибудь в другом месте, остался бы в полной неизвестности.
Тоесть «Hub» в гитхаб намного и намного важнее, чем «Git».
Именно ее и монополизировали М$, а совсем не бесплатный хостинг.
С одной стороной, людям удобно чтобы все было сконцентрировано в одном месте. С другой, GitHub могут делать все что им захочется и ничего им за этого не будет.
Здесь разницы в количеству информации небольшое (буквально сотни байтов) и не имеет значение для обработки.
Проблема в том, что при слияния коммитов и редактирования истории теряется класс информации. Например информации об ошибках. Или то насколько часто делались коммиты, в какое время сутки. И как на самом деле происходила разработка.
Если вам все это неинтересно, то все это можно отфильтровать используя подходящие инструменты на этапе анализа. Но ведь, кому нибудь в будущем вся эта информация возможно будет интересна?
Или вы думаете: "Раз мне это не интересно, значит никому никогда не будет интересно."
Под оврагами я подразумеваю когда что-то пошло не так. Например когда кто-то торопился и поэтому пропустил строчку в логе. Мало ли что интересного можно увидеть, если не редактировать историю?
Мне это интересно. Мне вообще интересно иногда поизучать ошибки других, чтобы сам их не допускать.
И вот пришел я в вашем проекте, начал рассматривать историю, а ошибок то и нет. Все причесано, все красиво, все безгрешны.
И в результате, получу я депрессию и синдром самозванца в придачу – ведь все безгрешны и только я все время делаю ошибки в коммитах. :P :P :P
Так у вас сейчас будущее по отношению к ситуации в прошлом.
Это конечно так. Только дело в том, что моя VCS всегда пишет история так как она случилась. Поэтому я всегда нахожу то что мне нужно. Пусть скажем, коммиты -А-Б-В-. И мне пришлось возвратится к коммиту Б. Так, вот, если кто нибудь слил бы его в прошлом например так: -АБ-В-, -А-БВ- или даже -АБВ-, то мне это не понравилось бы, потому что мне понадобился именно Б. Но это потому что у меня история непереписанная. А если у кого нибудь переписанная, то он даже и не задумался бы, не лучше ли было-бы если вот этот коммит был-бы менее объемистом.
В будущем, история всегда воспринимается так, как задокументирована. И история не знает сослагательное наклонение. Так что лучшее что можно вообще сделать с этим – писать то что случилось и не писать то, что не случилось.
Это упрощение работы программиста при анализе кода.
Система контроля версии, кроме записи истории, предназначена и для проведения анализа этой истории. Если инструменты VCS недостаточно продвинутые, то да упрощение истории упрощает работы программиста вручную анализировать историю. А вообще-то, анализ должен быть автоматическим и тогда гранулярность истории значения не имеет.
Почему тогда не делать коммиты по одной строке?
А что такое? Иногда именно так и делается. Когда логика изменения таковая.
Если это дефиниция велосипеда, то все СКВ – велосипеды, так как все они созданы потому что кого нибудь не устраивали существующие.
Ну, только SCCS не велосипед.
Кстати, читал где нибудь гипотезу, что длина жизни такая что можно было родить и вырастить детей. И поэтому позднее рождение детей приводит к удлинения жизни. И что в развитых странах, люди живут долго потому что рожают поздно. Жизнь, конечно удлиняется с замедлением в нескольких поколении.
Гипотеза интересная, но время прошло слишком мало, чтобы накопить статистику. Не знаю делал ли кто-нибудь опиты на мышах...
Ну вообще-то, бессмертие и неуязвимость это совершенно разные вещи.
Хм, а причем здесь серверы? Нельзя ли сделать просто долгосрочный кеш на стороне клиента? И сбрасывать его если произошла ошибка соединения.
Или я фундаментально не понимаю что нибудь?
Насколько я понял, частично отключается иммунитет. Но это неточно.
Поздно метаться, вокзал ушел. :D
Ну, для меня программирование, это вид творчество. И поэтому я делаю коммит, тогда когда мне кажется, что время его сделать. Иногда, коммичу каждую строку, когда мне кажется что так надо. Иногда делаю бранч, потом мержу его. И вообще, как правило, у меня всегда активны по крайней мере 4..5 ветки разработки.
Вообще, "я художник, я так вижу". :D
Но предмет искусства, здесь именно программа. А история, это лог работы, который потом помогает разобраться и анализировать как я работал и как эту работу можно улучшить в будущем. Именно поэтому для меня точность и непричесанность истории очень важна.
История разработки, это не документация! Это лог событии. И как каждый лог, она должна быть предельно точной.
А документацию можно и нужно синтезировать обрабатывая этого лога. Можно даже и в реальном времени.
Ну поиск есть. И еще там есть инструменты с которыми можно следить и работать над множество проектов, единым образом. Комментировать, рапортовать баги, делать пул-реквесты. Есть рейтинги и звездочки/лайки. Много чего есть. Но все это работает только если проект хостится на github.
Хотя (на первый взгляд) ничего не мешает сделать хаб с АПИ такое, чтобы можно было объединять репозитории которые хостятся независимо в другом месте. Конечно это намного сложнее, но все-таки....
Некоторые комментаторы наверх предлагали хостить такие проекты на отдельном сервере. Указывая, что услуги хостинга сейчас очень дешевы.
Но дело совсем не в деньгах. На github (а он в настоящем именно что монополист!) о проектах узнают очень большое количество людей. Тот же самый проект, как бы он не был интересным, и технически совершенным, если хостится где нибудь в другом месте, остался бы в полной неизвестности.
Тоесть «Hub» в гитхаб намного и намного важнее, чем «Git».
Именно ее и монополизировали М$, а совсем не бесплатный хостинг.
С одной стороной, людям удобно чтобы все было сконцентрировано в одном месте. С другой, GitHub могут делать все что им захочется и ничего им за этого не будет.
Здесь разницы в количеству информации небольшое (буквально сотни байтов) и не имеет значение для обработки.
Проблема в том, что при слияния коммитов и редактирования истории теряется класс информации. Например информации об ошибках. Или то насколько часто делались коммиты, в какое время сутки. И как на самом деле происходила разработка.
Если вам все это неинтересно, то все это можно отфильтровать используя подходящие инструменты на этапе анализа. Но ведь, кому нибудь в будущем вся эта информация возможно будет интересна?
Или вы думаете: "Раз мне это не интересно, значит никому никогда не будет интересно."
Вопрос неправильно задаете. А чем вам навредит, если 500?
Может навредит лишь отсутствие информации. Больше информации навредит не может в принципе.
А очевидно, 1 коммит несет меньше информации, чем 500 коммитов.
Инструменты исследования истории должны быть такие, чтобы в историю было легко ориентироваться.
А иначе история получается:
Иногда искушаюсь. Но вот, не судьба – fossil редактировать историю не дает. :D
Под оврагами я подразумеваю когда что-то пошло не так. Например когда кто-то торопился и поэтому пропустил строчку в логе. Мало ли что интересного можно увидеть, если не редактировать историю?
Мне это интересно. Мне вообще интересно иногда поизучать ошибки других, чтобы сам их не допускать.
И вот пришел я в вашем проекте, начал рассматривать историю, а ошибок то и нет. Все причесано, все красиво, все безгрешны.
И в результате, получу я депрессию и синдром самозванца в придачу – ведь все безгрешны и только я все время делаю ошибки в коммитах. :P :P :P
Конечно, но путь по котором был достигнут этот результат, весьма важен.
А вы утверждаете, можно просто соединить точки прямыми и все будет в порядке. Путь гладок и прямолинеен.
А то что овраги потерялись – кому нужны эти овраги? Так?
То-есть:
:D :D :D
Это конечно так. Только дело в том, что моя VCS всегда пишет история так как она случилась. Поэтому я всегда нахожу то что мне нужно. Пусть скажем, коммиты -А-Б-В-. И мне пришлось возвратится к коммиту Б. Так, вот, если кто нибудь слил бы его в прошлом например так: -АБ-В-, -А-БВ- или даже -АБВ-, то мне это не понравилось бы, потому что мне понадобился именно Б. Но это потому что у меня история непереписанная. А если у кого нибудь переписанная, то он даже и не задумался бы, не лучше ли было-бы если вот этот коммит был-бы менее объемистом.
В будущем, история всегда воспринимается так, как задокументирована. И история не знает сослагательное наклонение. Так что лучшее что можно вообще сделать с этим – писать то что случилось и не писать то, что не случилось.
Система контроля версии, кроме записи истории, предназначена и для проведения анализа этой истории. Если инструменты VCS недостаточно продвинутые, то да упрощение истории упрощает работы программиста вручную анализировать историю. А вообще-то, анализ должен быть автоматическим и тогда гранулярность истории значения не имеет.
А что такое? Иногда именно так и делается. Когда логика изменения таковая.
И как по вашему дать пример, который относится к будущем??? Я не знаю понадобится ли мне чтобы были два коммита наместо один.
И так как не знаю, то лучше чтобы были два. Потому что сделать из двух один проще-простого. А сделать два из одного, принципиально невозможно.
Пусть история документируется так, как произошла, а не так как субъективно больше кому-то нравится.
А я говорил, что историю трогать нельзя, как бы хороша эта идея не казалась нам сегодня.
Потому что история, это на завтра, а не на сегодня.