Παιχνίδι 2048 σε C

[imitheos]

Και μη φοβάσαι ρε συ, we 'll always have imitheos!

Σωστά, εγώ κλέφτης θα γίνω άλλωστε ? Κάπως πρέπει να πληρώσουμε και τον ενφια που ήρθε τώρα.

 

Επιδιορθώσεις και μερεμέτια πάσης φύσεως στο repo σας, ο imitheos. Τα καλύτερα υλικά Φινλανδίας (git), σίγουρη ικανοποίηση.

[geomagas]

Ωχ, τι ήθελες και μου τον θύμισες το δαίμονα αυτόν...

 

Θαρρώ πως, φόρο στο φόρο, όλοι κλέφτες θα γίνουμε στο τέλος!

[migf1]

Να ρωτήσω κάτι. Θέλω να κάνω μια αλλαγή στο master branch η οποία όμως θέλω να γίνει και στο dev_gtk2_replayer branch (έκανα κάτι αλλαγές στο con_color.h)... πώς το κάνουμε αυτό;

 

Γίνεται να φτιάξω ένα 3ο branch (π.χ. από το master) να βάλω εκεί το αλλαγμένο con_color.h και μετά να κάνω merge αυτό το 3ο branch και στο master και στο dev_gtk2_player?

[geomagas]

Για 3ο branch δεν νομίζω να αξίζει τον κόπο. Νομίζω ότι θα πρέπει να το δουλέψεις στο master, και μετά δες αυτό.

[migf1]

Εγώ διάβαζα αυτό:

http://stackoverflow.com/questions/1334027/git-and-working-on-multiple-branches

 

κι αυτό:

http://stackoverflow.com/questions/7908597/merging-one-change-to-multiple-branches-in-git

 

ΥΓ. Τα νεύρα μου ρε συ! Μαμώ τα git μου και τα dvcs μέσα μαμώ. Για να πας από Παγκράτι Κολωνάκι, σε στέλνουν μέσω Κηφισιάς... μαμώ τα git μου και τα dvcs μέσα μαμώ!

 

EDIT:

 

Μαμώ και το TortoiseGit μέσα μαμώ, που δεν κάνει implement όλες τις εντολές του git!

 

EDIT2:

 

Τελικά αυτό που είπα με το 3ο branch μόνο και μόνο για να κάνω το fix και μετά να το κάνω merge και στο master και στο dev_gtk2_replayer θα δουλέψει ή τσάμπα θα μπω στον κόπο;

 

 

ΥΓ. Δεν το δοκιμάζω χωρίς επιβεβαίωση για να μην μου τα κάνει θάλασσα.

 

EDIT3:

 

Τελικά το έκανα χειροκίνητα, ξεχωριστά σε κάθε branch (τα νεύρα μου) και έστειλα από 1 αντίστοιχο pull-request

 

 

Κι έτσι όπως πάει, μάλλον με βλέπω να τη γυρίζω πάλι σε zip αρχεία τη διάθεση του replayer

 

[imitheos]

Να ρωτήσω κάτι. Θέλω να κάνω μια αλλαγή στο master branch η οποία όμως θέλω να γίνει και στο dev_gtk2_replayer branch (έκανα κάτι αλλαγές στο con_color.h)... πώς το κάνουμε αυτό;

 

Γίνεται να φτιάξω ένα 3ο branch (π.χ. από το master) να βάλω εκεί το αλλαγμένο con_color.h και μετά να κάνω merge αυτό το 3ο branch και στο master και στο dev_gtk2_player?

Εφόσον δεν έχει γίνει ο διαχωρισμός που λέγαμε τις προάλλες δηλαδή το dev_gtk2_player περιέχει και τα αρχεία (και την ιστορία) του master, ένας τρόπος είναι να κάνεις την αλλαγή στο master και μετά να κάνεις merge το master στο dev_gtk2_player. Αυτό θα σου φέρει και όσες άλλες αλλαγές έχουν γίνει στο master αλλά δεν σε πειράζει.

 

Αυτό που λες με το 3ο branch θα οδηγήσει ακριβώς στο ίδιο αποτέλεσμα απλά είναι πιο δόκιμο σε μεγαλύτερα fixes.

 

Αν το gtk branch δεν είχε όλα τα αρχεία του master ή για τον Χ,Υ λόγο δεν ήθελες να φέρεις και τις υπόλοιπες αλλαγές, τότε θα κάνεις cherry pick όπως δείξαμε σε παλαιότερο μήνυμα. Πας στο gtk branch και του λες να κάνει cherry pick το τάδε commit πχ το 037a85f commit. Έτσι το branch σου θα έχει μόνο το commit που θέλεις. Υπάρχει μια αντίληψη που λέει ότι το cherry pick δεν είναι ποτέ η λύση και συνήθως είναι σωστή αλλά στη συγκεκριμένη περίπτωση ίσως το cherry pick να είναι πιο δόκιμο από το merge.

 

ΥΓ. Τα νεύρα μου ρε συ! Μαμώ τα git μου και τα dvcs μέσα μαμώ. Για να πας από Παγκράτι Κολωνάκι, σε στέλνουν μέσω Κηφισιάς... μαμώ τα git μου και τα dvcs μέσα μαμώ!

Ίσα ίσα το git είναι το vcs με την περισσότερη ελευθερία. Πολλές φορές διάβαζα σε λίστες να έρχεται κάποιος και να λέει "έτρεξα την Χ εντολή γιατί ήθελα να κάνω το τάδε πράγμα και το repo μου τώρα έχει το δείνα πρόβλημα" και να παίρνει απάντηση (ειδικά στο subversion) "Δεν έπρεπε να το κάνεις αυτό" και να του την λένε κιόλας για το πόσο νουμπάς είναι και δεν ξέρει να δουλεύει σωστά. Αντίθετα το git δεν σου λέει "θα δουλέψεις μόνο έτσι" αλλά σου επιτρέπει να δουλέψεις με 1002 τρόπους (αν φυσικά μάθεις όσες από τις 312 υπο-εντολές που χρειάζονται για τους 1002 τρόπους χρειάζεσαι).

 

Απλά έχουν επικρατήσει 4-5 τρόποι δουλειάς που είναι πιο δόκιμοι και έτσι όλοι δουλεύουμε αυτούς χωρίς όμως να σε περιορίζει το git.

 

 

Μαμώ και το TortoiseGit μέσα μαμώ, που δεν κάνει implement όλες τις εντολές του git!

