اخیرا یه مشکل تو روش محاسبه تفاوت بین نسخه‌های مختلف فایل‌ها توی git کشف شده که می‌تونه باعث بشه حجم ریپازیتوری‌ها چند برابر بشه. این مشکل باعث افت کارایی و مصرف بیش‌ازحد فضای ذخیره‌سازی می‌شه.
داستان هم از اونجایی شروع شد که یکی از مهندس‌های ارشد مایکروسافت، جاناتان کریمر، درباره یه ریپازیتوری جاوااسکریپت خیلی بزرگ که تیمشون روش کار می‌کنه پست کرده. یه مونو ریپو (یه ریپازیتوری که پروژه‌های مرتبط زیادی رو نگه‌می‌داره). بیش از ۱۰۰۰ کاربر فعال ماهانه و حدود ۲۰ میلیون خط کد وجود داشته. طبق گزارش کریمر، کلون کردن این ریپازیتوری ۱۷۸ گیگابایت از فضای دیسک رو مصرف کرده که خیلی بیشتر از چیزی بوده که انتظارش رو داشتن.
تیمشون برای بررسی مشکل با یکی از کانتریبیوترهای git به اسم Derrick Stolee، که قبلا تو GitHub بوده و حالا تو مایکروسافت مهندس ارشد هست، مشورت کردن. استولی متوجه می‌شه که وقتی git دو تا فایل با نام‌های مشابه (اینجا CHANGELOG.md) رو مقایسه می‌کنه، درواقع فایل‌های مختلف از پکیج‌های مختلف رو مقایسه می‌کنه و این باعث می‌شه با هر کامیت اختلاف بزرگی شناسایی بشه.
استولی یه pull request برای git فرستاده که یه چیزی به اسم “path walk API” اضافه می‌کنه. این API جدید به نرم‌افزار این امکان رو می‌ده که آبجکت‌ها رو بر اساس مسیر دسته‌بندی کنه و “کاملا از هرگونه کانفلیکت نام‌ها جلوگیری کنه.” کریمر با استفاده از دستور git repack و با آرگومان جدید path-walk-، سایز ریپازیتوری رو از ۱۷۸ گیگابایت به ۵ گیگابایت رسوند.
استولی تو mailing list کرنل لینوکس درباره همین مشکل نوشته که “کشف اصلی این بود که الگوریتم name-hash فعلی فقط ۱۶ کاراکتر آخر مسیر رو در نظر می‌گیره و تو همین محدوده بعضی برخوردها به‌صورت طبیعی رخ می‌ده.”
استولی تو یه پست دیگه اشاره کرد که “ریپازیتوری‌ای که بررسی کردم الگوی مشخصی تو ۱۰۰ فایل اول از نظر حجم داشت: ۹۹تاشون فایل‌های CHANGELOG.json و CHANGELOG.md بودن… که تغییرات کوچیکی که انتظار می‌رفت تبدیل به دلتاهای ۲۰ تا ۶۰ مگابایتی شدن.”
استولی مثال‌هایی از ریپازیتوری‌های دیگه هم داد که با گزینه‌های جدید، فضای لازم به‌شدت کم شده بود، یکی از ۱۳۰,۰۴۹ مگابایت به ۴,۴۳۲ مگابایت کاهش پیدا کرده بود.
عواقب بزرگ‌شدن بیش‌ازحد ریپازیتوری‌ها فقط فضای دیسک زیاد نیست، بلکه عملیات Git رو کند می‌کنه – گاهی تا حدی که به‌خاطر تأخیر یا پهنای باند موجود کامل از کار می‌افته.
هرچند این صرفه‌جویی‌های فضایی خیلی چشمگیره، ولی این مثال‌ها مربوط به ریپازیتوری‌های بزرگیه که کانفیلیکت‌های زیادی بین اسم فایل‌ها دارن. ریپازیتوری‌های معمولی git به این اندازه بهبود رو متوجه نمی‌شن، ولی با این حال، توسعه‌دهنده‌ها مشتاقن تا این ویژگی‌های جدید رو تو نسخه بعدی git ببینن.
اگر دوست داشتید راجع به مشکل دیگه‌ای با git که منجر به پیدایش VFS for git شد، بخونید…