שאלת הבנה בנוגע ל-status ו-checkout

היי,
מקווה שזה בסדר שאני רושמת בהמשך לשרשור הזה ולא בשאלה חדשה (לי אישית זה עזר שכל השאלות על הפונקציות הללו הן בשרשור אחד :))

אני מבינה למה לא למחוק את staging_area אחרי commit מוצלח. אבל למה לא למחוק אחרי שעושים checkout?
אחרי שעשיתי checkout נשארתי ב-staging_area עם כל הקבצים הקודמים שמאוד לא תואמים ל"תיקייה המקורית" (זו שמכילה את wit.).
אם בכל זאת התשובה היא שלא מוחקים אחרי checkout, מה אני אמורה לעשות עם כל השוני שיש בין התיקייה המקורית וה-staging_area? (לעשות commit שוב ייצור תמונה של תיקייה מעורבבת )
יכול להיות שפספסתי משהו מהותי בהוראות. בכל מקרה, אשמח להבהרה.

תודה מראש!

היי, ב־checkout את צריכה לעדכן את staging_area כך שיהיה תואם ל־HEAD
אוסיף את זה מפורשות לתרגיל.

בנוגע לשרשור האחד – שימי לב שהשאלות מתויגות, ואפשר ללחוץ על התיוג כדי להגיע לכל השאלות שנפתחו לגבי תרגיל מסוים.

הstatus עובד עם Head הנוכחי.
מה בדיוק אמור לקרות כשהcommit_id המתקבל עם הפקודה checkout, שונה מHead?
האם קודם כל הHead מתעדכן לcommit_id החדש ואז מתבצעת הבדיקה עם status (והcheckout יקרה רק אם באמת אין קבצים בchanges to be commited וכו’)
או שזה לפי הסדר שכתוב בשאלה. בודקים עם הstatus של Head. עושים checkout ויהי מה (כי הקבצים בתיקייה commit_id יכולים להיות ממש לא קשורים למצב עכשיו בstaging-area ) ואז מעדכנים את head ואת staging_area בהתאם ?

חוץ מזה הבהרה לגבי master , הוא פשוט תמיד מצביע על ה commit_id האחרון שנוצר ?

ה־status משווה בין המצב ב־staging_area לבין המצב בתיקיית העבודה כרגע, ובין staging_area ל־HEAD.

1. בדיקה של status, ממשיכים לסעיף 2 רק אם הוא לא מכיל Changes to be committed או Changes not staged for commit.
2. מעדכנים את התיקייה המקורית כך שתכיל את הקבצים מ־image
3. מעדכנים את HEAD בהתאם
4. מעדכנים את staging_area

עבודה בצורה הזו היא בעייתית – המטרה של הבדיקה מול status היא לבדוק שלא נדרסים בטעות קבצים שעשו בהם שינויים, וככה נאבד עבודה שעשינו.

לא, תחשוב על מצב כמו:
wit init
wit add a
wit commit
(נוצר 000000, ה־master עליו)
wit add b
wit commit
(נוצר 111111, ה־master עבר אליו)
wit checkout 000000
(אנחנו על 000000, ה־master עדיין על 111111)
wit add c
wit commit
(נוצר 222222, ה־master עדיין על 111111)

מה קורה לגבי קבצים שעברו עריכה ולא נוספו בadd וקבצים או ספריות שנמחקו?
הם יופיעו ב Changes to be commited וב־Changes not staged for commit גם אחרי commit.

אין צורך לתמוך במחיקת קבצים (אבל אפשר אם מאוד בא לך).

בנוגע לעברו עריכה ולא נוספו ב־add – הם יופיעו ב־Changes not staged for commit.
צריך לעשות להם add לפני, אחרת ה־checkout יכשל.

ב Changes to be commited לא יופיעו גם הקבצים שעברו עריכה אחרי ההוספה?