Το κοίταξα πολύ λίγο τις προάλλες και είδα ότι στις ρυθμίσεις του έχει ένα κάρο εντολές του git και επιλέγεις ποιες θέλεις να σου κάνει expose. Μήπως υλοποιεί την Χ εντολή που ψάχνεις και απλά την έχεις ξετικαρισμένη ?

 

Τελικά αυτό που είπα με το 3ο branch μόνο και μόνο για να κάνω το fix και μετά να το κάνω merge και στο master και στο dev_gtk2_replayer θα δουλέψει ή τσάμπα θα μπω στον κόπο;

 

ΥΓ. Δεν το δοκιμάζω χωρίς επιβεβαίωση για να μην μου τα κάνει θάλασσα.

Θα δουλέψει φυσικά αλλά δες και το cherry pick.

 

Τελικά το έκανα χειροκίνητα, ξεχωριστά σε κάθε branch (τα νεύρα μου) και έστειλα από 1 αντίστοιχο pull-request

 

Κι έτσι όπως πάει, μάλλον με βλέπω να τη γυρίζω πάλι σε zip αρχεία τη διάθεση του replayer

Fear (του git) is the path to the dark side (zip). Fear leads to anger. Anger leads to hate. Hate leads to suffering (zip == suffering).

 

Μη λαμβάνοντας υπόψην το συγκεκριμένο project και μιλώντας θεωρητικά, αυτό που χρησιμοποιείται από πολλούς και κάνει τα merge εύκολα είναι να δουλεύεις πάντα με το πιο παλιό branch που χρειάζεται την αλλαγή ώστε να μπορείς να κάνεις το λεγόμενο upwards merging.

 

Έστω ότι έχεις ένα branch v3.0, ένα v3.2 και ένα v3.4. Κάποια στιγμή που το master σου ήταν αρκετά ώριμο, δημιούργησες την release 3.0 και έκανες ένα branch v3.0 για maintainance της release ώστε να περνάς εκεί fixes. Ομοίως και για τα υπόλοιπα. Υλοποιούσες νέα features και έβγαζες νέες εκδόσεις.

 

Τώρα ήρθε στο φως ένα bug που υπάρχει εδώ και πολύ καιρό και πρέπει να το διορθωθεί. Αν εγώ πάω και κάνω commit το fix στο 3.4 branch, η μόνη μου λύση θα είναι να το κάνω cherry pick. Δεεν θα μπορώ να κάνω merge στα άλλα γιατί έτσι θα τους φέρω και τα νέα features και ουσιαστικά όλα τα branches θα είναι έκδοση 3.4.

 

Αν όμως πάω και κάνω commit στο 3.0, τότε απλά αλλάζω branch ένα-ένα στα νεότερα και κάνω merge. Οι νεότερες εκδόσεις είναι υπερσύνολα των παλιών. Περιέχουν μεν νέα features αλλά περιέχουν και όλα τα commits των παλαιότερων οπότε το merge ουσιαστικά θα φέρει μόνο τις αλλαγές του fix χωρίς να μου πηδήξει την έκδοση.

 

Αν εφαρμόσουμε αυτό τον τρόπο σκέψης στο δικό σου παράδειγμα, ο δόκιμος τρόπος θα ήταν να γίνει το μεγάλο fix στο master ή καλύτερα σε ένα feature branch που δημιουργείς τώρα στο master. Αυτό γίνεται γιατί το master σου είναι το πιο "παλιό" (αυτό του οποίου όλα τα commits περιέχονται σε όλα τα υπόλοιπα branches) και μετά θα το έκανες merge στο "νεότερο" - "υπερσύνολο" (δηλαδή το gtk player).

 

Πρακτικά, το πιο εύκολο είναι το cherry pick.

[migf1]

Κι όμως, το δοκίμασα με το 3ο branch και έγινε ο κακός χαμός (ευτυχώς πριν το κάνω είχα κάνει backup όλο το folder του project, κι έτσι μπόρεσα να το επαναφέρω).

 

Προφανώς κάτι δεν έχω καταλάβει καλά (ή μάλλον πολλά κάτι δεν έχω καταλάβει καλά). Στον σκληρό μου έχω 2 branches: master και dev_gtk2_replayer (το οποίο το είχα κάνει create από το master)... όπως είναι και στο fork. Πρέπει στο dev_gtk2_player να πάω να του πω να κάνει merge το master?

 

ΥΓ1. Κάθισα να προχωρήσω λιγάκι τα σχόλια στον κώδικα του replayer, κι αντί αυτού κάθομαι εδώ και 2 ώρες και παπαρίζομαι με το git.

 

ΥΓ2. Μόλις έκανα άλλο ένα pull-request.

 

ΥΓ3. Στο blessed repo, γιατί τα laz-player & gtk2_player branches λένε τόσα commits behind & τόσα commits ahead of master?

[imitheos]

Προφανώς κάτι δεν έχω καταλάβει καλά (ή μάλλον πολλά κάτι δεν έχω καταλάβει καλά). Στον σκληρό μου έχω 2 branches: master και dev_gtk2_replayer (το οποίο το είχα κάνει create από το master)... όπως είναι και στο fork. Πρέπει στο dev_gtk2_player να πάω να του πω να κάνει merge το master?

Όταν εσύ δουλεύεις στο master και βάζεις νέα commits και κάνεις το ίδιο και στο gtk, αυτά αποκλείνουν. Το merge ενώνει αυτές τις διαφορετικές δουλειές. Αν πρέπει να κάνεις στο gtk merge το master πρέπει να το πεις εσύ. Θέλεις όλη η νέα δουλειά που έκανες στο master να αντικατοπτρίζεται στο gtk ? Αν ναι, τότε πρέπει να κάνεις merge. Επειδή το gtk branch περιέχει ένα τελείως διαφορετικό tree που δεν σχετίζεται με το master θα μπορούσες να μην κάνεις ποτέ merge το master και δεν θα υπήρχε κανένα πρόβλημα. Αυτό θα το κρίνεις εσύ με βάση τις ανάγκες σου.

 

ΥΓ3. Στο blessed repo, γιατί τα laz-player & gtk2_player branches λένε τόσα commits behind & τόσα commits ahead of master?

Όταν εσύ δημιούργησες το laz-replay branch έδειχνε στην τότε κατάσταση του master. Άρχισες να δουλεύεις και έγραψες 5 commits τα οποία, όπως καταλαβαίνεις, δεν υπάρχουν στο master. Έτσι το branch σου είναι 5 commits ahead από το master.

 

