Նույն պահոցը աշխատում է տերմինալում git clone-ով, սակայն ձախողվում է JGit օգտագործող ծրագրում։ Սա երկու իրականացումների համեմատություն է, ոչ պարտադիր՝ նույն հաճախորդի աշխատող և կոտրված պատճենների։

JGit-ի կարգավորման տեղեկատուն ասում է, որ վստահված սերվերի կարգավորումն օգտագործում է Java-ի ստանդարտ մեխանիզմները java.net.ProxySelector-ի միջոցով։ Մի՛ ենթադրեք, որ Native Git-ի բոլոր HTTP ընտրանքները ներդրված են միայն այն պատճառով, որ երկու հաճախորդներն էլ հասկանում են Git կարգավորման ֆայլը։

Որոշե՛ք JGit-ը ներառող ծրագիրը, դրա տարբերակը և ընտրված HTTP փոխանցումը։ Հյուրընկալող ծրագիրը կարող է տրամադրել կարգավորումներ կամ վարքագիծ JGit-ի ինքնուրույն լռելյայն արժեքներից դուրս։

Այնուհետև ստուգե՛ք այդ գործընթացին տեսանելի Java վստահված սերվերի կարգավորումը։ URLConnection-ի վրա հիմնված HTTP փոխանցման համար ստուգե՛ք JVM հյուրընկալողի և պորտի հատկությունները, որոնք այն օգտագործում է։ Ծրագրի մեկնարկից հետո անկապ տերմինալում մուտքագրված հատկությունը չի կարող վերակարգավորել աշխատող JVM-ը։ IDE-ի Native Git գործողությունը և դրա JGit գործողությունը նույնպես կարող են տարբեր ուղիներ օգտագործել։

Վստահված սերվերի նույնականացումը առանձնացրե՛ք երթուղու ընտրությունից։ Հյուրընկալողին և պորտը նույնացնող Java վստահված սերվերի հատկությունները ինքնաբերաբար չեն ներդնում վստահված սերվերի գաղտնաբառի սխեմա։ Օգտագործե՛ք հյուրընկալող ծրագրի աջակցվող նույնականացման մեխանիզմը։

Օգտակար հարցն է՝ «ո՞ր վստահված սերվերն ընտրեց այս JGit հարցումը», այլ ոչ թե՝ «արդյո՞ք իմ Git կարգավորումը պարունակում է վստահված սերվերի տող»։ Native Git-ի հաջողությունը արժեքավոր համեմատություն է, սակայն այն չի պատասխանում իրականացմանը հատուկ այդ հարցին։

Առնչվող հոդվածներ