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

כאמור, אין פה בעיה.

אתה אמור לרוץ על הקבצים ב־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
אוסיף את זה מפורשות לתרגיל.

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

ה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.

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