Ταυτόχρονα δούλευες και στο master (ή αν θες καλύτερα έκανε merge πράγματα ο geomagas) οπότε το master προχώρησε και τα branches απέκλειναν όπως είπαμε πριν. Έτσι το branch υπολείπεται του master κατά 18 commits. Αυτό που αξίζει να τονίσουμε σε περίπτωση που δεν έχει γίνει κατανοητό είναι ότι ο branch pointer δεν προχωράει μόνος του ακόμη και αν δεν δουλεύεις στο branch. Αν κάνεις τώρα ένα branch στο master και το παρατήσεις, σε 1 μήνα θα είναι "30 commits behind". Για να προχωρήσει θα πρέπει να κάνεις στο branch merge το master (το οποίο αν απλά είναι πίσω χωρίς να έχει γίνει δουλειά θα είναι απλό fast forward merge).

 

% git log --reverse --oneline origin/laz-replay..master 
546124e (2-way push)
4bcabd1 Corrected error 
612ff57 Minor Optimizations & Typos
b1bfb21 Merge pull request #13 from migf1/MinorOpt
5b83fdb Initial commit
84ce7d1 Version bump
aa394e3 Windows screen-shots, Tag renaming, i18n preparations
15b1cf0 Added missing screen-shots
4b8307b Typos
8b63fcf Typos
2262594 Merge branch 'dev_gtk2_replayer' of https://github.com/migf1/2048cc into dev_gtk2_replayer
425f401 Markup mess
e5f45b6 Markup mess #2
df9b1f6 Markup mess #3
b0454c7 Merge pull request #14 from migf1/dev_gtk2_replayer
0eae7a8 Removed gtk2_replayer from master
64987e2 con_color: Remove compiler warnings in win32 - (int)GetLastError()
c1b73d2 Merge pull request #17 from migf1/master
% git log --reverse --oneline origin/laz-replay..master | wc -l
18

Εδώ βλέπουμε αυτό που σου λέει το github. Η έκφραση laz-replay..master μας λέει ξεκίνα στο laz-replay και φτάσε στο master οπότε μας δίνει όλα τα commits που έχουν γίνει στο master σου αλλά δεν έχουν ενσωματωθεί στο branch.

 

% git log --reverse --oneline master..origin/laz-replay
10ddb5d Uploaded the Lazarus Replayer
d087fef Deleted redundant replays directory
0a6fc32 Added (a) Windows executable
4b54c89 Minor development changes
b714138 Decoupled replays from main form

Και εδώ το αντίθετο. Αυτή είναι η δουλειά που έχει γίνει στο laz-replay branch αλλά για κάποιο λόγο (ίσως δεν είναι έτοιμη ακόμη) δεν έχει ενσωματωθεί στο master για να την πάρει ο κόσμος.

 

 

Κι όμως, το δοκίμασα με το 3ο branch και έγινε ο κακός χαμός (ευτυχώς πριν το κάνω είχα κάνει backup όλο το folder του project, κι έτσι μπόρεσα να το επαναφέρω).

Αναχρονιστικά πράγματα. VCS δουλεύεις.

 

What do VCSs do ? Αποθηκεύουν το περιεχόμενό σου με όλες τις αλλαγές του. Οπότε backup των folder και zip και λοιπά είναι πράγματα του παρελθόντος. Enter Reflog.

 

Όλα τα git repos (τα μη-bare αλλά για την ώρα σκέψου όλα) ενεργοποιούν το reflog το οποίο κρατάει ό,τι κάνεις.

 

% git reflog
c1b73d2 HEAD@{0}: clone: from git://github.com/geomagas/2048cc.git

Δεν έχω κάνει τίποτα ακόμη οπότε το reflog έχει μόνο το clone.

 

% git rm 2048cc_win_x86.exe
rm '2048cc_win_x86.exe'
% git commit -m "paei to exe"
[master ebd0bbc] paei to exe
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 2048cc_win_x86.exe

Ωχ έκανα βλακεία. Τι γίνεται τώρα ?

% git reflog 
ebd0bbc HEAD@{0}: commit: paei to exe
c1b73d2 HEAD@{1}: clone: from git://github.com/geomagas/2048cc.git

Επ τώρα έχω δύο states και μπορώ να γυρίσω σε όποιο θέλω.

% git reset --hard c1b73d2
HEAD is now at c1b73d2 Merge pull request #17 from migf1/master
% ls
2048cc_win_x86.exe  README.md  replays/  src/  ss/
% git reflog 
c1b73d2 HEAD@{0}: reset: moving to c1b73d2
ebd0bbc HEAD@{1}: commit: paei to exe
c1b73d2 HEAD@{2}: clone: from git://github.com/geomagas/2048cc.git

Κάνω reset με την παράμετρο hard ώστε να μου επαναφέρει και το tree και το index και γενικά τα πάντα στο προηγούμενο state (η hard θέλει λίγο προσοχή σε περίπτωση που έχουμε δουλειά που δεν έχει γίνει commit). Με το ls βλέπουμε ότι το exe ξαναήρθε. Επίσης βλέπουμε κάτι πολύ σημαντικό. Το reflog δεν μας δείχνει μόνο την πρώτη state όπως θα ήταν λογικό μια και ξαναγυρίσαμε εκεί αλλά μας έχει ξεχωριστά σαν τρίτο βήμα αυτό που κάναμε οπότε μπορούμε αν θέλουμε να ξαναγυρίσουμε στο commit με το σβησμένο exe. Δηλαδή κρατάει τα πάντα. Ακόμη και τις μεταπηδήσεις από το ένα branch στο άλλο κρατάει.

 

Έκανες βλακεία στο merge (και έχει τελειώσει το merge οπότε δεν μπορείς να τρέξεις --abort) ? Enter Reflog. Έκανες βλακεία στο rebase ? Το ίδιο. Σε κατέστρεψε ο βέλιουρας ? Reflog.

 

Από τη μάνα του το git σβήνει μόνο καταχωρήσεις που έχουν περάσει τις 90 μέρες και αυτό ακόμη αλλάζει σε περίπτωση που μιλάμε για ένα repo με πολύ αργή ανάπτυξη και μπορεί να γίνει όσο μικρό ή όσο μεγάλο θέλει ο developer.

Επεξ/σία 11 Αυγούστου 2014 από imitheos

[migf1]

Καλημέρα.

 

Καταρχήν σε ευχαριστώ για τις αναλυτικές οδηγίες. Δυστυχώς όμως δεν μπορώ να πω πως είμαι σε θέση να τις καταλάβω/παρακολουθήσω όλες.

 

