Ядрото има зрял, строг и добре дефиниран процес на развитие [1]. Нещата, които не се вписват добре в този модел, просто няма да бъдат успешни, дори ако работят добре в друг контекст.

торвалдс

Ако вашите разработчици извършват лош код, вероятно е доста лесно да ги намерите и евентуално да ги задействате. Ако не можете да разберете от кого е корекцията на ядрото или дори ако действително е от посочения човек, това поставя под въпрос сигурността на ядрото.

Освен това пластирът е дефицитен и по други начини. (а) липсваше заглавката Signed-off-by: и (b) трябваше да бъде изпратено до пощенския списък linux-bluetooth или до някой от поддържащите Bluetooth, като имейл списъкът linux-bluetooth бе поставен в копка.

Ти си малоумник. ", Който хората смятаха за вежлив. Коментарът, на който той отговори, изглежда е изтрит, така че не мога да преценя колко подходящо беше това. Бих искал да мисля, че е напълно подходящ - аз съгласен съм с вас като цяло, че другите му коментари са били разумно вежливи.

Отбелязвам, че GitHub всъщност е направил запис в блог преди време за добра практика на коммитиране и изглежда е същото като това, което изисква Torvald's. Не съм сигурен, че разбирам какъв е въпросът. https://github.com/blog/926-shiny-new-commit-styles

Отново, това е Linux. И въпросът беше за това какво/дали/как трябва да приема ангажименти в torvalds/linux на GitHub. Всеки може да се ангажира навсякъде и да разклонява Linux или да прави персонализирани компилации, дистрибуции и т.н. Но ако има едно място, той има абсолютното право да бъде тиран е над torvalds/linux. Фактът, че той също така е проектирал и стартирал git за цялата цел да контролира версиите The Right Way, въз основа на неговите нужди от разработка на Linux, е просто череша на този аргумент. Но той не беше учтив.

pirtlj "Не разбрах, че лайна на Линус не смърди." torvalds "ти си идиот"

Изглежда ми честно.

Дори и да не мога да кодирам като Линус, мога поне да се опитам да напиша съобщения за обвързване като неговите ...

Това каза, че не мисля, че това е достатъчно важно, за да се добави към убедителна причина.

По-добре тогава да се каже „поправки“, така че да се различава от употребата във фраза като императив. „Трябва да поправим това.“

Редактиране: за да бъдем малко по-ясни; вашият традиционен SCM има модел за писане веднъж, никога не променящ се за багажника на разработката. Това има проблем в ситуация на партньорска проверка и проблемът е следният: Мога да продължа с най-добрите намерения да разложа нещата на дискретни кръпки. Но когато стигнете до месинг, промените в системата обикновено се случват в даден ред - може да откриете скрита грешка при тестване на вашата функция, която няма нищо общо с вашата функция. Сега имате два избора: можете да изчакате и да не ангажирате нищо, докато всичко е чудесно, което означава, че не се интегрирате с основната линия, което означава, че интегрирането ще бъде изключително болезнено, което води до заключвания; или вие се ангажирате, както идва в момента, което е много по-добре за интеграция и много по-лесно е да се оттеглят частични промени и обикновено да се получат всички неархивни елементи на SCM, но което е много дяволът за партньорска проверка. С rebase -i е доста лесно да се извърши във втория стил в момента и след това ги почистете за партньорска проверка по-късно; това е способността да се ревизира историята означава, че можете да вземате решения веднага, без да се притеснявате, че те ще бъдат хвърлени в камък завинаги и винаги.

Не винаги съм бил толкова твърд по тази тема, но настоящата ми работа използва Perforce като основна SCM и осъзнах, че не съм съгласен с почти всяко решение, което Perforce взема общо. Все още го използвам, защото всеки SCM е много по-добър от никакъв SCM и не искам да обяснявам git на всички останали, но действителното ми развитие се случва с git-p4.

Проекти като Git и Linux приемат своя принос като кръпки, които се изпращат към пощенския списък на проектите. Тъй като по време на публикуването то не е обединено в основното дърво, няма смисъл да се използва минало време за описване на това, което трябва да се направи, ако е обединено.

