האם יש באמת סיבה למצוא את הא הכי קרוב לHEAD ול BRANCH_NAME?
שואל מאחר שאם משרשרים בסופו של דבר את ה commit החדש למיקום שHEAD היה בו אין באמת צורך לדעת מי ואיפה היה האב הכי קרוב?
לייק 1
עדכון: לא רלוונטי, ראו המשך השרשור.
למען האמת אתה צודק – לא חייבים. זה שם רק בשביל “הכנה למזגן” לפונקציות יותר מורכבות (נניח: לבונוס).
מימוש אפשרי אחר יהיה פשוט לוודא ש־staging_area ו־HEAD זהים, ואז להעתיק ל־staging_area את BRANCH_NAME ואז לעשות commit.
לייק 1
שאלת הבהרה נוספת באותה נקודה ממש.
התחבטתי באותה שאלה הגעתי למסקנה ראשונה שמספיק להשוות בין ה head (כביכול) לבראנצ’, אבל, אם יש קבצים שונים, אני לא בהכרח רוצה לדרוס אותם בהד,
אז אני כן צריכה את האב המשותף כדי להחליט בקבצים שונים בין הד לבראנצ , בשביל להחליט איזו משתי הורסיות האלו אני שומרת (לא?)
ולא מדובר על המצב שיכשיל את מרג’ בבונוס (כלומר עדיין רק אחת הגרסאות שונתה, רק שאם אני משווה בין שתי הגרסאות (בלבד) אני לא יודעת מי שונתה ומי לא
(סליחה מראש אם עשיתי סלט מהכל)
אני חשבתי על זה כמו המצב שקורה כשאת עושה צ’קאאוט ומעדכנת את התיקיה המקורית-
את רוצה שהתיקיה המקורית תיראה כמו הקומיט האחרון רק בלי שידרסו קבצים שלא היו בקומיט וכן היו בתיקיה המקורית. אז זה מקרה דומה- את רוצה שמה שיש בבראנץ’ יתעדכן בstaging area יחד עם מה שכבר יש בו ובלי לדרוס את מה שיש בו (head)
ככה אני עשיתי אבל אולי לא הבנתי נכון ועשיתי סלט בעצמי😂
אבל זה לא בדיוק בלי לדרוס - קבצים שהשתנו מאז ההורה המשותף האחרון רק בענף , כן צריכים לדרוס קבצים שלא השתנו בהד. אבל קבצים שלא השתנו בהד בענף, (אבל כן השתנו בהד) לא צריכים להדרס. זה לא טריוויאלי בעיני. (אפשרי, בהחלט, אבל לא פשוט) ודורש למצוא את האב המשותף (שגם יכול להיות קצת מאתגר, כי ייתכן שיש יותר הורה משותף אחד שגם מיד לפניו וגם מיד אחריו יש פיצול לאורך השרשרת)
סורי, ממש לא הצלחתי לעקוב.
התרגיל מוגדר כך שאין מצב שאותו קובץ השתנה בשני ה־branch־ים. זה עונה על השאלה?
לא.
מה קורה במצב הבא:
באב המשותף הקרוב ביותר יש שלושה קבצים: נסמן אותם בדרך הייחודית והמקורית : a b ו c
ב c לצורך העיניין לא נגענו. הד שינתה את a ל a’ ו בראנצ שינתה את b ל b’.
עכשיו יש לנו ככה : תחת האב האחרון: a b c
תחת הד ( ובהנחה שהד זהה לסטייג’ גם בסטייג’): a’, b, c
ובענף: a, b’, c
לדעתי המרג’ צריך ליצור: a’, b’, c
אבל הנחות ללא התחשבות באב הקדמון יצא לנו a, b’, c (ואז למה עבדנו כ’כ קשה עד עכשיו בעצם).
או שיש משהו שלא הבנתי.
עריכה: ייתכן שכן יש דרך להתמודד עם זה ע’י שימוש בזמן יצירת הקבצים, אבל זה לא עושה את זה פשוט יותר בעיני
עריכה 2 : אני יכולה לחשוב על מלא מקרים שההצעה בעריכה לא תפתור
4 לייקים
הסבר מעולה. עם ה abc.
הסיטואציה היחידה שאני מצליחה לחשוב עליה שבה ניתן לדרוס את הקבצים ב staging area היא כאשר ב BRANCH_NAME ישנם רק הקבצים שהשתנו מאז האב המשותף.
האם באמת זה המצב?
תודה על הפרמול, ממש עזר לי להבין.
חשבתי על זה קצת ונשמע שאת צודקת והתשובה שנתתי קודם לא נכונה.
מי שמימש את זה כבר ככה עד נקודת הזמן הזו – לא אתעקש על זה.
מי שלא – עקבו בבקשה אחרי ההדרכה בפוסט המקורי, זו הצורה הנכונה לממש את זה.
לייק 1
ממליצה שתמחק את התשובה שכתבת שזה אפשרי, לא כולם ירדו עד התגובה האחרונה כדי לוודא שהיא בטלה ומבוטלת.
או לכל הפחות, תוסיף הערה למעלה שהתשובה לא רלוונטית.
אני חושב שכן, אבל אני ממליץ למצוא מימוש גנרי ולא לפרק לתתי מקרים.
נראה לי שהתייחסות לכל תת מקרה במיוחד תסבך את זה ותהיה מתכון להרבה באגים במקרי קצה
ערכתי, תודה
לייק 1