მშობლიური Git პროქსის მეშვეობით მუშაობს, JGit კი არა
JGit არის Java-ის იმპლემენტაცია საკუთარი მხარდაჭერილი ტრანსპორტის პარამეტრებით. http.proxy ჩანაწერი მშობლიურ Git-ში უნივერსალური კონფიგურაცია არ არის ყველა Git კლიენტისთვის.
იგივე რეპოზიტორი მუშაობს ტერმინალში git clone-ით და იშლება JGit-ის გამოყენებით მუშაობისას. ეს ორი იმპლემენტაციის შედარებაა და არა აუცილებლად ერთი კლიენტის მუშა და გატეხილი ასლის შედარება.
JGit-ის კონფიგურაციის ცნობარი ამბობს, რომ პროქსის კონფიგურაცია იყენებს Java-ს სტანდარტულ მექანიზმებს java.net.ProxySelector-ის მეშვეობით. ნუ ჩათვლით, რომ მშობლიური Git-ის ყველა HTTP პარამეტრი რეალიზებულია მხოლოდ იმიტომ, რომ ორივე კლიენტს ესმის Git-ის კონფიგურაციის ფაილი.
განსაზღვრეთ JGit-ის შემცველი აპლიკაცია, მისი ვერსია და არჩეული HTTP ტრანსპორტი. მასპინძელ აპლიკაციას შეუძლია მოგვცეს პარამეტრები ან ქცევა JGit-ის დამოუკიდებელი ნაგულისხმევი მნიშვნელობების მიღმა.
შემდეგ შეამოწმეთ ამ პროცესისთვის ხილული Java პროქსის კონფიგურაცია. URLConnection-ზე დაფუძნებული HTTP ტრანსპორტისთვის შეამოწმეთ JVM-ის მასპინძლისა და პორტის თვისებები, რომლებსაც ის იყენებს. აპლიკაციის გაშვების შემდეგ უკავშირო ტერმინალში შეყვანილი თვისება ვერ გადააკონფიგურირებს მომუშავე JVM-ს. IDE-ის მშობლიური Git ოპერაცია და მისი JGit ოპერაცია ასევე შეიძლება სხვადასხვა გზას იყენებდეს.
პროქსის ავთენტიფიკაცია გამოყავით მარშრუტის არჩევისგან. Java პროქსის თვისებები, რომლებიც მასპინძელსა და პორტს განსაზღვრავენ, ავტომატურად არ ახორციელებენ პროქსის პაროლის სქემას. გამოიყენეთ მასპინძელი აპლიკაციის მხარდაჭერილი ავთენტიფიკაციის მექანიზმი.
სასარგებლო კითხვაა „რომელი პროქსი აირჩია ამ JGit მოთხოვნამ?“ და არა „შეიცავს ჩემი Git კონფიგურაცია პროქსის ხაზს?“. მშობლიური Git-ის წარმატება ღირებული შედარებაა, მაგრამ ის არ პასუხობს იმპლემენტაციისთვის სპეციფიკურ ამ კითხვას.