Έχω πολύ πιο βασικά προβλήματα. Ίσως να φταίει πως το ότι προσπαθώ το προσπαθώ από το TortoiseGit κι όχι από τη γραμμή εντολών, δεν ξέρω.

 

Για παράδειγμα, μόλις τώρα επιχείρησα να κάνω merge το master στο gtk branch, και το αποτέλεσμα ήταν πως και conflicts έβγαλε και έσβησε διάφορα αρχεία του gtk που δεν υπάρχουν στο master. Τα επανέφερα κάνοντας revert.

 

Υποτίθεται πως τα αρχεία του master branch υπάρχουν αυτούσια στο gtk branch, κι απλώς στο gtk branch υπάρχουν κι άλλα. Το merge δεν θα έπρεπε να μου κρατάει τα έξτρα αρχεία στο gtk-branch.

 

Για να κάνω το merge, έκανα (δεν ξέρω γιατί τις βγάζει δυσανάλογες τις εικόνες ο editor)...

 

1. Switch/checkout στο gtk branch...

 

2. Merge το master branch...

 

το βήμα 3 περιέχει τα εξής μηνύματα:

 

 

git.exe merge master

 

Removing gtk2_replayer/ss/06_statusbar.png

Removing gtk2_replayer/ss/05_jumpto.png

Removing gtk2_replayer/ss/04_playback.png

Removing gtk2_replayer/ss/03_file_open.png

Removing gtk2_replayer/ss/02_about.png

Removing gtk2_replayer/ss/01_fallback.png

CONFLICT (modify/delete): gtk2_replayer/src/text.h deleted in master and modified in HEAD. Version HEAD of gtk2_replayer/src/text.h left in tree.

Removing gtk2_replayer/src/misc.h

Removing gtk2_replayer/src/misc.c

Removing gtk2_replayer/src/main.c

Removing gtk2_replayer/src/gui_statusbar.h

Removing gtk2_replayer/src/gui_statusbar.c

Removing gtk2_replayer/src/gui_slider.h

Removing gtk2_replayer/src/gui_slider.c

Removing gtk2_replayer/src/gui_menus.h

Removing gtk2_replayer/src/gui_menus.c

Removing gtk2_replayer/src/gui_locale.h

Removing gtk2_replayer/src/gui_locale.c

Removing gtk2_replayer/src/gui_dialogs.h

CONFLICT (modify/delete): gtk2_replayer/src/gui_dialogs.c deleted in master and modified in HEAD. Version HEAD of gtk2_replayer/src/gui_dialogs.c left in tree.

Removing gtk2_replayer/src/gui_board.h

Removing gtk2_replayer/src/gui_board.c

Removing gtk2_replayer/src/gui/tool_stop.png

Removing gtk2_replayer/src/gui/tool_speed_reset.png

Removing gtk2_replayer/src/gui/tool_prev.png

Removing gtk2_replayer/src/gui/tool_plus.png

Removing gtk2_replayer/src/gui/tool_play.png

Removing gtk2_replayer/src/gui/tool_pause.png

Removing gtk2_replayer/src/gui/tool_next.png

Removing gtk2_replayer/src/gui/tool_minus.png

Removing gtk2_replayer/src/gui/tool_last.png

Removing gtk2_replayer/src/gui/tool_jumpto.png

Removing gtk2_replayer/src/gui/tool_first.png

Removing gtk2_replayer/src/gui/imgUp.png

Removing gtk2_replayer/src/gui/imgRight.png

Removing gtk2_replayer/src/gui/imgNomove.png

Removing gtk2_replayer/src/gui/imgLeft.png

Removing gtk2_replayer/src/gui/imgDown.png

Removing gtk2_replayer/src/gui/gtk2_viewer_bak.png

Removing gtk2_replayer/src/gui/gtk2_replayer_logo.png

Removing gtk2_replayer/src/gui/gtk2_replayer_icon.png

Removing gtk2_replayer/src/gui/gtk2_replayer.glade

Removing gtk2_replayer/src/gui/flag_envLang.png

Removing gtk2_replayer/src/gui/flag_en.png

Removing gtk2_replayer/src/gui/flag_el.png

Removing gtk2_replayer/src/gui.h

CONFLICT (modify/delete): gtk2_replayer/src/gui.c deleted in master and modified in HEAD. Version HEAD of gtk2_replayer/src/gui.c left in tree.

CONFLICT (modify/delete): gtk2_replayer/src/gamedata.h deleted in master and modified in HEAD. Version HEAD of gtk2_replayer/src/gamedata.h left in tree.

CONFLICT (modify/delete): gtk2_replayer/src/gamedata.c deleted in master and modified in HEAD. Version HEAD of gtk2_replayer/src/gamedata.c left in tree.

CONFLICT (modify/delete): gtk2_replayer/src/_xgettext_info.txt deleted in master and modified in HEAD. Version HEAD of gtk2_replayer/src/_xgettext_info.txt left in tree.

CONFLICT (modify/delete): gtk2_replayer/src/README.md deleted in master and modified in HEAD. Version HEAD of gtk2_replayer/src/README.md left in tree.

Removing gtk2_replayer/gui/tool_stop.png

Removing gtk2_replayer/gui/tool_speed_reset.png

Removing gtk2_replayer/gui/tool_prev.png

Removing gtk2_replayer/gui/tool_plus.png

Removing gtk2_replayer/gui/tool_play.png

Removing gtk2_replayer/gui/tool_pause.png

Removing gtk2_replayer/gui/tool_next.png

Removing gtk2_replayer/gui/tool_minus.png

Removing gtk2_replayer/gui/tool_last.png

Removing gtk2_replayer/gui/tool_jumpto.png

Removing gtk2_replayer/gui/tool_first.png

Removing gtk2_replayer/gui/imgUp.png

Removing gtk2_replayer/gui/imgRight.png

Removing gtk2_replayer/gui/imgNomove.png

Removing gtk2_replayer/gui/imgLeft.png

Removing gtk2_replayer/gui/imgDown.png

Removing gtk2_replayer/gui/gtk2_viewer_bak.png

Removing gtk2_replayer/gui/gtk2_replayer_logo.png

Removing gtk2_replayer/gui/gtk2_replayer_icon.png

Removing gtk2_replayer/gui/gtk2_replayer.glade

Removing gtk2_replayer/gui/flag_envLang.png

Removing gtk2_replayer/gui/flag_en.png

Removing gtk2_replayer/gui/flag_el.png

