git-annex - Git उपयोगकर्ताओं के लिए बड़े फ़ाइलों को प्रबंधित करने का टूल

• git-annex एक ऐसा टूल है जो बड़ी फ़ाइलों के कंटेंट को सीधे Git repository में डाले बिना भी प्रबंधित करने देता है
• यह offline और online वातावरण में sync, backup, archive करता है और checksum तथा encryption के ज़रिए सुरक्षा सुनिश्चित करता है
• Git की distributed विशेषताओं को बड़े फ़ाइलों पर लागू करके कई drives, servers और cloud के बीच location tracking और transfer को सरल बनाता है
• यह CLI-केंद्रित उपयोगकर्ताओं के लिए उपयुक्त है, जबकि सामान्य उपयोगकर्ताओं के लिए git-annex assistant फ़ोल्डर sync जैसी usability देता है
• दीर्घकालीन संरक्षण के लिए सरल repository format और विभिन्न special remotes के माध्यम से archiving और migration workflows को विस्तारित करने वाला टूल है

---

अवलोकन

• git-annex बड़े फ़ाइलों को प्रबंधित करने का एक टूल है, जिसमें फ़ाइल का कंटेंट Git के बाहर रखा जाता है और केवल metadata तथा location information को Git से प्रबंधित किया जाता है
  • इससे commit history हल्की बनी रहती है और बड़े binary फ़ाइलों का संग्रहण तथा स्थानांतरण लचीले ढंग से संभाला जा सकता है
  • checksum और encryption support के साथ integrity और confidentiality सुनिश्चित होती है
• यह offline और online दोनों स्थितियों में sync, backup, archive करता है, और distributed storages के बीच एक ही फ़ाइल की copy count management तथा logging की सुविधा देता है
• यह command line उपयोगकर्ताओं के लिए अनुकूलित है, लेकिन git-annex assistant के माध्यम से सामान्य उपयोगकर्ता भी इसे फ़ोल्डर sync के रूप में आसानी से इस्तेमाल कर सकते हैं
• शुरुआती उपयोगकर्ताओं के लिए walkthrough दस्तावेज़ उपलब्ध है, जिससे installation और basic workflow जल्दी सीखा जा सकता है

उपयोग परिदृश्य: Archivist(archive-केंद्रित उपयोगकर्ता)

• कई offline archive drives चलाते हुए भी एक single directory tree में सभी फ़ाइलों को एक साथ जैसे browse और reorganize किया जा सकता है
  • भले ही फ़ाइल का कंटेंट offline drive में हो, index और pointers की मदद से वास्तविक deletion के जोखिम के बिना पुनर्संरचना और commit किया जा सकता है
• जब किसी विशेष फ़ाइल की ज़रूरत हो, तो यह बताता है कि वह किस drive पर मौजूद है और उसे आसानी से available state में लाया जा सकता है
  • प्रत्येक drive आपसी location information साझा करती है, जिससे पूरे archive की स्थिति समझी जा सकती है
• यह सरल repository format का उपयोग करता है, इसलिए git-annex और git का उपयोग न करने पर भी लंबी अवधि में फ़ाइल access बना रहता है
• cron jobs के माध्यम से रात में नई फ़ाइलों को स्वचालित रूप से archive किया जा सकता है, और इच्छित तथा अनिच्छित प्रतियों को रिकॉर्ड करके कब replication की ज़रूरत है इसका आधार मिलता है

उपयोग परिदृश्य: Nomad(गतिशील उपयोगकर्ता)

• laptop, portable USB drive/keydrive, remote server, और cloud encrypted storage जैसे भिन्न storages को Git remotes की तरह एकसमान तरीके से प्रबंधित किया जा सकता है
  • यात्रा के दौरान server पर download queue जमा की जा सकती है, और बेहतर connectivity वाले स्थान पर वास्तविक transfer करने वाला deferred transfer workflow समर्थित है
• battery बचाने आदि के लिए USB से तुरंत copy करके local consumption जैसा offline-friendly workflow बनाया जा सकता है
• उपयोग पूरा होने के बाद किन चीज़ों को रखना या हटाना है यह तय कर local space वापस लिया जा सकता है, और अगली sync में बदलावों को server के साथ sync किया जाता है
• special remotes और transfer pipeline के माध्यम से विभिन्न storage backends और network स्थितियों में लचीला data movement संभव होता है

मुख्य विशेषताएँ और लाभ

