Dlaczego niektóre projekty open source nie akceptują żądań ściągania, a jedynie przesyłanie plików łatek pocztą e-mail

Dlaczego niektóre projekty Open Source nie akceptują żądań ściągania, ale wymagają od autorów tylko łatania plików e-mail? np. Git Chociaż publikują kod w github lub innym hostowanym serwerze SCM. Wysyłanie plików łatek nie jest interaktywne ani wygodne. Plik łatki jest staromodny. Żądania ściągania są interaktywne. Inne osoby mogą również dyskutować.

Może to zależeć od tego, kto będzie odpowiedzialny za przyjęcie twojego żądania ściągnięcia.

Jeśli to Linus Torvalds , cóż ... lepszy jest dobry stary patch :

Nie wykonuję żądań ściągania na githubie.

github wyrzuca wszystkie istotne informacje, takie jak posiadanie nawet ważnego adresu e-mail dla osoby, która prosi mnie o pobranie .
Diffstat jest również niedobór i bezużyteczny.

Git jest wyposażony w ładny moduł generujący żądanie ściągnięcia, ale zamiast tego github postanowił zastąpić go własną, całkowicie gorszą wersją.
W rezultacie uważam github za bezużyteczny do tego rodzaju rzeczy.

Nadaje się do hostingu , ale żądania ściągania i edycja zatwierdzeń online są po prostu śmieciami.
Powiedziałem ludziom z Github o moich obawach, nie myśleli, że mają znaczenie, więc się poddałem. Zgłoś błąd w github.

Szczegóły:

Aby mnie wyciągnąć z github, trzeba:

• (a) złożyć prawdziwe żądanie ściągnięcia, a nie badziewne bzdury, które robi github, gdy poprosi się go o pociągnięcie:
  • prawdziwe wyjaśnienie ,
  • prawidłowe adresy e-mail ,
  • właściwy dziennik , oraz
  • właściwy diffstat .
• (b) ponieważ tożsamość github jest losowa, oczekuję, że żądanie ściągnięcia będzie oznaczonym tagiem , dzięki czemu będę mógł zweryfikować tożsamość danej osoby.

Odmawiam również pobierania zatwierdzeń dokonanych za pomocą interfejsu sieciowego github.
Ponownie dlatego, że sposób, w jaki działa interfejs sieciowy github, te zatwierdzenia są niezmiennie bzdurą.
Zatwierdzenia wykonane w github niezmiennie mają całkowicie nieczytelne opisy, ponieważ funkcja dokonywania zatwierdzeń github nie robi żadnej z najprostszych rzeczy, których ludzie jądra oczekują od wiadomości zatwierdzenia:

• brak „krótkiego opisu jednowierszowego w pierwszym wierszu”
• bez zdrowego zawijania długiego opisu, który wpisujesz: wiadomości github commit są zwykle (jeśli w ogóle mają jakiś opis) jedną długą nieczytelną linią.
• brak wylogowań itp., które są wymagane do przesyłania jądra.

github może ułatwić pisanie dobrych komunikatów zatwierdzania i wymuszać odpowiedni „oneliner dla krótkich dzienników i gitkpełne wyjaśnienie pełnych dzienników”.
Ale github nie.
Zamiast tego interfejs „zatwierdzania w sieci” github jest jednym okropnym polem do wprowadzania tekstu bez absolutnie żadnego zdrowego sposobu na napisanie dobrze wyglądającej wiadomości.

Gdy pojawi się pytanie w polu tekstowym dla komunikatów zatwierdzania:

@torvalds Interfejs użytkownika GitHub zatwierdzenia zapewnia pole tekstowe dla komunikatów zatwierdzania.
Obsługuje to nowe wiersze i ułatwia wykonywanie ładnie sformatowanych komunikatów zatwierdzania :)

Nie, nie ma.
Obsługuje pisanie długich linii, których * * * nie masz pojęcia, jak długie są.
Obszar tekstowy nie wykonuje podziałów linii i nie ma sposobu, aby ocenić, dokąd pójdą podziały linii.

Innymi słowy, bardzo utrudnia to wykonywanie „ładnie sformatowanych komunikatów zatwierdzania”.
Nie wymusza również trywialnego modelu „oneliner for shortlog” , więc komunikaty zatwierdzania często wyglądają jak totalna bzdura w shortlogach i gitku.

Więc interfejs użytkownika zatwierdzania github powinien mieć

• oddzielne okno tekstowe „shortlog” w jednym wierszu, aby ludzie nie mogli tego zepsuć.
• jakiś sposób na rzeczywiste zawijanie wyrazów przy standardowym 72-kolumnowym znaku.
• przypomnienia o podpisaniu umowy itp., których niektóre projekty potrzebują ze względów specyficznych dla projektu lub nawet z powodów prawnych.