באיזו מערכת Source Control / Version Control אתם משתמשים?

[חזי2003]

השאלה היא לא לכמה זמן reflog שומר

השאלה היא לכמה זמן הקומיטים האבודים האלה יישארו שם. ההגדרה הדיפולטיבית ל-gc של git היא להעיף אותם אחרי שבועיים. לפעמים הם יישארו שם יותר מזה, אם התמזל המזל ושום דבר לא הריץ git gc בזמן הזה, אבל שבועיים זו המגבלה הבטוחה.

 

[ipv6]

מה שעשוי לרוץ ברקע

בלי שביקשתי זה git gc --auto. הוא אמור ל'ארוז' meta data ישן בzlib ולא למחוק (כנראה שכבר לא אוכל לחזור בקלות אבל בטח אפשר לשחזר את זה). איפה ראית שחלון הזמן הוא שבועיים?

 

[חזי2003]

אני מדבר על קומיטים שהם unreachable

כלומר, אין שום branch או tag שדרכו אפשר להגיע אליהם (או לצאצאים שלהם, כמובן), שזו בדרך כלל הבעיה עם reset --hard. אם תסתכל בתיעוד של git gc, תראה שהדיפולט עבור gc.pruneExpire הוא שבועיים. &nbsp אבל כעת אני רואה שהאמת היא באמצע בין שנינו. כל עוד קומיט נגיש דרך reflog, הוא לא נחשב unreachable לעניין הזה, אז החלון של שבועיים לא חל עליו. מצד שני, זה גם לא 90 יום. ל-reflog יש הגדרה נפרדת מתי לעשות prune לרשומות ישנות כשהן unreachable (כשהפעם reflog לא נחשב), וזה 30 יום בברירת המחדל - gc.reflogExpireUnreachable.

 

[ipv6]

אני מבין למה הכוונה

מעניין אותי מה עלול לקרות לי "מתחת לרגליים" (בלי יוזמת משתמש). gc.pruneExpire רלוונטית להרצה של "git gc --prune" וממה שאני רואה, git gc לא אמור לרוץ עם הדגל "prune" מעצמו, רק אם המשתמש יוזם. כך שההגדרה הזאת לא רלוונטית (למיטב הבנתי). מה שעלול לקרות מעצמו (ללא יוזמה של המשתמש) זה הרצה של git gc --auto, שבתורה עלולה ליזום קריאה ל- " git reflog expire " והפקודה הזאת באמת מסתכלת על הקונפיגורציה gc.reflogExpireUnreachable

 

[חזי2003]

זה לא מה שאני מבין

אני מבין ש-auto אומר לבדוק האם הגיע הזמן להריץ את פעולות התחזוקה של gc (בדרך כלל כי ההערכה של מספר ה-loose objects במערכת עוברת גבול מסוים). אבל ברגע שההחלטה להפעיל את פעולו התחזוקה, גם prune יקרה. &nbsp Once housekeeping is triggered by exceeding the limits of configuration options such as gc.auto and gc.autoPackLimit, all other housekeeping tasks (e.g. rerere, working trees, reflog…) will be performed as well. https://git-scm.com/docs/git-gc