• content addressing और checksum आधारित integrity assurance तथा encrypted storage support के साथ सुरक्षित दीर्घकालीन संरक्षण
• location tracking के ज़रिए प्रत्येक फ़ाइल की storage location, copy count, availability को स्पष्ट रूप से समझा जा सकता है
• बड़े फ़ाइलों पर distributed version management मॉडल लागू करके centralized storage पर निर्भरता घटती है और offline resilience मिलती है
• assistant mode फ़ोल्डर sync जैसा अनुभव देता है, जिससे CLI में अनभिज्ञ उपयोगकर्ता भी drag-and-drop स्तर की usability पा सकते हैं

लाभों का सार

• git-annex सिर्फ file references को git से प्रबंधित करता है, इसलिए बड़े फ़ाइलों को बिना बोझ के संभालने के लिए उपयुक्त है
• distributed architecture के माध्यम से कई devices और locations में फ़ाइलों का स्वतंत्र movement, storage, sync·backup और version management संभव है
• offline और long-term preservation scenarios, या कई devices और cloud के बीच गतिशील data management में इसकी विशेष रूप से उत्कृष्ट integration और scalability है
• archive-केंद्रित और mobility-केंद्रित मिश्रित उपयोगकर्ताओं के लिए भी यह उपयुक्त है, और copy policy management तथा backend diversification के कारण संगठन और व्यक्तिगत उपयोग दोनों में उपयोगी है
• Git की distributed nature और portability को बड़े data तक विस्तारित करके, यह long-term storage और movement operations में operational risk और मेहनत को कम करता है

[GN⁺]

Hacker News टिप्पणियाँ

• मैं git-annex का उपयोग करके अपनी सभी ड्राइव्स का डेटा मैनेज करता हूँ। यह अपने-आप ट्रैक करता है कि कौन-सी फ़ाइल किस ड्राइव पर है, कॉपी की पर्याप्त संख्या बनाए रखता है, और सभी फ़ाइलों के checksums की पुष्टि करता है। ऑफ़लाइन ड्राइव्स के साथ भी यह बिना समस्या के अच्छी तरह काम करता है। git-annex शुरुआत में समझने में थोड़ा कठिन लग सकता है, इसलिए मैं सलाह दूँगा कि एक अस्थायी repository बनाकर walkthrough फ़ॉलो करें और हाथों-हाथ अभ्यास करें। अलग-अलग workflow भी देखने लायक हैं

  • जानना चाहता हूँ कि आप कितना डेटा रख रहे हैं। मैं लगभग 1 लाख से 10 लाख फ़ाइलें, कई TB फ़ोटो डेटा ZFS पर git-annex से मैनेज कर रहा हूँ। शुरुआत में कोई समस्या नहीं थी, लेकिन हाल में यह धीरे-धीरे इतना धीमा हो गया है कि हर कमांड में 5–30 मिनट लग जाते हैं। समझ नहीं आ रहा कि वजह ZFS है, git-annex है, या डिस्क

  • मैं भी लंबे समय से git-annex से डेटा मैनेज करने के बारे में सोचता रहा हूँ, लेकिन फ़ाइलों को पूरी तरह हटाने में कुछ friction है और कुछ समस्याएँ भी मिलीं। अगर आपके पास समय हो, तो क्या आप बता सकते हैं कि आप इसे कैसे इस्तेमाल करते हैं

• पेज पर नहीं दिखता, लेकिन git-annex को Joey Hess ने बनाया है। उन्होंने moreutils, etckeeper भी विकसित किए हैं

  • मेरे हिसाब से इससे भी ज़्यादा मशहूर बात यह है कि वे 1996 से कई दशकों तक Debian के core contributor रहे हैं। आज जिस Linux के बड़े हिस्से की हम कल्पना करते हैं, उसमें उनका बड़ा योगदान है

• Git की नई native large object management सुविधा पर हाल की चर्चा यहाँ हुई थी

  • जोड़ना चाहूँगा कि मुझे क्यों लगता है कि वह चर्चा ज़्यादा संबंधित नहीं है, यह मैंने टिप्पणी में भी लिखा है। annex वास्तव में “large files in git” समस्या से थोड़ा अलग क्षेत्र है। git-annex को इस नज़रिए से समझना आसान है कि यह LFS जैसी चीज़ों में “server-side” storage समस्या को Git-native तरीके से distributed रूप में हल करता है