CONFLICT (modify/delete): gtk2_replayer/gtk2_replayer.exe deleted in master and modified in HEAD. Version HEAD of gtk2_replayer/gtk2_replayer.exe left in tree.

CONFLICT (modify/delete): gtk2_replayer/README.md deleted in master and modified in HEAD. Version HEAD of gtk2_replayer/README.md left in tree.

Automatic merge failed; fix conflicts and then commit the result.

 

git did not exit cleanly (exit code 1) (281 ms @ 12/8/2014 10:07:55 πμ)

 

3. Revert για να τα επαναφέρω (και πάω να πετάξω το pc από το μπαλκόνι )

 

Δεν ξέρω αν έχει σημασία, το master branch περιέχει τα αρχεία του gtk branch, αλλά του έχω πει να κάνει ignore τον φάκελο gtk2_replayer... για αυτό τον δείχνει με εικονίδιο πλην ( - ) στην 1η εικόνα (εκείνη δηλαδή που δείχνει τα περιεχόμενα όταν είμαστε στο master branch).

[imitheos]

Καταρχήν σε ευχαριστώ για τις αναλυτικές οδηγίες. Δυστυχώς όμως δεν μπορώ να πω πως είμαι σε θέση να τις καταλάβω/παρακολουθήσω όλες.

 

Έχω πολύ πιο βασικά προβλήματα. Ίσως να φταίει πως το ότι προσπαθώ το προσπαθώ από το TortoiseGit κι όχι από τη γραμμή εντολών, δεν ξέρω.

Ή πιθανότερα γιατί το εξηγώ εγώ χάλια. Κάνε quote διάφορα points μου για να τα εξηγήσω διαφορετικά.

 

Για παράδειγμα, μόλις τώρα επιχείρησα να κάνω merge το master στο gtk branch, και το αποτέλεσμα ήταν πως και conflicts έβγαλε και έσβησε διάφορα αρχεία του gtk που δεν υπάρχουν στο master. Τα επανέφερα κάνοντας revert.

 

Υποτίθεται πως τα αρχεία του master branch υπάρχουν αυτούσια στο gtk branch, κι απλώς στο gtk branch υπάρχουν κι άλλα. Το merge δεν θα έπρεπε να μου κρατάει τα έξτρα αρχεία στο gtk-branch.

Έχεις απόλυτο δίκιο. Αυτό που σου περιέγραψα με το merge ισχύει αλλά ξέχασα τη βλακεία που έγινε με τα branches για αυτό σου βγάζει πρόβλημα. Ας δούμε από που ξεκινάει το θέμα. Η εντολή merge-base σου εμφανίζει την κοινή αρχή δύο branches.

 

% git merge-base master origin/dev_gtk2_replayer 
b0454c7de00c3e7f29823e5fbbebc7d06430c7a5

 

Η αρχή των branches φαίνεται και από το γράφημα ότι είναι το επιλεγμένο commit αλλά έβαλα και την merge-base για να είναι πιο κατανοητό. Από αυτό το commit και μετά αρχίζει η απόκλιση των δύο branches. Το merge φυσικά δουλεύει σωστά αλλά γιατί σου δημιουργεί πρόβλημα ?

 

Ο geomagas έκανε merge την pull request στο master branch από λάθος αντί για το gtk branch. Έπειτα το διόρθωσε αλλά με ένα όχι και τόσο δόκιμο τρόπο δηλαδή να δημιουργήσει ένα νέο commit που σβήνει τον κατάλογο gtk2_replayer.

 

Όταν λοιπόν πας να κάνεις merge το master στο gtk, το merge προσπαθεί να περάσει τα commits που βλέπει οπότε πάει και σβήνει τον κατάλογο. Μετά βλέπει ένα άλλο commit που αλλάζει κάτι στο αρχείο gtk_replaer/τάδε το οποίο όμως δεν υπάρχει οπότε δημιουργούνται οι διενέξεις.

 

Τα βήματα που έκανες ήταν σωστά αλλά αντιμετώπισες ένα χαμό λόγω της κακής επίλυσης του geomagas.

 

Ο δόκιμος τρόπος τώρα θα ήταν να επιλυθεί σωστά το πρόβλημα και να γίνει force push αλλά είναι μανούρα οπότε μπορείς να το λύσεις εσύ διαφορετικά.

 

ours

This resolves any number of heads, but the resulting tree of the

merge is always that of the current branch head, effectively

ignoring all changes from all other branches. It is meant to be

used to supersede old development history of side branches. Note

that this is different from the -Xours option to the recursive

merge strategy.

Το git υποστηρίζει πολλές διαφορετικές στρατηγικές με τις οποίες κάνει τα merge. Μία από αυτές είναι η λεγόμενη ours η οποία υπό κανονικές συνθήκες δεν πρέπει να χρησιμοποιείται γιατί όπως διαβάζεις αγνοεί εντελώς τις αλλαγές του branch. Απλά κάνει το branch να φαίνεται ως merged χωρίς να φέρει καμμία από τις αλλαγές του.

 

Στην προκειμένη περίπτωση όμως σε συμφέρει αυτό γιατί δεν θα χάσεις τίποτα. Τα δύο commits που θα χαθούν είναι α) αυτό που σβήνει τον κατάλογο και θέλεις να το αγνοήσεις β) αυτό που αλλάζει το con_color το οποίο μεν χρειάζεται αλλά επειδή είχες τσατιστεί το είχες κάνει σαν ξεχωριστό commit και στο άλλο branch οπότε το έχεις ήδη.

 

Όπως λέμε δύο αρνήσεις => μία κατάφαση, η κακή επίλυση που έκανες με τα δύο commits σε βοηθάει να διορθώσεις την πρώτη κακή επίλυση .

 

Άρα δεν χάνεις τίποτα και οδηγείσαι στο παρακάτω αποτέλεσμα με το master να είναι merged στο gtk.

 

 

Δεν ξέρω πως γίνεται στο Tortoise αλλά τα βήματα που έκανα εγώ ήταν τα εξής:

 

1) git checkout -b gtk origin/dev_gtk_player
2) git merge --strategy=ours master

Με το 1 δημιουργώ ένα νέο branch με όνομα gtk το οποίο να ακολουθεί το remote branch στο github με όνομα dev_gtk_player. Αυτό το βήμα δεν χρειάζεται να το κάνεις εσύ γιατί λογικά έχεις ήδη ένα τοπικό branch με όνομα dev_gtk_player (αυτό από το οποίο προήλθε το branch στο github). Εσύ απλά θα μετακινηθείς σε αυτό το branch.

 

