VPN کے ذریعے SSHFS پر git status سست ہے: کام منتقل کریں

200 MB کی فائل کاپی کریں اور وہ اڑتی ہے۔ اسی ڈائریکٹری میں git status چلائیں اور انتظار اتنا طویل ہے کہ دھیان کہیں اور چلا جائے۔ یہ دونوں مشاہدے متضاد نہیں، کیونکہ بڑے پیمانے کی منتقلی تھروپٹ ناپتی ہے جبکہ Git ناپتا ہے کہ فی سیکنڈ کتنے چھوٹے فائل سسٹم سوالات پوچھ سکتا ہے، اور ماؤنٹ شدہ دور دراز درخت ہر سوال کو ایک آنے جانے میں بدل دیتا ہے۔ VPN کو ٹیون کرنے سے غلط شکل کا کام ٹھیک نہیں ہوگا۔

status غلط پیمانہ کیوں ہے

Git کو بہت سی فائلوں کا علم ہونا چاہیے: کون سی تبدیل ہوئی، کون سی ٹریک نہیں ہوئی، اور کیا کیش شدہ انڈیکس ڈیٹا اب بھی ڈسک پر موجود ڈیٹا سے مطابقت رکھتا ہے۔ SSHFS کے ذریعے ان میں سے ہر مشاہدہ نیٹ ورک آپریشن ہو سکتا ہے۔ یہاں کام کی اکائی فائلوں کی تعداد ہے، میگابائٹ نہیں۔

اسی لیے کلون کے بعد پہلا status سست ہوتا ہے، اور اسی لیے بلڈ آؤٹ پٹ سے بھرے درخت میں اگلے مزید سست ہو سکتے ہیں۔ ٹریک نہ ہونے والی فائلوں کی اسکیننگ ایسی ڈائریکٹریوں سے گزرتی ہے جن کی آپ کو پروا نہ ہو، اور ہر قدم لنک پر ایک اور درخواست ہے۔ 40 ms کے راستے پر چند ہزار اندراجات کا درخت چند ہزار آنے جانے میں بدل جاتا ہے۔ اس حساب کی تصدیق کے لیے پیکٹ کیپچر کی ضرورت نہیں۔

ڈاؤن لوڈ پیمانہ کہتا ہے کہ لنک ٹھیک ہے؛ یہ کچھ نہیں کہتا کہ ہزار چھوٹی پڑھائیاں آج دوپہر تک پوری ہوں گی یا نہیں۔

کام کا درخت منتقل کریں، ٹیوننگ نوب نہیں

مقامی کلون کام کا درخت، انڈیکس اور Git کی کارروائیاں ایک ہی مشین پر رکھتا ہے۔ پھر pull ایک نظر آنے والا نیٹ ورک قدم بن جاتا ہے، ہر فائل کی جانچ نہیں۔

یہ تب موزوں ہے جب ڈویلپر ضروری ماخذ مقامی طور پر رکھ سکے، اور اکثر ایسا ہی ہوتا ہے۔ یہ commit اور تعیناتی کی حد کو بھی تیز کرتا ہے، کیونکہ مقامی فائل میں ترمیم اب اتفاقاً چلتی ہوئی دور دراز سروس کو نہیں بدلتی؛ تبدیلی کو باقی سب کی طرح پش اور تعینات کرنا پڑتا ہے۔ قیمت یہ ہے کہ کوڈ دو جگہ موجود رہتا ہے، اس لیے طے کریں کون سی نقل مستند ہے اور سرور پر کی گئی فوری مرمت کیسے مخزن میں واپس آتی ہے۔ وہ گفتگو اس status کمانڈ سے سستی ہے جسے کوئی چلانا نہیں چاہتا۔

اگر کام کی جگہ دور ہی رہنی ہو، تو وہیں Git چلائیں

کبھی کام کی جگہ منتقل نہیں ہو سکتی: بلڈ کو وہی ماحول چاہیے، ڈیٹا بہت بڑا ہے، یا پالیسی ماخذ کو میزبان پر رکھتی ہے۔ تب فائلوں کے ساتھ ہی Git اور متعلقہ ڈویلپمنٹ ٹولز چلائیں، منظور شدہ دور دراز شیل یا دور دراز ڈویلپمنٹ ماحول کے ذریعے۔ ایڈیٹر لیپ ٹاپ پر رہ سکتا ہے جبکہ اس کا بیک اینڈ کام کے درخت کے پاس کام کرتا ہے۔

تب مہنگی کارروائیاں دور دراز میزبان پر مقامی طور پر ہوتی ہیں، اور نیٹ ورک ہزاروں stat کالوں کی بجائے ایڈیٹر کی ٹریفک اٹھاتا ہے۔ یہ مقامی کلون جیسا ہی علاج ہے، ہجرت نہیں، تعیناتی کے انتخاب کے طور پر بیان کیا گیا۔

ہم آہنگی مالکان والا ورک فلو ہے، کیش نہیں

ہم آہنگ کام کی جگہ بار بار ہونے والی دور دراز پڑھائی کم کر سکتی ہے، مگر یہ شفاف کیش نہیں۔ اسے ہر تبدیلی کے لیے مالک، تنازعات کے لیے قاعدہ، اور پیدا شدہ فائلوں پر اتفاق چاہیے جنہیں دونوں فریق اپنی سمجھتے ہیں۔ ان قواعد کے بغیر یہ انتظام سہولت کی بجائے اختلاف پیدا کرتا ہے۔

ان کے بغیر دو طرفہ ہم آہنگی وہ مسئلہ حل کرنے کی بجائے مختلف مسئلہ پیدا کرتی ہے، عام طور پر ایسا انضمام جسے کوئی کسی سے منسوب نہیں کر سکتا۔ ایک مشترکہ کام کے درخت پر دو Git عمل چلانے سے گریز کریں، جب تک آپ نہ سمجھیں کہ وہ کیسے ہم آہنگ ہوتے ہیں۔

پھر ٹیون کریں، اور SSH کو سمجھداری سے رکھیں

انتظام درست ہونے کے بعد دو سیٹنگز بدلتی ہیں کہ Git کو کتنی فائلوں کے بارے میں پوچھنا ہے: status.showUntrackedFiles اور core.untrackedCache کے پیچھے ٹریک نہ ہونے والا کیش۔ کوئی بھی 40 ms پر ہر سوال کی لاگت نہیں بدلتی؛ وہ صرف سوالات کی تعداد بدلتی ہیں۔ نوب تبھی گھمائیں جب آنے جانے مقامی ہو جائیں۔

اس کمانڈ کا وقت ناپیں جو آپ کو چڑاتا ہے، ایک بڑی فائل کاپی کرنے والے پیمانے سے استدلال کرنے کی بجائے، اور معاون SSH انکرپشن کو چھیڑیں نہیں۔ پرانا سائفر آنے جانے کو مختصر نہیں کرتا؛ یہ دوسرا مسئلہ شامل کرتا ہے جو پہلے سے زیادہ جیتا رہتا ہے۔ git status کا حوالہ ایک بار پڑھنے کے قابل ہے، کیونکہ کمانڈ اپنے نام سے کہیں زیادہ کام کرتی ہے۔