• git-annex की निराशाजनक बात Haskell है। भाषा से मुझे नफ़रत नहीं है, लेकिन इसे install करने के लिए जितनी dependencies चाहिए, उसे देखकर मैं सचमुच चौंक गया। उनमें से काफ़ी की कहीं और ज़रूरत नहीं पड़ती, और कई applications में version conflict भी आसानी से हो जाता है। system package manager से install करें तो यह और भी मुश्किल हो जाता है। सिर्फ annex और pandoc install करने पर भी हर दिन दर्जनों Haskell package updates आते रहते हैं। अगर आप source से build होने वाला distribution इस्तेमाल करते हैं, तो यह किसी दुःस्वप्न जैसा है। सच कहूँ तो मुझे लगता है कि इनमें से ज़्यादातर को static link करना सुरक्षित होगा। फिर भी Haskell समुदाय इसे बारीक library modularization का परिणाम बताता है। लेकिन system management जैसी दूसरी priorities भी होती हैं, और Rust, Go, Zig, C, C++ में मुझे ऐसी समस्या नहीं मिली। मैं Haskell ecosystem या उसके users के ख़िलाफ़ नहीं हूँ, और इसे सीखने का इरादा भी है। लेकिन यह समस्या है क्यों, और इसका समाधान क्या है, यह जानना चाहता हूँ

  • Haskell tooling में static linking पहले से supported है। मैं Solus के लिए Haskell stack maintain करता हूँ, और pandoc को सिर्फ libc dependency के साथ, बाकी सभी Haskell packages को binary में static रूप से bundle करके Rust की तरह distribute करता हूँ। यानी यह पूरी तरह संभव है। Solus में dependencies बहुत ज़्यादा हो जाती हैं, इसलिए हम बस static linking कर देते हैं। मुझे यह distribution maintainer के फ़ैसले का मामला लगता है

  • “ज़्यादातर को static link करना सुरक्षित होगा” वाली बात पर, क्या distribution repo के मामले में यह आख़िरकार package manager policy का मुद्दा नहीं है

  • एक full-time Haskell developer होने के नाते मुझे भी non-static-linked Haskell packages के प्रति ऐसी ही झिझक है। AUR में पहले से static-linked versions मौजूद हैं, इसलिए कम-से-कम यह असंभव नहीं है। packagers dynamic linking पर इतना ज़ोर क्यों देते हैं, इस पर मैंने भी गहराई से नहीं देखा। आम तौर पर dynamic linking internal software distribution के लिए ठीक हो सकता है, लेकिन शायद वही सोच वे बेवजह distributions पर भी लागू कर रहे हैं

  • आप कौन-सा package manager इस्तेमाल करते हैं? apt-based systems में Haskell की वजह से मुझे कभी समस्या नहीं हुई

  • हर बार pacman -Syu चलाने पर updates का आधा हिस्सा Haskell packages का होता है, और यह परेशान करता है। शायद इसकी वजह pandoc या shellcheck है

• git-annex वाकई बहुत कूल तकनीक है। लेकिन मेरी धारणा है कि यह single-user repositories में सबसे अच्छा काम करता है। जैसे, जब कोई एक व्यक्ति अपनी फ़ाइलें, दस्तावेज़, संगीत आदि कई devices में फैलाकर व्यक्तिगत डेटा मैनेज कर रहा हो। मैंने इसे बड़े files वाले collaborative repository में sync के लिए इस्तेमाल किया है, लेकिन “magic” branch वाला तरीका अच्छी तरह scale नहीं करता

  • हर किसी का अनुभव अलग हो सकता है, लेकिन हमारे संस्थान में यह उल्टा अच्छी तरह काम करता है। हम एक digital archive institution हैं, और 10 साल से ज़्यादा समय से internal repository के backend के रूप में git-annex इस्तेमाल कर रहे हैं। स्टाफ लगभग 15–20 लोगों का है, लेकिन 30TB से ज़्यादा डेटा, 7.5 लाख फ़ाइलें (binary + metadata), और सैकड़ों repositories को बिना दिक्कत संभालते हैं

