תזהרו משינוי ההקשר בgitk מ 3 שורות לשורה אחת, זה מטעה בטרוף

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

ב gitk  יש דרך לשנות את ההקשר (מספר השורות שמוצגות), מכיוון שהייתי קצת עצלן שיניתי את ההקשר לשורה אחת, הרי גם ככה אני עושה git add -p בשביל לברור קומיטים ברמת השורה, אז קל יותר לראות את הינויים.

היה לי איזה באג שהיתי צריך לתקן, והפעלתי gitk עם שורה אחת, הפלט שראיתי היה : 

index 4e92ce88879..be1c749241f 100644
--- a/x/y/filesystem/remote_fs.cpp
+++ b/x/y/filesystem/remote_fs.cpp
@@ -10219,7 +10219,7 @@ file_state_t __update_inode(
-          permission_t * &         r_permission,
+    const permission_t * &         r_permission,

אני מסתקל בקוד ,מתקן ועדיין יש חתיכת תקלה, לאחר 20 דקות שאני שובר את הראש אני פונה לעמיתי, יש לנו כלל בחברה, שאם אתה תקוע מעל 20 דקות על משהוא אתה חייב לפנות לעוד זוג עיניים, ולא הברווז לדיבוג זה לא שווה.

 

הוא מסתקל, ואומר , רגע אם אני מבצע checkout לשינוי הזה הפונקציה הזאת לא השתנתה כלל ! 

 

 אז אני מפעיל git show שבו יש הקשר גדול יותר, ומה אני רואה ? 

index 4e92ce88879..be1c749241f 100644
--- a/x/y/filesystem/remote_fs.cpp
+++ b/x/y/filesystem/remote_fs.cpp
@@ -10219,7 +10219,7 @@ file_state_t __update_inode(
  file_state_t  __create_link(
     const   char         * pt_calling_source_file,
     const   unsigned int   calling_line_number,
-          permission_t * &         r_permission,
+    const permission_t * &         r_permission,

למרות שהפונקציה שהשתנתה היא __create_link הוא היה מציג את הפונקציה __update_inode.

עזבו את ה GUI לנפשו

פוסט זה מסכם עשרות ימי תמיכה במשתמשי git ו subversion שנתקלו בבעיות עם ה VCS שלהם. 

יותר מדי אנשים בוחרים היום להשתמש בכלי gui  ומעטפות על git ו subversion , בעוד כלי ה gui יכולים להראות פתרונות מדהימים להכל, וFoolproof בכל יום תמיכה אני מגלה עוד ועוד דברים שמראים שהם לא מתאימים לכל דבר.

במקרה הפשוט של git למשל (כנראה מערכת ה VCS הפופלארית ביותר שקיימת ) :

בחלק מהממשקים הגרפים (למשל Tortoise ו github desktop ) אין הצגה למצב של deatched head , אנשים שוכחים לבודק ידנית על איזה branch הם נמצאים והופ הם תקועים ולא יכולים לעשות push וצריך לבצע מעבר ידני (ב git bash ) . 

אם אנחנו עובדים ב git ללא submodules , הסיכויי שלכם במסלול תקין להגיע ל deatched head ללא כוונה שואף לאפס (זה לא המצב כשיש שגיאות או שימוש רצויי בו אתם רוצים להגיע ל deatched head). 

במצב גרפי ? הסיכוי שלכם להבין שאתם נמצאים ב deatched head ללא התראה כמעט לא קיים (קיימת אזהרה ב tortoise git שמציעה לכם לעבור ל branch חדש אבל זה ממש לא ברור).

עובדים עם submodules ? בהכרח אתם תהיו במצב של deatched head כי זה המצב התקין , הבעיה בכלי הממשק הגרפי שמשתמשים לא ישימו לב , ויעשו commit ב deatched head או במקרה הטוב ייצרו branch חדש ואחרי זה יינסו לתקן (והנה 10 -20 דקות שהלכו לאיבוד)

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

git submodule update --merege --remote --recursive  ולא git pull --recurse-submodules

עושים זאת כי תמיד יש סיכויי שאיזה submodule עבר עידכון אבל הsubmodule העליון לא עודכן . בכלים כמו toritoisegit ו github desktop אין אינדיקציה ברורה לפעולה הזאת (או יכולת להבדיל ביניהן).

הייתה שגיאה ב rebase , וזה קורה הרבה במיוחד כאשר מקבלים early EOF במהלך pull כשאר המערכת מוגדרת לבצע rebase כברירת מחדל.

רוצים לעבוד בצורה רגועה , בלי לחץ ועם סיכוי נמוך לעשות טעויות ? תעבדו ב command line.

איך להציל ולהעביר היסטוריה בין מאגרים שונים בgit לפי מסלול ?

פנו אלי בבקשה לגבי להעביר היסטורי של מסלול (path) למאגר שונה בצורה פשוטה , פעם הייתי ממליף על filter-branch הייפה והטוב , אבל היום יש לנו את git filter-repo שהוא הרבה הרבה הרבה יותר מהיר.

הפתרון תקף גם ל מאגר רגיל וגם לתת מאגר (submodules) אבל זה פחות מתאים לsubtree.

הפתרון שמצאתי שהוא הזול ביותר מבחינת משאבי רשת :

שימוש ב git bundle בשביל להעתיק את המאגר המקומי , למסלול אחר.

שימוש ב git filter-repo בשביל להעתיק את ההיסטוריה של המסלול הזה לענף (branch) בפני עצמו.

 הוספת remote למאגר אשר לתוכו צריך להוסיף את ההיסטוריה , ה remote הוא למקום בו עשינו clone מה  bundle (שזה מסלול מלא).

ביצוע fetch ל ענף שייצרנו במהלך העתקת ההיסטוריה.

ביצוע merge

ביצוע push

ובא לציון גואל.
 

חומר להעתק / הדבק  כמובן שיש להתאים לצורך שלכם :

How to transfer history between two repositories, or a super repository to it's submodules.

in my case, I'm extracting the history of the path 
"engine/C87AOP"

    1. Prepare a bundle to clone a repository, which will be used for git filter-repo later
    
    cd ~/git/source_repo
    mkdir ~/git/working_dir
    git bundle create ~/git/working_dir/C87.bundle master
    
    2. Clone from the bundle file:

    cd ~/git/working_dir/

    git clone -b master ./C87.bundle
    
    3. Extracting only C87AOP history by using git filter repo:
    
    git checkout -b C87AOP_ENGINE

    git filter-repo --path engine/C87AOP --refs C87AOP_ENGINE --force
    
    4. adding a remote on destination repo to ~/git/working_dir
    
    cd ~/git/dest_repo
    git remote add local file:///home/user/git/working_dir/C87/
    
    5. fetching the branch C87AOP_ENGINE from the remote local we added on step 4

    git fetch local C87AOP_ENGINE
    
    6. creating a new working branch locally
    git checkout -b merging_history_from_c87
    
    7. merging the branch C87AOP_ENGINE with local brnach

    git merge local/C87AOP_ENGINE  --allow-unrelated-histories

    8. git checkout master
    9. git merge merging_history_from_c87
    10. git push origin master
    11. git branch -d merging_history_from_c87
    12. git remote remove local
    13. rm -rfi /home/user/git/working_dir
  

git reflog

לידידי הייתה בעייה קטססטרופלית עם git לפני מספר ימים , הוא ביצע rebase היה קונפליקט בחר לבצע skip ואז abort והבין שהופ  והמידע שלו נעלם מהענף עליו עבד.

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

אני מאמין שבעיות כאלה יכולים לקרות לכל אדם אז כככל אני ממליץ את צורת עבודה :

• מבצעים pull על ה master
• עוברים לענף פיתוח git checkout -b something_usefull ועודבים בתוכו
• חוזרים לענף ה master מבצעים pull
• חוזרים לענף הפיתוח ומגבים את ענף הפיתוח :
  git checkout -b something_usefull_backup_rebasing
• מבצעים rebase master
• חוזרים ל master ומבצעים git merge something_usefull_backup_rebasing
• מוחקים את ענף הפיתוח והגיבויי:
  git rebase -D something_usefull_backup_rebasing
  git rebase -D something_usefull
  

לצערי ידידי לא הקשיב לי (אבל אני עובד עם PRs ! לא צריך את צורת העבודה הזאת )  וחשב כי איבד את עבודתו , בשביל להציל את המידע אנחנו משתמשים בכלי המדהים שנקרא reflog , ולדעתי כל אדם שעובד עם git חייב להכיר את הכלי הזה.

בשביל להציל את המידע אנו מפעילים git reflog ומוצאים את ה hash לפני rebase, לקחתי דוגמה מהצלה אחרת אבל בה היה מקרה דומה (גם שם יש עבודה לא נכונה כפי שרואים) :

7d8e22cc631 (HEAD -> nieuwe_maas, origin/master, origin/HEAD) HEAD@{0}: rebase (skip) (finish): returning to refs/heads/nieuwe_maas
7d8e22cc631 (HEAD -> nieuwe_maas, origin/master, origin/HEAD) HEAD@{1}: pull origin master (start): checkout 7d8e22cc63117d3667c3490a9910850c2690e6d3
606fb656349 HEAD@{2}: rebase (abort): updating HEAD
7d8e22cc631 (HEAD -> nieuwe_maas, origin/master, origin/HEAD) HEAD@{3}: pull origin master (start): checkout 7d8e22cc63117d3667c3490a9910850c2690e6d3
606fb656349 HEAD@{4}: commit: Correct IPv6 route handeling
089c98cb217 HEAD@{5}: checkout: moving from rotterdam to nieuwe_maas
ee8d88108d3 (rotterdam) HEAD@{6}: rebase (skip) (finish): returning to refs/heads/rotterdam
ee8d88108d3 (rotterdam) HEAD@{7}: pull origin master (start): checkout ee8d88108d3964731d423d2b7ad36ae8860f6970
089c98cb217 HEAD@{8}: rebase (abort): updating HEAD
ee8d88108d3 (rotterdam) HEAD@{9}: pull origin master (start): checkout ee8d88108d3964731d423d2b7ad36ae8860f6970
089c98cb217 HEAD@{10}: commit: BUGFIX: null derefernece

הקומיטים שנעלמו לנו היו 606fb656349 ו 089c98cb217 בשביל להציל את הקומיט הזה מספיק לעשות :

git checkout -b sos_rescue 606fb656349 , כי לפי ההיסטוריה פה (ובבדיקה) הקומיטים נמצאים אחד אחרי השני.

ענף הפיתוח החדש sos_rescue יכיל את מה ש"נעלם" מההיסטוריה שלנו.

אותה הבעייה יכולה להתקיים גם עם git rebase --abort , שם המצב מפחיד בהרבה כי בדר"כ לא מצפים ש abort יוביל לאיבוד מידע ולא חזרה להתחלה.

לדעתי כל אדם שמתחיל לעבוד עם git חייב לעבור על כל הפעולות תחת docs, יש שם דברים שבהתחלה יכולים לחשוב שזה לא חשוב או לא תשתמשו בהם , אבל כל אחת מהסעיפים שם תציל אותכם אחרי זה.

 

לצערי גם git reflog הוא לא חסר מבעיות , ולמעשה אחת הבעיות המובנות שאני סובל מהם קשות זה ש reflog שומר רק שלושה חודשים ואני מוצא את עצמי מגבה את תיקיית ה .git אחת לחודש כי כל פתרונות הגיבוי שאני מכיר לוקים בחסר אבל זה כבר סיפור אחר.

Github Desktp Can't locate repository last seen on ...

 GitHub Desktp שהרבה מעמיתי עובדים עימו, נכשל לעבוד עם מאגר שעבר clone.

 

אדם היה בוחר תיקייה , התוכנה מראה את תוכן המאגר והכל נראה תקין, אבל אם סוגרים את ה GitHub Desktop , התוכנה הייתה מקבלת את פניך עם השגיאה :

Can't locate repository last seen at ...

לחיצה על locate מחזירה למקום וזה היה נראה שהכל עובד, אבל אתחול של התוכנה היה מחזיר את התוכנה למצב בו היתה מבקשת ממך לאתר את ה repository.

חיפוש זריז בלוגים גילה שיש באג בתוכנה שאם הפלט של git status מעל 19.0734 מ"ב , התוכנה היתה נכשלת אבל לא מציגה את המידע למשתמש. כן אפילו בימי ה type script העליזים חזרנו לבעיות של הקצאת זכרון לתוכנה.

הפתרון ?

שימוש ב .gitignore שיכיל כל אחת  מהתיקיות אותן git status מדווח כ untracked(במקום לבטל קבצים בודדים).

אז למה אני לא מדווח את הבאג ב issues של התוכנה  ולא שולח תיקון ל GitHub Desktop ?

כי זה לא באמת תוכנה ברישיון MIT  ויש לזה אפילו EULA. 

 
למי שמאמין בטענה כי מדובר בתוכנה ברישיון MIT צריך לקרוא את ה Readme שלהם או לבקר באתר.   קוד המקור אולי (?) באמת מופץ ברישיון MIT , אבל הבינארי לא (לפי מה שכתוב באתר שלהם) , וגם אי אפשר לפתוח באגים (כי יש עוד רישיון בשביל לפתוח באגים).

אני ממש לא עורך דין , אבל אני לא מאמין שתוכנה יכולה להיות גם מצד אחד ברישיון MIT וגם מצד שני להכיל הסכם EULA שמגביל את אופן השימוש בתוכנה (שזה אחד הסעיפים ב רישיון MIT).

לצד הטכני יותר : 

קיימת תיקיית לוגים במיקום :

%APPDATA%\Github Desktop\logs\ 

ושם אני מגלה את היופי הבא:

 

2020-09-23T19:29:15.843Z - error: [ui] 'git status' emitted 43812700 bytes, which is beyond the supported threshold of 20000000 bytes

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

ולפני שאנשים באים ואומרים זה המשתמשים שלא משתמשים כנון ב gitignore והם היו צריכים לחשוב על זה אני אומר שיש די הרבה כלים שלא היו מתנהגים ככה , ואלו שלא מסוגלים לתמוך לפחות מזהירים אותך מזה.

RIP Cloudforge

היה שלום ספק יקר, קלאודפורג' (cloudforge) שעבדתי איתו מימי ה CollabNet העליזים סוגר את שעריו לאחר מעבר לבעלות אחרת. 

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

אבל כמו כל דבר טוב יום אחד הם נרכשים ע"י חברה גדולה יותר.

היה שלום חבר , ותודה על הדגים.

איך לבצע ניגון של הרבה פאטצים ב git

לפני מספר חודשים התחלתי לעבוד על קובץ מסויים תחת git-svn אתמול גיליתי שמה שאני צריך זה לא לדחוף אלא לבצע fork שלם, אבל אני מבין שאני צריך את כל ההיסטוריה שלי.

git לא שומר שמות קבצים אלא עץ מצב לכן לא הצצלחתי לחשוב על דרך ב אוכל להזיז היסטוריה (התחלתי מ svn cp source dest בשביל שההיסטוריה תשמר בשרת).

המחשבה הראשונה היתה לעשות:

boris@pc /c (case_0x567823_devil)
$ git format-patch master

ולאחר מכן שינוי יידני של כל פאטץ יצירת ענף חדש ואז git am רק שקיבלתי שגיאות של patch does not
 apply
 שזה משהוא לא ממש הגיוני אני עובד על אותה המכונה (השגיאה יכולה לצוץ עם בעיית הרשאות למשל)

שברתי את הראש וכמעט אמרתי נואש ואז מצאתי שמישהוא הציע אולי הבעיה בכלל בwhitespaces או רווחים.

וזה היה הפתרון!

התהליך שעשיתי היה :

boris@pc /c/src/ (case_0x567823_devil)
$ git format-patch master

קיבלתי כמה עשרות קבצים(קובץ עבור כל commit שנעשה), שיניתי בכל אחד מהם את שם הקובץ הישן והפורק

:%s/source.cpp/dest.cpp/g  

לאחר מכן הפעלתי את קסמי ה git:

boris@pc /c/ (case_0x567823_devil_newbranch)
$ git am 0*.patch --ignore-space-change --ignore-whitespace

ובא לציון גואל

למידע נוסף
git am
git format-patch

וחיו git ו svn ביחד

 יש לי התקנה שהיא יחסית נדירה, אני משתמש במספר מערכות ניהול גירסאות על המחשב שלי בו זמנית.
יש לי גם ניהול גירסאות מבוסס svn וגם ניהול גירסאות מבוסס git-svn, והחלק הבעייתי באמת מדובר על מספר גיגה בייתים של מידע תחת svn.

בפעם הראשונה שמנסים לעשות clone מגבלים שgit יוצא ללא שגיאה ומה שרואים היינו:

git svn clone -s https://ip/svn/project/trunk_name local_repo

rXXXXX = 231876121242148168246 (refs/remotes/git-svn)

אם ניכנס לתיקיה local_repo נראה שאין קבצים פרט לתיקיית .git, על מנת לפתור את הבעיה הזאת יש להריץ git svn fetch מתוך התיקייה שנוצרה ע"י git svn.
בחלק מהמקרים נאלצתי להריץ ידנית fetch עוד עשרות פעמים עד ש git הואיל בטובו להוריד את כל הפרוייקט, מדי פעם עדיף להריץ גם git gc (אחת ל 1000 גירסאות הספיק לי .


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

fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
   Use '--' to separate paths from revisions
   log --no-color --no-decorate --first-parent --pretty=medium HEAD: command returned error: 128

הפתרון לבעיה זו הוא להשתמש ללא -s ולכוון ל svn trunk שצריך דוגמה :

git svn clone https://ip/svn/project/trunk_name/ local_repo

טוב בשעה טובה ומוצלחת הצלנו לעשות clone לפרוייקט הגדול שלנו איך ניתן לו לחיות ביחד עם svn באותה התיקיה ?  שימו לב שזה מתכון לצרות - אבל גם ללמידה.

לוקחים את תיקיית ה git שנוצרה (יש רק אחת ומושכים אותה לתיקיה הראשונה שנוצרת לכם ע"י svn ,
לדוגמה:

/opt/svn/bfs_patches$ ls -la
total 7816
drwxr-xr-x 15 boris boris    4096 Jun 21 18:49 .
drwxr-xr-x  3 boris boris    4096 Jun 21 18:21 ..
-rw-r--r--  1 boris boris     174 Jun 21 18:24 .buildpath
drwxr-xr-x  3 boris boris    4096 Jun 21 18:24 docgenerator
drwxr-xr-x  9 boris boris    4096 Jun 22 00:47 .git
drwxr-xr-x  3 boris boris    4096 Jun 21 18:51 2.6.38-bfs
-rw-r--r--  1 boris boris     517 Jun 21 18:24 .project
drwxr-xr-x  3 boris boris    4096 Jun 21 18:24 .settings
drwxr-xr-x  6 boris boris    4096 Jun 21 20:15 .svn

הוספתי את התיקייה .git לתוך תיקיות שהיו תחת svn, השלב הבא הוא לזכור שבכל פעם שאנחנו משנים קבצים ע"י svn לעשות :

  git  reset --hard && git svn rebase

שימו לב זה יעיף את כל השינוים המקומים שלכם בgit.

למה אני עושה את זה - אני עובד עם הרבה מאוד תוכנות ותסריטים שדורשות עבודה עם svn ולא יודעות להתמודד עם git. לכן כאשר אני מסיים איתן אני מריץ reset וחוזר לעבוד עם git.