Με το 2 έκανα merge το master στο τρέχον branch αγνοώντας όλες τις αλλαγές του master. Μετά κάνεις απλά push στο github.

[migf1]

...

Δεν ξέρω πως γίνεται στο Tortoise αλλά τα βήματα που έκανα εγώ ήταν τα εξής:

 

1) git checkout -b gtk origin/dev_gtk_player
2) git merge --strategy=ours master

Με το 1 δημιουργώ ένα νέο branch με όνομα gtk το οποίο να ακολουθεί το remote branch στο github με όνομα dev_gtk_player. Αυτό το βήμα δεν χρειάζεται να το κάνεις εσύ γιατί λογικά έχεις ήδη ένα τοπικό branch με όνομα dev_gtk_player (αυτό από το οποίο προήλθε το branch στο github). Εσύ απλά θα μετακινηθείς σε αυτό το branch.

 

Με το 2 έκανα merge το master στο τρέχον branch αγνοώντας όλες τις αλλαγές του master. Μετά κάνεις απλά push στο github.

 

Υποθέτω πως με το TortoiseGit κάνω πρώτα switch στο dev_gtk2_player branch, μετά του λέω να κάνει merge το master branch, αλλά μέσα στο dialog του merge του ενεργοποιώ την ours επιλογή, πριν δώσω το OK...

 

Αν θελήσω να το κάνω από γραμμή-εντολών, αρκεί να κάνω cd μέσα στον φάκελο του προτζεκτ και να δώσω την εντολή που είπες? ( git merge --strategy=ours master )

 

Αν γίνει πάλι κάνας χαμός, θα μπορέσω να τα επαναφέρω με Revert?

 

ΥΓ. Δεν ξέρω ρε φίλε, εμένα όλα αυτά (εξακολουθούν να) μου φαίνονται άβολα, bloated και error-prone διαδικασίες. Προφανώς και δεν νοείται multi-contributors project χωρίς κάποιο vcs, αλλά δεν παύει να είναι ένας διαρκής πονοκέφαλος.

 

Ουσιαστικά χρειάζεσαι κάποιον git (or whatever other vcs) expert στην ομάδα σου, επωμισμένο με τη δουλειά του maintainer. Κι από ότι διαβάζω εδώ κι εκεί, δεν είναι και λίγα τα horror-stories (π.χ. http://randyfay.com/content/avoiding-git-disasters-gory-story... και μου ακούγεται απόλυτα φυσιολογικό να υπάρχουν horror-stories, αφού έτσι όπως έχει γίνει το πράγμα πρέπει πλέον μεταξύ όλων των άλλων είτε να "σπουδάσεις" κιόλας την "επιστήμη" των vcs, είτε να "προσλάβεις" κάποιον "πτυχιούχο"

[pmav99]

Κατά σειρά αυξανόμενης πολυπλοκότητας

 

a) one repo - one contributor

b ) one repo - many contributors

c) many repos - many contributors

 

Η όλη φάση με τα pull requests (που κατουσίαν είναι multiple upstreams) αυξάνουν την πολυπλοκότητα του workflow. Το απλούστερο στην περίπτωσή σας είναι το b ) ενώ εσείς δουλεύετε κατευθείαν με το c).

 

DVCS expert δεν χρειάζεσαι εκτός και αν

 

α) το project είναι τεράστιο

β) σε ενδιαφέρει πραγματικά να έχεις πεντακάθαρη ιστορία

 

Αναφορικά με το tortoisegit, προσωπικά μου κάνει εντύπωση που επιλέγεις να δουλέψεις με αυτό. Για εμένα η λογική είναι η ίδια με τα διάφορα toolchains που χρησιμοποιείς πχ σε μία γλώσσα προγραμματισμού. Μάθε τα low level εργαλεία για να καταλάβεις τι γίνεται και μετά πας στα πιο high level.

 

Προσωπικά χρησιμοποιώ

 

* git gui για να κάνω commits· θέλω να διαλέγω ποια chunks/lines θα γίνουν commit με γραφικό τρόπο

* gitg για να βλέπω το history (που είναι clone του gitk απλά πιο όμορφο)

* git σκέτο για όλα τα άλλα

 

καμιά φορά (πολύ σπάνια) μπορεί να ανοίξω και κανένα smartgithg που είναι πραγματικά πολύ καλό αλλά 99/100 βαριέμαι να το μάθω και το κλείνω.

Επεξ/σία 12 Αυγούστου 2014 από pmav99

[imitheos]

Υποθέτω πως με το TortoiseGit κάνω πρώτα switch στο dev_gtk2_player branch, μετά του λέω να κάνει merge το master branch, αλλά μέσα στο dialog του merge του ενεργοποιώ την ours επιλογή, πριν δώσω το OK...

Ναι λογικά έτσι θα γίνεται από ό,τι βλέπω από την εικόνα.

 

Αν θελήσω να το κάνω από γραμμή-εντολών, αρκεί να κάνω cd μέσα στον φάκελο του προτζεκτ και να δώσω την εντολή που είπες? ( git merge --strategy=ours master )

Ναι έτσι γίνεται αρκεί φυσικά να είσαι στο branch που θέλεις. Διαφορετικά μετά το cd θα πρέπει απλά να τρέξεις git checkout dev_gtk_replayer για να μεταφερθείς σε εκείνο το branch.

 

Αν γίνει πάλι κάνας χαμός, θα μπορέσω να τα επαναφέρω με Revert?

Και πριν ήθελα να το ρωτήσω τι εννοείς λέγοντας revert. Αν το revert το εννοείς ετυμολογικά δηλαδή να επαναφέρει το merge χρησιμοποιώντας την εντολή reset ή κάποια παρόμοια (όπως έδειξα πριν στο παράδειγμα του reflog) τότε ναι αυτή είναι η σωστή διαδικασία. Αν το εννοείς κυριολεκτικά χρησιμοποιώντας την εντολή git-revert τότε όχι δεν θα δουλέψει σωστά σε merge.

 

ΥΓ. Δεν ξέρω ρε φίλε, εμένα όλα αυτά (εξακολουθούν να) μου φαίνονται άβολα, bloated και error-prone διαδικασίες. Προφανώς και δεν νοείται multi-contributors project χωρίς κάποιο vcs, αλλά δεν παύει να είναι ένας διαρκής πονοκέφαλος.

 