אם לא מתבצעת המחיקה, במידה ומחקו קובץ או תיקייה הם תמיד יישארו ב Changes not staged for commit ולא יהיה ניתן לעשות checkout.
או שפספסתי משהו.

עניינת אותי מאוד

עדיין לא מצאתי דרך יפה שלא משתמשת ברקורסיה ומתחשבת בכל התיקיות הפנימיות

הם כן, אבל רק אם עשו להם add, לא עשו commit, ערכו, ואז לא עשו add ולא commit.

לא הבנתי כ"כ, אבל אני אחדד: לא צריך להתחשב במקרים בהם המשתמש מוחק קבצים כרגע.

סבבה. ראיתי את התגובה שלך בשאלה אחרת וממשתי לפי זה.

שאלת הבנה בנוגע לchanges not staged for commit:

מתחת לכותרת הזו בעצם יופיעו שמות הקבצים שעשו להם add לstaging_area , ולאחר הadd הקבצים הללו שונו בתיקייה המקורית? (שממנה מעתיקים).

“אבל התוכן שלהם שֻׁנָּה מאז ה־commit האחרון ומאז שהתוכן שלהם שֻׁנָּה לא עשו להם add.”
בעצם פעולת הcommit לא ממש קשורה לכותרת הנ"ל אם הבנתי נכון לכותרת הזאת:
סה"כ תחת הכותרת הזו יופיעו שמות הקבצים שהשתנו אבל בcommit הבא שינויים אלו לא יגיעו לתיקיית images בגלל שעדיין לא נעשה add עליהם. (השינויים עליהם בתיקייה המקורית נעשו לאחר שעשו add).

כן

נכון, הם לא הוספו מחדש ל־index. הקבצים האלו ישמרו ב־image הבא, אבל לא בגרסה העדכנית שלהם.
(אלא בגרסה הישנה שנשארה ב־staging_area מ־add קודם)

מקווה שלא פספסתי את זה באחד השרשורים -

לגבי changes not staged for commit, האם הרשימה צריכה לכלול גם תיקיות שתכולתן השתנתה או רק קבצים שתוכנם השתנה?

רק קבצים

קצת הקשיתי על עצמי פה וכללתי גם תיקיות בchanges not staged for commit ובuntracked_files, בגלל מקרים של תיקיות ריקות ללא קבצים… האם בסדר להשאיר כבר כך?

כן, אין בעיה

לגבי checkout ו-Untracked files - האם זה הגיוני שבמימוש שלי של checkout לא באמת צריך ללכת לבדוק מה יש תחת רשימת הקבצים הזו (כלומר תכלס לא צריך להשתמש ב-status ולקחת ממנו את הרשימה), מכיוון שהפעולה פשוט “לא נוגעת” בקבצים בתיקיה המקורית שלא נמצאים ב-committed_id? או שאני מפספסת משהו?

מה אם בתיקייה המקורית הקבצים שונו ואת דורסת אותם?

לא בטוחה שהבנתי. נניח שאני רצה על תיקיית הגיבוי commit_id, בודקת כל קובץ בה בהשוואה לתיקיה המקורית, דואגת ליצור כל קובץ שלא קיים בתיקיה המקורית, ולהחליף כל קובץ שאני מזהה שקיים בתיקייה המקורית (אלא אם מדובר בתיקייה, שבמקרה שלה צריך להיכנס לעשות את הבדיקה בצורה רקורסיבית).

במקרה הזה באיזה תרחיש אני דורסת קבצים ששונו? אם קובץ שונה ולא הועלה בגרסה העדכנית ל-staging area או שלא בוצעה לאחר מכן הפעולה comit, הפעולה checkout בכלל לא אמורה לרוץ - לא?

נכון, זו בדיוק הנקודה – היא אמורה לא לרוץ כדי למנוע מצב לא נעים של איבוד מידע.
השימוש ב־status הוא כדי להבין מתי היא אמורה לא לרוץ