• मैं self-hosted forgejo इस्तेमाल कर रहा हूँ। अभी तक मुझे git-annex में LFS से बेहतर कुछ खास नहीं दिखा, और setup भी आसान नहीं लगता। git-annex का Haskell में लिखा होना भी मुझे पसंद नहीं, और मुझे लगभग 50% धीमा होने की बात भी मिली है (हालाँकि सिर्फ एक source मिला, इसलिए यह भरोसेमंद जानकारी है या नहीं, पता नहीं)। कमांड्स जटिल होने के कारण होंगे, लेकिन LFS की तरह सिर्फ .gitattributes देखकर लगभग सब समझ जाने वाली सुविधा इसमें नहीं है। git-annex में मुझे .gitattributes जैसी पारदर्शिता भी नहीं दिखी। और अगर कोई tutorial ‘git lfs ls-files’ के बराबर कमांड भी न दिखाए, तो शायद मेरी दिलचस्पी न बने। मुझे ‘git status’ और ‘git lfs ls-files’ से चीज़ें जाँचना पसंद है

  • धीमापन Haskell की वजह से नहीं है। git-annex एक distributed backup tool है, इसलिए I/O और data preservation को लेकर इसका बहुत सतर्क व्यवहार ही धीमापन पैदा करता है। उदाहरण के लिए, drop कमांड चलाने पर इसे real time में सभी remotes पर यह जाँचना पड़ता है कि वह content वहाँ मौजूद है या नहीं, इसलिए यह धीमा होता है। --fast जैसे options से अगर आप सिर्फ local metadata पर भरोसा करें और verification छोड़ दें, तो यह बहुत तेज़ हो जाता है (लेकिन थोड़ा जोखिम भी रहता है)

  • LFS और git-annex का उपयोग थोड़ा अलग है। LFS उन development repositories के लिए उपयुक्त है जहाँ Git repository में large files मिली-जुली हों, जैसे game development। git-annex तब बेहतर फिट बैठता है जब आप महत्वपूर्ण डेटा का backup लेना चाहते हों, या music folder जैसी बड़ी file collections को कई जगहों पर रखना चाहते हों। मैं इसे दूसरे तरीके से इस्तेमाल करता हूँ

  • git-annex को support करने वाला Forgejo soft-fork मौजूद है: forgejo-aneksajo

  • git-annex से मैनेज किया गया मेरा सबसे बड़ा repository कई systems में फैला हुआ कई TB का है, और बहुत-सी फ़ाइलें 10GB से भी बड़ी हैं। अगर लेखक git-lfs-ls-files जैसा कुछ ढूँढ रहा है, तो git-annex में git annex list --in here शायद उसके समान भूमिका निभाता है

• कमांडलाइन documentation में असली उपयोग के उदाहरण सबसे पहले आना अच्छा लगा। बहुत-से tools आम तौर पर ऐसे रहस्यमय options की व्याख्या से शुरू होते हैं जो शायद ही कभी काम आते हों, और यह हमेशा खटकता था

• GitHub ने LFS के लिए Microsoft शैली का NIH (Not Invented Here) अपनाया और git-annex को नहीं अपनाया

  • मुझे भी git-annex ज़्यादा elegant लगता है, लेकिन cross-platform compatibility कमज़ोर है। जानकारी के लिए, LFS GitHub और Bitbucket (सटीक तौर पर कौन-सा forge था, यह याद नहीं) के सहयोग से निकला था। एक पक्ष ने implementation दी, दूसरे ने नाम, और Git conference में मिलने के बाद दोनों एक हो गए। आज की सबसे बड़ी निराशा GitHub के large projects पर लागू limits हैं। इसके अलावा, “push करने के लिए सभी objects local में होने चाहिए” वाली policy के कारण, बड़े development communities जल्दी ही limit पार कर लेते हैं। संदर्भ के लिए: मैंने git-lfs में योगदान दिया है

  • (ईमानदारी से कहूँ तो) GitHub का NIH तरीका हर मायने में नुकसानदेह है। git-annex को पसंद करने वाले एक presenter का यह talk है: Staying in Control of your Scientific Data with Git Annex by Yann Büchau

• विडंबना यह है कि पिछले वीकेंड मैंने एक दिन में अपना खुद का large-file version control system बना लिया। मुझे git-annex इतना नापसंद है। यह फ़ाइलों को blobs में बदल देता है और file system को फुला देता है। मेरा मुख्य उद्देश्य distributed फ़ाइलों के बीच sync है, version control में मेरी कोई दिलचस्पी नहीं है (और सच कहूँ तो समझ नहीं आता कि large files के लिए version control की ज़रूरत ही क्यों है)। AI और Python से फ़ाइलों को hash करके lookup table बनाई जा सकती है, और rclone से source sync करने के helper methods भी बनाए जा सकते हैं। इससे कहीं ज़्यादा सरल और प्रभावी तरीके मौजूद हैं

• मैंने इसे कई साल इस्तेमाल किया, और सबसे बड़ा फ़ायदा cloud storage providers और backups के साथ integration था। लेकिन वह integration हमेशा अस्थिर रहा और ऐसे third-party plugins पर निर्भर था जिनका maintenance नहीं हो रहा था। एक समय data inconsistency bug भी था, इसलिए मैंने आख़िरकार इसे छोड़ दिया। जानना चाहता हूँ कि पिछले 5 सालों में इसमें कोई सुधार हुआ है या नहीं

  • मुझे लगता है यह इस पर निर्भर करता है कि आप किस तरह के cloud storage provider का उपयोग कर रहे हैं। S3, webdav, sftp जैसे official standard protocols को support करने वाले providers यहाँ फ़ायदेमंद रहते हैं। हाल के समय में rclone-आधारित special remote git-annex में built-in आ गया है, इसलिए यह पुराने third-party remotes की तुलना में बेहतर maintained है और rclone जिन लगभग सभी cloud remotes को support करता है, उनके साथ काम कर सकता है