Ουσιαστικά χρειάζεσαι κάποιον git (or whatever other vcs) expert στην ομάδα σου, επωμισμένο με τη δουλειά του maintainer. Κι από ότι διαβάζω εδώ κι εκεί, δεν είναι και λίγα τα horror-stories (π.χ. http://randyfay.com/content/avoiding-git-disasters-gory-story... και μου ακούγεται απόλυτα φυσιολογικό να υπάρχουν horror-stories, αφού έτσι όπως έχει γίνει το πράγμα πρέπει πλέον μεταξύ όλων των άλλων είτε να "σπουδάσεις" κιόλας την "επιστήμη" των vcs, είτε να "προσλάβεις" κάποιον "πτυχιούχο"

Είσαι τυχερός που έχει ψιλο εξαλειφθεί το CVS (και το subversion έχει βλακείες αλλά όχι τόσες). Να εύχεσαι στον εχθρό σου να δουλεύει CVS

 

Ίσως είναι συνήθεια αλλά εγώ δεν μπορώ να δουλέψω χωρίς git. Σου έδειξα παραδείγματα που μέχρι και τα πιο χαζά πράγματα όπως με ποια σειρά πρέπει να φορτώσω τα mods για ένα παιχνίδι τα σώζω όλα σε repo.

 

Εκτός από τα δικά μου projects και τα ουκ ολίγα repos που απλά παρακολουθώ, συμμετέχω σε 5-6 repos και δεν μπορώ να πω ότι έχω κάνει πολλές βλακείες ή τουλάχιστον κάποια που να μην μπορώ να διορθώσω και σίγουρα δεν έχω δει κάποιο horror story.

 

Μου φαίνεται πολύ εύκολη διαδικασία και στους περισσότερους devs έχει γίνει δεύτερη φύση το git. Ίσως φταίει το γεγονός ότι δεν χρησιμοποιούμε GUI και Github (πέραν από hosting). Αν έπρεπε να κλείσω το notepad, να πάω στον explorer στον κατάλογο του repo, να κάνω δεξί κλικ για να βγει το context μενού του Tortoise, να κάνω add και ποιος ξέρει τι άλλο και εμένα θα μου φαινόταν bloated και άβολο.

 

Όταν από την άλλη έχεις ανοιγμένο ένα τερματικό και τρέχεις vi (ή οποιονδήποτε editor τρέχει ο κάθε dev), απλά θα γράψεις make και git-τάδε. Σε συνδυασμό μάλιστα με τα aliases του git δεν γράφεις καν αυτό. Ένα κλασικό alias που έχουμε πολλοί είναι au = add --update οπότε οποιαδήποτε αλλαγή σε υπάρχοντα αρχεία γίνεται add με ένα απλό git au. Και σε συνδυασμό με τα aliases των shells έχεις gau = git au. Δεν το σκέφτεσαι καν και αφού βγεις από τον editor το χέρι σου αυτόματα γράφει gau.

 

Το workflow δηλαδή που χρησιμοποιείς χωρίς το git, επεκτείνεται να συμπεριλάβει το git χωρίς ουσιαστικά να σου αλλάζει τίποτα.

 

Σε πολλούς editor μάλιστα όπως το vim έχεις plugins που με κάποιο συνδυασμό πλήκτρων σου κάνει και make και git add, commit, κτλ οπότε γίνεται ακόμη πιο εύκολο.

[migf1]

@imitheos:

 

Αν δεις την 1η εικόνα σε αυτό το ποστ, το context menu έχει και μια εντολή Revert (πάνω από την Switch/Checkout)... δεν έχω ιδέα ποιο command-line flag περνάει στο git.

 

Οπότε, αν κάνω αυτό που πρότεινες με το --strategy=ours και στραβώσει, τι πρέπει να κάνω για να το επαναφέρω από γραμμή εντολών? Ρωτάω για να μην την πατήσω πάλι (όποιος έχει καεί στον χυλό, φυσάει και το γιαούρτι ).

 

@pmav & @imitheos:

 

Το gui μου δίνει την αίσθηση (ίσως και την ψευδαίσθηση, δεν το ξέρω) της σχετικής ασφάλειας, ως νουμπά. Π.χ. μου κρύβει εντολές που δεν ισχύουν στην τρέχουσα κατάσταση, μπορώ και βλέπω οπτικοποιημένα γκρουπαρισμένες σχτεικές εντολές, κλπ.

 

Το ζήτημα προκύπτει από το γεγονός πως αυτή τη στιγμή θεωρώ πως έχει μεγαλύτερη προτεραιότητα να ασχοληθώ (όποτε μπορώ να ασχοληθώ) αφενός με τον κώδικα αυτόν κάθε αυτόν, κι αφετέρου με την εσωτερική &εξωτερική του τεκμηρίωση, την ενημέρωση της κοινότητας, κλπ παρά το να ασχοληθώ με τα ενδότερα του git.

 

Π.χ. τον κώδικα του replayer δεν νομίζω πως μπορεί να τον παρακολουθήσει εύκολα κανείς έτσι όπως είναι τώρα, χωρίς σχόλια... ελπίζω το BROWSING.md να βοηθάει κάπως (αν και πρέπει να γράψω κι άλλα), αλλά νομίζω δεν συγκρίνεται με το να υπάρχουν ΚΑΙ σχόλια μέσα στον ίδιο τον κώδικα.

 

Από την άλλη μεριά, ο κώδικας του κυρίως παιχνιδιού, περιέχει μεν περιγραφικά σχόλια αλλά και πάλι δεν είμαι πολύ σίγουρος πως είναι εύκολο να τον παρακολουθήσει χωρίς κάποιο αντίστοιχο αρχείο με το BROWSING.md του player, που να εξηγεί έστω και περιληπτικά πως & γιατί συνδέονται/επικοινωνούν μεταξύ τους τα διάφορα source-modules.

 

Συν ότι για παράδειγμα, το parsing που κάνω κατά το serialization/deserialization στο κυρίως παιχνίδι, είναι τελείως inefficient συγκρτικά με το ίδιο πράγμα στον player. Θεωρώ πως έχει μεγαλύτερη προτεραιότητα να αξιοποιήσω τον όποιον χρόνο έχω διαθέσιμο για να το φτιάξω αυτό, από το να εμβαθύνω στο git.

 

Ομοίως, νομίζω έχει μεγαλύτερη προτεραιότητα να φτιάξω π.χ. το internatinalization του player, από το να χάνω 2 ώρες για να βρω γιατί δεν δουλεύει το merge όπως έπρεπε... κι άλλες τόσες για να γράφω μηνύματα το φόρουμ επειδή μόνος μου δεν έβγαλα άκρη (κι ευτυχώς που το βρήκε και το εξήγησε ο ημίθεος, αλλιώς εγώ ακόμα θα έψαχνα).

 

Αυτός είναι και ο βασικός λόγος που δεν θέλησα εξαρχής (κι εξακολουθώ να μη θέλω) να είμαι εγώ ο maintainer του blessed repo. Δεν έχω ούτε το απαραίτητο expertise, αλλά κυρίως ούτε την ευχέρεια να το αποκτήσω στην παρούσα φάση (επειδή όπως εξηγώ παραπάνω, εκτιμώ πως έχουν προτεραιότητα πιο ουσιώδη πράγματα στον κώδικα και την τεκμηρίωσή του και δυστυχώς ο χρόνος και τα κίνητρα είναι ήδη περιορισμένα).

 

Νομίζω πως το ιδανικό στην παρούσα φάση θα ήταν να προθυμοποιηθεί/ενδιαφερθεί κάποιος (ή κάποιοι) που γνωρίζει τα των git/github να αναλάβει το maintenance, ώστε εγώ (εικάζω και ο geomagas) να μπορέσω να ασχοληθώ απρόσκοπτα στον χρόνο που διαθέτω με άλλα επίσης απαραίτητα πράγματα (που δεν είναι και λίγα, αλλά τουλάχιστον τα γνωρίζω καλά).

 

EDIT:

 

 

 

Άσχετο, αλλά με αφορμή το "απόφθεγμα" του Τόρβαλντς στην υπογραφή του ημίθεου, εμένα μου αρέσει κι ένα άλλο του "απόφθεγμα": Talk is cheap, show me the code

 

 

[imitheos]

Οπότε, αν κάνω αυτό που πρότεινες με το --strategy=ours και στραβώσει, τι πρέπει να κάνω για να το επαναφέρω από γραμμή εντολών? Ρωτάω για να μην την πατήσω πάλι (όποιος έχει καεί στον χυλό, φυσάει και το γιαούρτι ).

Με δεδομένο ότι δεν έχεις κάνει άλλες αλλαγές που δεν έχεις κάνει commit, θα χρησιμοποιήσεις την εντολή reset όπως δείξαμε στην περίπτωση του reflog.

 

% git checkout dev_gtk2_replayer
% git merge --strategy=ours -m "Merge but ignore master" master
% git show
commit cdccf3cc5a32721cc3b36b1894285c2ab0705eaa
Merge: 9085ec5 c1b73d2
Commit:     imitheos <[email protected]>
CommitDate: Tue Aug 12 13:38:28 2014 +0300

    Merge but ignore master

Έγινε το merge. Κοίταξε το tree σου είναι σωστό ? Αν δεν είναι κάνεις reset το tree στην προηγούμενη κατάσταση.

% git reflog 
cdccf3c HEAD@{0}: merge master: Merge made by the 'ours' strategy.
9085ec5 HEAD@{1}: checkout: moving from master to dev_gtk2_replayer
c1b73d2 HEAD@{2}: clone: from git://github.com/geomagas/2048cc.git
% git reset --hard HEAD@{1}

Πάει το merge σαν να μην έγινε ποτέ.

 

Αν όλα αυτά σε μπερδεύουν, τότε έχε ως πρακτική το scratch branch που είπαμε πριν κάμποσα μηνύματα.

 

1) % git checkout dev_gtk2_replayer
% git checkout -b mitsos1
Switched to a new branch 'mitsos1'