Благодарение на страхотните функции за промяна на графиката на Git като пребазиране и бране на череши, това би имало още по-малко смисъл. Винаги можете да вземете някакъв ангажимент и да го приложите към нови клонове или дори хранилища.

Побърква ме, че никога не знам кога точно Github ще наруши моите едноредови описания, когато изглежда, че има достатъчно място за показване на героите. Като този от Линус:

Освен това е по-проста и насърчава по-малко объркани фрази.

Той е директен, кратък, последователен и има тенденция към активен глас, а не към пасивен глас. Освен това не всеки, който пише или чете съобщенията, ще бъде носител на английски език. Избягването на форми от минало време просто го улеснява.

"опишете промените в императивното настроение, напр." make xyzzy do frotz "вместо" [This patch] xyzzy do frotz "или" [I] промени xyzzy да направи frotz ", сякаш давате заповеди на кодовата база да промени поведение."

Линус не се колебае да критикува и винаги мисли за нещата, преди да ги обяви за готини.

О, той прави грешки като всички. Той обикновено не винаги е много добър в съобщенията (прочетете LKML и ще разберете). Но той обикновено е прав и обикновено не пише случайни неща, защото "е модерно".

Така че GitHub е модерен. Линус не се интересува. Линус се грижи за добрите черти и привличането не е един от тях в очите му. И тогава отново, мисля, че е прав. Издърпването на GitHub е глупаво.

Но това, което липсва в посланието му, е причина защо издърпването на GitHub е скапано. Сигурен съм, че знае, но използва половин дума. Ето причината:

Ако GitHub наложи правилно изтегляне на съобщения, ХОРАТА НЕ ЩЕ ИЗПОЛЗВАТ. Защо? Защото лекотата на разклоняване и дърпане прави GitHub успешен. Така че виждате ли, дърпанията трябва да бъдат МЪРТИ ЛЕСНО. И това означава също „едно текстово поле, без налагане на каквото и да било“.

Така че, да. GitHub няма да го поправи, защото това ще бъде лошо за техния бизнес.

С текущия работен поток на Linus (заявки за изтегляне по имейл), все още е напълно възможно да имаме ужасно структурирана заявка за изтегляне и затова те добавиха правила извън това, което технологията може да направи за това как трябва да се форматират заявките за изтегляне. Не успявам да разбера защо същите правила не могат да бъдат приложени към GitHub.

Линус измислено Git и е напълно възможно да има съобщения за ангажиране на един символ в Git. Не съм съвсем сигурен защо е неуспех на GitHub, че той използва също толкова свободен подход към това как се справя с исканията за изтегляне.

Не мисля така. Прочетете коментара на tomayko в оригиналната тема: GitHub потвърди проблема с исканията за изтегляне.

Дори и да сте били прави, GitHub може да добави начин проект да създаде свои собствени (принудени) правила.

Обичайте този безсмислен стил, но нека кажа, че това е не само стилът, но и че Линус има достатъчно на своя страна, за да го подкрепи.

Ние винаги се вслушваме в обратна връзка и работим за подобряване на преживяването за всички. Жалко е, че полезни битове отзиви като този се превръщат в друг драматичен епизод.

/ времева линия, която показва цялата активност (ангажименти, коментари, искания за изтегляне, проблеми и т.н.)

Бих взел версията на Github за която и да е функция, всеки ден, над официалната версия на git, всеки път, когато те се различават - Git е известна враждебна за потребителя част от софтуерния интерфейс и почти единственото нещо, което има за него фронтът за използваемост е Github.

Смешно е да го кажете, защото Git е единствената система за контрол на версиите, при която работата с клонове, разклонения и обединения в големи проекти е не само изпълнима, но в 90% от случаите безболезнена. Не можете наистина да оцените Git, докато не опитате да правите същите задачи в Perforce, SVN и CVS. Никой друг подобен софтуер няма същия безболезнен подход към разклоняване и обединяване, дори и други разпределени системи.

