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

בתרגיל status נכתב:

תחת הכותרת 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?
האם הם נשארים או נמחקים?

למה? אם עשית commit ועדיין לא עשית add, אין סיבה שיהיו קבצים ב־changes to be committed.

לא, הם נשארים, זה כתוב במפורש כאן:

• קבצים שמופיעים תחת הכותרת Untracked files: לא ישונו – הם ישארו כמו שהם, והקבצים שלצידם יוחלפו או יווצרו.

אז כנראה שלא הבנתי עד הסוף נכון, אשמח לאישור:
(1) Changes to be committed - מכיל את כל הקבצים שנמצאים ב-staging_area
(2) Changes not staged for commit - מכיל את כל הקבצים שנמצאים גם בתיקייה המקורית וגם ב-staging_area, אבל התוכן שלהם שונה.
Untracked files - מכיל את כל הקבצים שנמצאים בתיקייה המקורית אבל לא ב-staging_area, שזה למעשה מה שמופיע ב(1) אבל לא ב-(2)

כאן יש טעות: Changes to be committed מכיל רק את הקבצים ששונו מאז ה־commit האחרון, ונוספו ל־staging_area בעזרת add.

כן, התוכן שלהם ב־staging_area אינו תואם לתוכן שלהם בתיקייה המקורית.

נכון.

לפי מה שאתה מתאר, פקודת commit צריכה למעשה למחוק את תיקיית staging_area אחרי ביצוע מוחלט, כדי שנוכל לעקוב אחרי קבצים חדשים שנוספו מאז ה commit האחרון…

לא, זה לא מה שאמור לקרות.

אז משהו לא ברור לי ב flow הנדרש.

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

הפלואו הבעייתי:

1. בעת add הקבצים והתיקיות מועתקים בשלמות לתייקית staging_area.
2. בעת commit כל הקבצים שבתיקייה staging_area מועתקים ל commit_id, ותיקיית staging_area לא מתאפסת.
3. בעת 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.

אני עדיין לא מבין למה לא למחוק את תיקיית staging area אחרי commit מוצלח. זו הדרך הכי קלה לעקוב אחרי כל add חדש.

כי אז יהיה לך לא נעים לעשות wit commit, והוא יהפוך לפקודה מורכבת שתכיל לוגיקה של איחוד בין ה־staging_area לבין התיקייה המקורית.
מה יקרה ב־commit שבו יש לך בתיקייה המקורית 3 קבצים, 2 מהם נערכו, ועשית add רק לאחד מהם? באיזו לוגיקה תשתמש כדי להחליט אילו קבצים לשמור ב־image?

רק מה שעשיתי לו add מקבל גיבוי. איך זה שstaging_area נשאר יעזור להחליט איזה מהקבצים לשמור?

כאן הפער: זה לא נכון. כל מה שב־staging_area מקבל גיבוי.
קרא שוב את התרגיל של commit.

7 פוסטים פוצלו לנושא חדש: על git status וההתכתבות של git commit איתו

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

1. לא מצאתי מודול שמבצע את הסריקה הזו או לממש אותה - לא ראיתי שדיברנו על רקורסיה לאורך הקורס. מצאתי את מודול filecmp שמתקרב לזה אבל רק מדפיס את ההשוואה ולא מחזיר משהו.
2. מודולים קיימים שמשווים בין קבצים בתיקיות, כן מצליחים להראות שינוי בין קבצים אבל לא מצליחים להראות שינויים על קובץ חדש שנוסף.
3. בנוסף האם עלינו לשמור את הנתיבים לתיקיות המקוריות מהן הועתקו הקבצים (לצורך סעיף 3)? הם עשויים לבוא ממקומות שונים במחשב וזה מוסיף עוד טבלה או רשימה שצריך לעדכן

אני בסופו של דבר השתמשתי בfilecmp, בתוך פונקציה כדי לקבל את תת התיקיות.
אני עדיין מממש את זה אבל יש לי כיוון די טוב כבר.

לא חייבים לממש באמצעות רקורסיה, יש פתרונות אחרים

האם האשכול ההרחבה על פקודת add עוזר?

“…תחת הכותרת Changes to be committed יבואו כל הקבצים שעשו להם add, שישונו ב־commit הבא. ההבדלים בין HEAD לבין staging_area, בגדול”.

בהקשר לסעיף הזה-במידה ועשו add לתיקייה שלמה עם קבצים ותתי תיקיות, אני אמורה להראות תחת הכותרת את שם התיקייה הראשית כי כולה כביכול גובתה מחדש או את שמות כל הקבצים שבתוכה ובתוך התיקיות שבתוכה?

את שמות כל הקבצים שבתוכה ובתתי תיקיות שבתוכה

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

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

תודה מראש!

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

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