2) % git merge --strategy=ours -m "Scratch Merge of master" master
Merge made by the 'ours' strategy.

3) % git checkout dev_gtk2_replayer 
Switched to branch 'dev_gtk2_replayer'

4) % git br -D mitsos1
Deleted branch mitsos1 (was b0ed80b).

Μεταφέρεσαι στο branch που θέλεις και δημιουργείς ένα νέο branch με ό,τι όνομα θέλεις και φυσικά μεταφέρεσαι σε εκείνο. Μετά στο 2 κάνεις κανονικά merge αλλά στο νέο branch. Κοιτάς το tree και βλέπεις αν πέτυχε ή όχι. Στο 3 μεταφέρεσαι στο κανονικό σου branch και στο 4 σβήνεις το προσωρινό.

 

Αν το merge σου δεν πέτυχε ζητάς βοήθεια από κάποιον ενώ αν πέτυχε το ξανακάνεις merge αλλά στο πραγματικό branch αυτή τη φορά.

 

Έτσι ό,τι και να γίνει, το πραγματικό σου branch μένει αμόλυντο και δεν έχεις το φόβο του ωχ τι θα κάνω τώρα που έγινε βλακεία. Απλά έτσι κάνεις διπλή δουλειά.

 

@pmav & @imitheos:

 

Το gui μου δίνει την αίσθηση (ίσως και την ψευδαίσθηση, δεν το ξέρω) της σχετικής ασφάλειας, ως νουμπά. Π.χ. μου κρύβει εντολές που δεν ισχύουν στην τρέχουσα κατάσταση, μπορώ και βλέπω οπτικοποιημένα γκρουπαρισμένες σχτεικές εντολές, κλπ.

Δεν μπορώ να ξέρω πώς δουλεύεις αλλά μου δίνεται η εντύπωση πως η πηγή όλων των προβλημάτων σου είναι το Tortoise που δεν σε αφήνει να κατανοήσεις κάποιες έννοιες που χρειάζονται.

 

Το ζήτημα προκύπτει από το γεγονός πως αυτή τη στιγμή θεωρώ πως έχει μεγαλύτερη προτεραιότητα να ασχοληθώ (όποτε μπορώ να ασχοληθώ) αφενός με τον κώδικα αυτόν κάθε αυτόν, κι αφετέρου με την εσωτερική &εξωτερική του τεκμηρίωση, την ενημέρωση της κοινότητας, κλπ παρά το να ασχοληθώ με τα ενδότερα του git.

Ίσα ίσα το παρόν project που δεν είναι κάτι καίριο και δεν θα νοιαστεί και πολύς κόσμος να περιέχει bugs ή αν δεν έχει επαρκή τεκμηρίωση είναι ό,τι πρέπει για να μάθεις τα ενδότερα του git. Αντί λοιπόν να χρησιμοποιείς το git ως εργαλείο για να βελτιώσεις το 2048, μπορείς να χρησιμοποιήσεις το 2048 ως εργαλείο για να βελτιώσεις το git-fu σου.