תחת הכותרת Changes to be committed:, יהיו קבצים שעשינו להם add והם יתווספו לתיקייה חדשה ב־images בפקודת ה־commit הבאה.
בסופו של דבר, כל הקבצים שנמצאים ב-staging_area יתווספו ב-commit הבא כל עוד היה שינוי מהגיבוי האחרון (במידה והתווסף קובץ לא קיים, או התווסף קובץ שעבר שינוי).
בתרגיל checkout נכתב:
כדי לא לאבד מידע, הפקודה תכשל ולא תתחיל לרוץ אם יש קבצים שמופיעים ב־ wit status תחת הכותרת Changes to be committed: , או תחת הכותרת Changes not staged for commit: .
אבל יופיעו תמיד קבצים תחת changes to be committed (לפי ההסבר למעלה), אלא אם changes to be committed הוא למעשה האיחוד של changes not staged for commit ו- untracked files.
השאלה בסופו של דבר:
האם changes to be committed הוא האיחוד של שניהם, או כל הקבצים המופיעים בתיקיית staging_area לפי ההסבר למעלה?
שאלה נוספת:
מה קורה לקבצים שלא נמצאים ב-staging_area ולא ב-images אחרי שמבצעים את הפקודה checkout?
האם הם נשארים או נמחקים?
אז כנראה שלא הבנתי עד הסוף נכון, אשמח לאישור:
(1) Changes to be committed - מכיל את כל הקבצים שנמצאים ב-staging_area
(2) Changes not staged for commit - מכיל את כל הקבצים שנמצאים גם בתיקייה המקורית וגם ב-staging_area, אבל התוכן שלהם שונה. Untracked files - מכיל את כל הקבצים שנמצאים בתיקייה המקורית אבל לא ב-staging_area, שזה למעשה מה שמופיע ב(1) אבל לא ב-(2)
(אני מבין את ההיגיון הבסיסי שאומר שאם עשינו add לקובץ זה אומר שזה קובץ שאנחנו רוצים לגבות עכשיו, וגם כנראה בעתיד, ואנחנו לא רוצים כל פעם לעדכן את הרשימה.
אבל אנחנו בכל מקרה מתעסקים עם הקבצים עצמם שמועתקים ולא עם פוינטרים, אז כל פעם חייבים להוסיף ל add אחרי כל עריכה של הקובץ במיקומו המקורי… אז למה לא למחוק?)
הפלואו הבעייתי:
בעת add הקבצים והתיקיות מועתקים בשלמות לתייקית staging_area.
בעת commit כל הקבצים שבתיקייה staging_area מועתקים ל commit_id, ותיקיית staging_area לא מתאפסת.
בעת status אני צריך להציג את כל הקבצים שעשינו להם add וטרם עשו commit. כיוון שאני לא שומר בצד את “רשימת ה add” האחרונים", ולא ערכתי קבצים כדי לסמן האם עשו commit… יש פה בעיה
אתה אמור לרוץ על הקבצים ב־staging area ולבדוק האם התוכן שלהם שונה מהקבצים בתיקייה המקורית.
אם עשית wit add ואז שינית את הקובץ, השינוי שנעשה אחרי wit add לא אמור להכנס ל־staging area ולא אמור להיות משוקף ב־commit הבא.
אם עשית commit ומיד אח"כ status, אתה אמור להציג 0 קבצים ב־Changes to be commited וב־Changes not staged for commit.
כי אז יהיה לך לא נעים לעשות wit commit, והוא יהפוך לפקודה מורכבת שתכיל לוגיקה של איחוד בין ה־staging_area לבין התיקייה המקורית.
מה יקרה ב־commit שבו יש לך בתיקייה המקורית 3 קבצים, 2 מהם נערכו, ועשית add רק לאחד מהם? באיזו לוגיקה תשתמש כדי להחליט אילו קבצים לשמור ב־image?
ניסיתי למצוא דרך לעבור על כל התיקיות באופן רקורסיבי לצורך ההשוואה אבל אני נתקלת במספר קשיים:
לא מצאתי מודול שמבצע את הסריקה הזו או לממש אותה - לא ראיתי שדיברנו על רקורסיה לאורך הקורס. מצאתי את מודול filecmp שמתקרב לזה אבל רק מדפיס את ההשוואה ולא מחזיר משהו.
מודולים קיימים שמשווים בין קבצים בתיקיות, כן מצליחים להראות שינוי בין קבצים אבל לא מצליחים להראות שינויים על קובץ חדש שנוסף.
בנוסף האם עלינו לשמור את הנתיבים לתיקיות המקוריות מהן הועתקו הקבצים (לצורך סעיף 3)? הם עשויים לבוא ממקומות שונים במחשב וזה מוסיף עוד טבלה או רשימה שצריך לעדכן
“…תחת הכותרת Changes to be committed יבואו כל הקבצים שעשו להם add, שישונו ב־commit הבא. ההבדלים בין HEAD לבין staging_area, בגדול”.
בהקשר לסעיף הזה-במידה ועשו add לתיקייה שלמה עם קבצים ותתי תיקיות, אני אמורה להראות תחת הכותרת את שם התיקייה הראשית כי כולה כביכול גובתה מחדש או את שמות כל הקבצים שבתוכה ובתוך התיקיות שבתוכה?
היי,
מקווה שזה בסדר שאני רושמת בהמשך לשרשור הזה ולא בשאלה חדשה (לי אישית זה עזר שכל השאלות על הפונקציות הללו הן בשרשור אחד :))
אני מבינה למה לא למחוק את staging_area אחרי commit מוצלח. אבל למה לא למחוק אחרי שעושים checkout?
אחרי שעשיתי checkout נשארתי ב-staging_area עם כל הקבצים הקודמים שמאוד לא תואמים ל"תיקייה המקורית" (זו שמכילה את wit.).
אם בכל זאת התשובה היא שלא מוחקים אחרי checkout, מה אני אמורה לעשות עם כל השוני שיש בין התיקייה המקורית וה-staging_area? (לעשות commit שוב ייצור תמונה של תיקייה מעורבבת )
יכול להיות שפספסתי משהו מהותי בהוראות. בכל מקרה, אשמח להבהרה.
)