أشعر أنه يجب استبدال العلاقات العامة Github بأدوات محلية من جانب العميل أولا. العلاقات العامة - > بعض الإشارات التي تطلب دمج فرع في فرع مستهدف مراجعة العلاقات العامة - > إعادة استخدام نفس الإشارة المذكورة أعلاه ، أرسل العلاقات العامة فوق فرع العلاقات العامة الآن تحتاج الكتل المختلفة إلى تعليقات خاضعة للرقابة في المراجعة. منجز.

/ أذكر بالتحقق من الإصدار الجديد من @radicle_xyz الذي يهدف إلى التحكم في المراجعة اللامركزية المحلية أولا بما في ذلك التذاكر والتعاون مع الفروع ...

توضيح: يهدف "تعليق الفرق الكبير" إلى الوفاء بوظيفة تعليق مراجعة GH: يتم تتبعه في محفوظات المراجعة، ويعلق على قطعة كبيرة (على سبيل المثال، "يجب أن تكون واجهة برمجة التطبيقات هذه غير متزامنة" حيث تقوم الكتل التالية بتحويل الوظيفة)، ولا تظهر في التعليمات البرمجية.

لن أتفاجأ على الإطلاق إذا كان لدى git بالفعل هذا التصميم في مكان ما (تحت طبقات من التعقيد) ، لأنه قريب جدا من أسلوب "تصحيحات البريد الإلكتروني للمتعاونين" الأقرب إلى جذور git. التطور هو التحكم في مراجعة الفرق * التعليقات *.

توضيح 2: يمكن للمقدم الأصلي الرد على "العلاقات العامة للمراجعة" إما عن طريق قبول الفرق ، أو عن طريق إنشاء علاقات عامة ثالثة أعلى العلاقات العامة للمراجعة (استجابة للمراجعة). يستمر هذا التنس على الطاولة حتى يقبل الطرفان جميع التعديلات. يتم حفظ التفاعل في المحفوظات

ملاحظة: أنا أقوم بالقرصنة على أداة تحكم في المراجعة الأولى المحلية اللامركزية كهواية (~ من سنة إلى ∞ تاريخ الشحن). أريد أن يدعم حالات الاستخدام هذه: - عملية العلاقات العامة على النحو الوارد أعلاه - يمكن أن ينتج عن القرار تغيير واحد "مسحوق" كجزء من "السرد" - التاريخ الكامل لا يزال متاحا

@lftherios @radicle_xyz @radicle أحب اللامركزية ذات العقدة الورقية ، ولكن كمستخدم ، أستخدم استضافة البائعين بنسبة 85٪ من التطبيقات ، وإذا لم تكن خارج الصندوق ، فغالبا ما أستسلم قبل إعداد البنية التحتية الخاصة بي.

@lftherios @radicle_xyz @radicle استضافة البائع مع الاشتراك ، والبنية التحتية مفتوحة المصدر ، والقدرة على التصدير بدون قفل هي مجموعة الكريبتونيت الخاصة بي للتطبيقات المدفوعة. لذا فإن ملاحظاتي الحالية (من الذاكرة) هي أنني كنت أتمنى أن أتمكن من الاشتراك في العقدة المستضافة عالية التوفر والتي تكرر جميع مستودعاتي.