Освен това интерфейсът му е враждебен, тъй като изисква от потребителя да разбере малко за вътрешността му. Може да не сте съгласни, че това е добър дизайн, но ви дава безпрецедентен контрол над хранилището, от който имате нужда често, когато лайна удари вентилатора. Освен това Git е страшно бърз и ефективен. Подобно на C, интерфейс, направен с вкус, но това не се харесва на тези със слаби сърца. И фактът, че такива проекти като Linux се поддържат с Git, проекти, които имат огромен брой участници, е истинско свидетелство за страхотността на Git.

И между другото, като се има предвид как контролът на версиите е един от най-важните инструменти на ваше разположение, ако не и най-важният в големите отбори, спрете да четете тези уроци за SVN 2 Git и отидете да четете странно ръководство. Заслужава си, защото ще се учудите колко мощност има под предния капак.

Не съм съгласен с второто твърдение и първото не обяснява, че е така. Какво е толкова вкусно в това:

Не - може да е полезно, може да е бързо, може да е ефективно. Но интерфейсът е гадно напълно и е много несъвместим както между командите, така и в това, което е отговорност на всяка команда.

Това изтрива препратката към отдалечено хранилище. Разликата между Git и SVN тук е, че в Git можете да имате многократни отдалечени хранилища, с които можете да комуникирате.

Това е полезно, когато дърпате и бутате към/от множество хора. Представете си, че разменяте код между вас и вашите колеги, правите експерименти, правите прегледи на кодове и т.н. Той също така е полезен, когато се занимавате с Heroku или когато имате ядро ​​с отворен код, което е изпратено към GitHub и друг клон със собствени добавки, които натискате някъде другаде.

Също така, всички команди за управление на тези препратки към хранилището започват с "git remote" и за да разберете как да направите нещо с тях, просто правите "man git-remote".

Това изтрива локален клон. Няма нищо общо с горното. Той не използва "rm", защото това може да е името на клон и тази команда е силно претоварена.

Това изтрива маркер. Това е в съответствие с горната команда, тъй като "git клон -d" (малки букви D) също се поддържа, но главни букви D означава, че изтриването е принудително, дори ако клонът не е бил обединен. Отново "rm" не се използва, тъй като това може да се обърка с името на етикет.

Изтрива файл, но не е нужно да го използвате. Ако сте уверени в уменията си за редактиране, можете просто да извършите всички изтривания с "git commit -a.". git също ще бъде достатъчно умен, за да открие преименуване на файл, въпреки че сте направили изтриване + добавяне.

"rm" е също името на командата, която прави същото нещо в Unix, свързано с премахването на файлове.

Както казах, "git remote" управлява препратки към отдалечени хранилища. Това просто преименува препратката, наречена „стара“, на „нова“.

Може да се каже, че е трябвало да използват "mv", както в случая с "git mv", но това не е команда "move". Това е просто преименуване.

Това преименува местния клон с име "стар" на "нов". Наистина е в противоречие с останалите, но това е така, защото помощната програма "git branch" е претоварена много. Тази команда ме обърква от време на време.

Както в случая с "git rm", тази команда прави "mv", докато регистрира действието в Git. Също така не е необходимо, ако правите "git add. && git commit -a".

"mv" има смисъл тук, тъй като това е името на командата Unix за преместване на файлове.

И последен съвет за начинаещи: използвайте страниците „мъж“. В терминала въведете някоя от следните команди, когато имате нужда от помощ .

Идеята ми беше по-скоро за несъответствия, отколкото за невъзможност да разбера коя команда какво е направила.

Не съм сигурен дали са разрешени.

Вероятно е вярно, но когато сте променили технологичния свят два пъти преди 40-годишна възраст, хората са склонни да ви отрежат допълнително.

Тогава вероятно не сте използвали SCCS преди git. Тъй като CVS е още по-грозен, Bitkeeper е причината Линус да пише git и всеки друг опит, който бях по-„враждебен към потребителя“, отколкото git.

> почти единственото нещо, което се случва за него по отношение на използваемостта, е Github.

Звучиш като програмист на Visual Basic, който току-що видя C за първи път.