Ιδέες για project σε C

[imitheos]

Λοιπόν, μόλις τα έκανα όπως τα είπαμε... 2 commits στο ίδιο branch: ένα με τις ουσιώδεις αλλαγές, κι ένα tagged Version Bump που βασικά αλλάζει μονάχα τα comments των πηγαίων και τα screenshots στον ss/ φάκελο.

 

Ελπίζω να μην γίνει κάνα μπάχαλο όταν τα εφαρμόσει ο geomagas

Το πέρασε

 

Τώρα μπορείς να σβήσεις το branch αν θέλεις (και επίσης να φέρεις το master σου σε sync με τον geomaga)

[geomagas]

Έτοιμα!

[migf1]

Είναι πολύ γρήγορο αυτό το παιδί

Αλλά τα Releases δεν έγιναν update

 

Για να σβήσω το branch, δεν αρκεί να κάνω pull το blessed/master και κατόπιν να το κάνω push στο origin/master?

 

Ή πρέπει πρώτα να σβήσω το branch manually και locally και στο origin, και κατόπιν να κάνω pull locally το blessed/master?

[imitheos]

Είναι πολύ γρήγορο αυτό το παιδί

Αλλά τα Releases δεν έγιναν update

Η pull request του github ενημερώνει τον maintainer για μια σειρά από commits που έχεις κάνει και θέλεις να περάσει. Ίσως κάνω λάθος αλλά δεν νομίζω να τον ενημερώνει για τυχόν tags που έχεις.

 

Άσχετο αλλά το tag το έκανες στο commit e3394da (Added next-move κτλ) αντί στο commit e218a11 (Version Bump).

 

Ή πρέπει πρώτα να σβήσω το branch manually και locally και στο origin, και κατόπιν να κάνω pull locally το blessed/master?

Αυτός είναι ένας τρόπος να το κάνεις απλά όταν πας να σβήσεις το branch χωρίς να έχεις κάνει pull το blessed, θα σου πει ότι τα commits του branch δεν περιέχονται πουθενά αλλού και δεν θα σε αφήσει να το σβήσεις (ή θα σε ρωτήσει αν είσαι σίγουρος δεν ξέρω τι κάνει το tortoise).

 

Για να σβήσω το branch, δεν αρκεί να κάνω pull το blessed/master και κατόπιν να το κάνω push στο origin/master?

Οτιδήποτε κάνεις σε κάποιο branch δεν επηρεάζει αυτόματα άλλα branches. Όταν κάνεις pull το blessed και μετά το κάνεις push στο github, φέρνεις το github σου στη τελευταία κατάσταση του geomaga. Αυτό δεν σημαίνει ότι θα σβηστεί αυτόματα το άλλο σου branch. Θα πρέπει εσύ να το σβήσεις.

[migf1]

Άσχετο αλλά το tag το έκανες στο commit e3394da (Added next-move κτλ) αντί στο commit e218a11 (Version Bump).

Πάνω που σκεφτόμουν: "μωρέ μπράβο μου, ούτε μια βλακεία δεν έκανα;"

 

Τα υπόλοιπα τα έκανα τελικά manually ως εξής:

 

Locally:

1. Έκανα switch από το branch στο master

2. Έσβησα το branch (μου είπε πως περιέχει unmerged stuff κλπ, αλλά του είπα διώχτο-διώχτο )

3. Έκανα pull το blessed/master

 

Github:

1. Έσβησα manually το branch

 

Locally:

1. Έκανα push από local/master σε origin/master

 

Δείχνει να λειτούργησε as expected.

[imitheos]

Locally:

1. Έκανα switch από το branch στο master

2. Έσβησα το branch (μου είπε πως περιέχει unmerged stuff κλπ, αλλά του είπα διώχτο-διώχτο )

3. Έκανα pull το blessed/master

 

Github:

1. Έσβησα manually το branch

 

Locally:

1. Έκανα push από local/master σε origin/master

 

Δείχνει να λειτούργησε as expected.

Αν κάνεις 1->3->2 δεν θα σου πει για unmerged stuff επειδή θα έχουν μπει τα commits στο master σου. Όσον αφορά το σβήσιμο του branch στο github θα πρέπει σίγουρα να γίνεται και "locally" κατευθείαν από το tortoise.

 

Κατά τα άλλα καλά μου φαίνονται σαν βήματα.

 

Edit: Εδώ βλέπουμε ένα αρχείο από το repo του OpenBSD. Επέλεξα κατά τύχη το Makefile. Η πρώτη του γραμμή είναι η εξής:

 

#	$OpenBSD: Makefile,v 1.122 2014/07/09 19:23:28 espie Exp $

Διαβάζοντας το εγχειρίδιο του CVS και συγκεκριμένα την παράγραφο που μιλάει για Keyword Substitution βλέπουμε πως έχοντας στο αρχείο την έκφραση "$Id$", αυτή θα μεταφράζεται αυτόματα σε κάθε commit σε αυτό που βλέπουμε παραπάνω.

 

Όπως είπα και σε προηγούμενο μήνυμα, αυτό στα σύγχρονα DVCS δεν γίνεται. Γιατί το είπα όμως αυτό θα μου πεις.

 

Αν έχεις γράψει κάποιο scriptάκι που δίνοντας του έκδοση για παράμετρο, ψάχνει σε όλα τα αρχεία και όπου βρει το "Version:" του βάζει αυτή τη νέα έκδοση και όπου βρει "Date:" βάζει την τρέχουσα ημερομηνία, ή γενικά παράγει το παρακάτω και αυτόματα το εισάγει στην αρχή κάθε αρχείου, τότε πάω πάσο.

 

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

 

/****************************************************************
 * This file is part of the "2048cc" game.
 *
 * Author:       migf1 <[email protected]>
 * Version:      0.3a3
 * Date:         July 11, 2014
 * License:      Free Software (see comments in main.c for limitations)
 * Dependencies: common.h, board.h
 * --------------------------------------------------------------
 *
 ****************************************************************
 */

Επεξ/σία 11 Ιουλίου 2014 από imitheos

[migf1]

Αν εννοείς ότι θα με δυσκολέψει στο editing, δεν υπάρχει πρόβλημα. 2 απλά Search & Replace είναι σε όλα τα αρχεία του project (ένα για την version, κι ένα για την date).

[pmav99]

Λογικά θα γίνεται να αυτοματοποιηθεί με κάποιο pre-commit hook στο git

[imitheos]

Έκανα μια pull request στον geomagas και πρέπει να την δει και εσύ. Δεν ξέρω αν παρακολουθείς το repo του οπότε γράφω και εδώ.

 

Αυτά που έχει η request είναι τα εξής:

 

1) Άλλαξα τον τύπο της my_sleep_msecs από uint σε ulong. Ο ορισμός της συνάρτησης χρησιμοποιεί ulong καθώς και η συνάρτηση tui_sleep (που είναι το μόνο σημείο που την χρησιμοποιείς) χρησιμοποιεί και αυτή ulong. Παρόλα αυτά το prototype είχε uint. Με βάση τα παραπάνω υπέθεσα ότι το σωστό ήταν ulong.

 

2) Έσβησα το MY_C macro. Δεν μπορώ να καταλάβω τι χρησιμότητα έχει. Ορίζεις τα prototypes μόνο αν ifndef MY_C. Όλα τα αρχεία που εισάγουν το header δεν ορίζουν το MY_C εκτός από το my.c. Δηλαδή θέλεις να μην ορίζονται τα prototypes στο my.c ? Γιατί ?

 

3) Πήγα τον έλεγχο για __linux__ πριν το __unix__ γιατί έτσι όπως ήταν δεν θα έτρεχε ποτέ μια και στο linux ορίζεται και το __unix__. Για την ώρα δεν έχει κάποια αξία μια και ο κώδικας για unix και linux είναι ίδιος αλλά έτσι είναι τυπικά πιο σωστό.

 

4) Έκανα split τις "portable" functions σε os specific αρχεία.

#if defined (linux)
#define MY_LINUX
#elif defined (win)
#define MY_WIN

return_type function_name(parameters) {
        #if defined(MY_LINUX)
                Ένα κάρο γραμμές για linux;
        #elif defined(MY_WIN)
                Ένα κάρο γραμμές για win;
        #else
                Fallback γραμμές για άγνωστα συστήματα;
        #endif
    }

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

 

Η μορφή πλέον είναι η εξής:

#if defined (linux)
#include "os-linux.c"

και στο os-linux.c υπάρχει

return_type function_name(parameters) {
     Ένα κάρο γραμμές για linux;
}

Έτσι ο έλεγχος γίνεται μόνο σε ένα σημείο το οποίο μου επέτρεψε να αφαιρέσω τα περιττά MY_τάδε και επίσης η κάθε συνάρτηση είναι μικρότερη και περιέχει μόνο τον κώδικα που πρέπει. Έτσι ο X dev μπορεί να επεξεργαστεί την Ψ εκδοχή της συνάρτησης χωρίς να του αποσπά την προσοχή άσχετος κώδικας.

 

Πιστεύω ότι αυτή είναι καλύτερη πρακτική αλλά εκτός ότι είναι υποκειμενικό και μπορεί να μην σου αρέσει, αν γίνει merge θα πρέπει να αλλάξει και η οδηγία "gcc *.c" που δίνει το readme.

 

5) Έγραψα λίγα σχόλια για το τι κάνουν τα VTIME, VMIN που είχες απορία.

 

Όταν δεν βαριέμαι θα αλλάξω το unix κομμάτι να χρησιμοποιεί ncurses ώστε να φύγουν εκείνα τα 300 κακάσχημα memcmp.

 

Δες την pull request και αν διαφωνείς πες τον geomagas να την κάνει reject.

[migf1]

Καλημέρα!

 

Καμία αντίρρηση δεν έχω στα points 1,3,5. Ίσα-ίσα που είναι well-thought και on-the-spot (many thanks).

 

To 2 (που btw ως πρακτική το ακολουθώ σε όλα τα source-modules) δεν είναι πρακτική ουσίας, αλλά ένα σημειολογικό convention που ακολουθώ για να είναι ξεκάθαρο πως οι συγκεκριμένες συναρτήσεις ΔΕΝ προορίζονται ως external για το source-module στο οποίο ορίζονται, αλλά για οποιοδήποτε άλλο (αυτονόητο μεν, αλλά πάει πακέτο με το ότι αποφεύγω επίσης να δηλώνω function prototypes μέσα στα source modules).

 

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

 

Για το 4, η καλή πρακτική είναι φυσικά αυτή που προτείνεις στο pull-request. Απλά όπως σημείωσες κι εσύ, πλέον το compilation χρειάζεται configuration-tools τα οποία δυστυχώς διαφέρουν από compiler σε compiler. Και πάλι δεν έχω αντίρρηση, αλλά με την προϋπόθεση να το συνοδεύσουμε και με τις κατάλληλες compilation οδηγίες+αρχεία τουλάχιστον για 1-2 δημοφιλείς compilers σε κάθε υποστηριζόμενη πλατφόρμα (win, unix, linux, osx). Τι λέτε κι εσείς;

 

Κάτι άλλο τώρα. Θέλετε να δοκιμάσουμε την πρόταση του geomagas για την αυτονόμηση των ui (δηλαδή το game-loop embed μέσα στο ui), έτσι ώστε να έχουμε έτοιμο το codebase για όποιον θελήσει να φτιάξει ui της προκοπής?

 

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

 

EDIT:

 

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

EDIT2:

 

Και κάτι ακόμα (ένα-ένα μου έρχονται). Δεν ξέρω πως προέκυψαν αρχεία με διαφορετικά EOL μέσα στο project. Κατά πάσα πιθανότητα, σε κάποια  πέρα-δώθε που έκανα στο project μεταξύ windows & ubuntu για διάφορες δοκιμές.

 

Τα αρχεία των replays όμως υποτίθεται πως δημιουργούνται συνειδητά με CRLF από τις serialization ρουτίνες (εκείνες που τελειώνουν σε _to_text()... το αρχείο ανοίγεται συνειδητά σε binary mode, και κατόπιν στα τέλη των γραμμών αποθηκεύεται η ακολουθία "\r\n").

 

Κατόπιν, για εσωτερικό processing μέσα στο game, η συνάρτηση s_fixeol() (στο common.c) που χρησιμοποιούν οι deserialization κλήσεις της _load_stack_from_fp_line() (στο mvhist.c) αναλαμβάνει να μετατρέψει τα EOL στο φορμά της πλατφόρμας που έχει γίνει το compilation (λέω στα comments της πως περιμένει CRLF στο s, αλλά είναι outdated comment... π.χ. σε Windows, αν το EOL δεν είναι CRLF μετατρέπεται σε LF... για αυτό δουλεύουν και με LF στα τέλη τους και σε Windows τα replay-files).

 

Οπότε, δεν έχω ιδέα πως προέκυψαν replay-files αποθηκευμένα με σκέτο LF τα τέλη των γραμμών τους... κάποιο bug ίσως;

[imitheos]

Καλημέρα!

 

Καμία αντίρρηση δεν έχω στα points 1,3,5. Ίσα-ίσα που είναι well-thought και on-the-spot (many thanks).

Οπότε να ακυρώσω την request (ή ίσως να πρέπει να την ακυρώσει ο geomagas) και να κάνεις cherry-pick ή όπως το ονομάζει το tortoise αυτά τα commits.

 

To 2 (που btw ως πρακτική το ακολουθώ σε όλα τα source-modules) δεν είναι πρακτική ουσίας, αλλά ένα σημειολογικό convention που ακολουθώ για να είναι ξεκάθαρο πως οι συγκεκριμένες συναρτήσεις ΔΕΝ προορίζονται ως external για το source-module στο οποίο ορίζονται, αλλά για οποιοδήποτε άλλο (αυτονόητο μεν, αλλά πάει πακέτο με το ότι αποφεύγω επίσης να δηλώνω function prototypes μέσα στα source modules).

 

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

Οκ άφησε το τότε. Δεν ήταν και τόσο πρόβλημα απλά πρώτη φορά βλέπω κάτι τέτοιο και μου φάνηκε παράξενο. Το μόνο κακό που δημιουργούσε ήταν να κρύψει την ασυνέπεια που ανέφερα στο 1. Τουλάχιστον ο gcc έβγαλε πρόβλημα για conflicting ορισμούς μόνο όταν το αφαίρεσα και έτσι βρήκε το prototype στην ίδια μονάδα με το definition.

 

Για το 4, η καλή πρακτική είναι φυσικά αυτή που προτείνεις στο pull-request. Απλά όπως σημείωσες κι εσύ, πλέον το compilation χρειάζεται configuration-tools τα οποία δυστυχώς διαφέρουν από compiler σε compiler. Και πάλι δεν έχω αντίρρηση, αλλά με την προϋπόθεση να το συνοδεύσουμε και με τις κατάλληλες compilation οδηγίες+αρχεία τουλάχιστον για 1-2 δημοφιλείς compilers σε κάθε υποστηριζόμενη πλατφόρμα (win, unix, linux, osx). Τι λέτε κι εσείς;

Έτσι και αλλιώς Makefile χρησιμοποιούσα αλλά δεν ξέρω αν θα πρέπει να αλλάξει κάτι για mingw και τι άλλα build systems χρειάζονται. Στο .gitattributes έβαλα πρόνοια για αρχεία του Visual Studio που πρέπει να έχουν CRLF (είδα τις καταλήξεις από το repo το defacer που περιείχε build files για VS) οπότε μπορούν να προστεθούν κατευθείαν.

 

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

Δεν ασχολούμαι με τέτοια WTFPL

 

Και κάτι ακόμα (ένα-ένα μου έρχονται). Δεν ξέρω πως προέκυψαν αρχεία με διαφορετικά EOL μέσα στο project. Κατά πάσα πιθανότητα, σε κάποια  πέρα-δώθε που έκανα στο project μεταξύ windows & ubuntu για διάφορες δοκιμές.

 

 

Τα αρχεία των replays όμως υποτίθεται πως δημιουργούνται συνειδητά με CRLF από τις serialization ρουτίνες (εκείνες που τελειώνουν σε _to_text()... το αρχείο ανοίγεται συνειδητά σε binary mode, και κατόπιν στα τέλη των γραμμών αποθηκεύεται η ακολουθία "\r\n").

 

Κατόπιν, για εσωτερικό processing μέσα στο game, η συνάρτηση s_fixeol() (στο common.c) που χρησιμοποιούν οι deserialization κλήσεις της _load_stack_from_fp_line() (στο mvhist.c) αναλαμβάνει να μετατρέψει τα EOL στο φορμά της πλατφόρμας που έχει γίνει το compilation (λέω στα comments της πως περιμένει CRLF στο s, αλλά είναι outdated comment... π.χ. σε Windows, αν το EOL δεν είναι CRLF μετατρέπεται σε LF... για αυτό δουλεύουν και με LF στα τέλη τους και σε Windows τα replay-files).

 

Οπότε, δεν έχω ιδέα πως προέκυψαν replay-files αποθηκευμένα με σκέτο LF τα τέλη των γραμμών τους... κάποιο bug ίσως;

% cd /tmp 
% git clone git://github.com/migf1/2048cc
Cloning into '2048cc'...
remote: Counting objects: 136, done.
remote: Compressing objects: 100% (122/122), done.
remote: Total 136 (delta 68), reused 80 (delta 12)
Receiving objects: 100% (136/136), 673.97 KiB | 217.00 KiB/s, done.
Resolving deltas: 100% (68/68), done.
Checking connectivity... done
% cd 2048cc 
% file replays/*
replays/1024.sav:     ASCII text, with CRLF line terminators
replays/6x6_lost.sav: ASCII text
replays/8x8_more.sav: ASCII text
% file src/*
src/common.h:            C source, ASCII text, with CRLF, LF line terminators
src/mvhist.c:            C source, ASCII text, with CRLF, LF line terminators

Εφόσον κάνεις pull το tree του geomagas, θα πρέπει από εδώ και πέρα όλα να δουλεύουν τζάμι. Το μόνο που θα χρειαστεί είναι να αλλαχτούν τα replays.

 

# Visual Studio build files should always have CRLF
*.sln text eol=crlf
*.vcproj text eol=crlf
*.vcxproj text eol=crlf
*.vcproj.filters text eol=crlf
*.vcxproj.filters text eol=crlf

Αν δεις το αρχείο .gitattributes, στο τέλος έχει το παραπάνω τμήμα. Αυτό λέει στο git ότι αντιμετώπισε τα αρχεία του VS σαν text αλλά πάντα πρέπει να τα κάνεις checkout με CRLF. Προσθέτεις μια νέα γραμμή που να λέει "replays/*.sav text eol=crlf" και το κάνεις add στο repo. Πριν κάνεις commit όμως πρέπει να πειράξεις και τα ίδια τα αρχεία γιατί το git δεν πειράζει αρχεία που δεν έχουν αλλαχτεί με κάποιο commit.

 

Άκυρο το έκανα και το στέλνω στον geomagas.

Επεξ/σία 13 Ιουλίου 2014 από imitheos

[imitheos]

Μια και γύρισα νωρίτερα, ας δούμε κάποιους από τους τρόπους που μπορεί να γίνει αυτό που είπαμε πριν.

 

1) Cherry Pick

% git co -b migf1-approved master

Δημιουργώ ένα νέο branch με βάση το master μου (δεν έχει δηλαδή τις αλλαγές που έκανε στο restructure branch) και αλλάζω σε αυτό.

 

% git log --oneline --reverse master..myc-restructure
2ad6ecb Fix my_sleep_msecs argument type
e373134 Remove MY_C macro
fd9815f Check for linux before unix
0d33935 Split functions into OS specific files
ae80ef7 Document VMIN and VTIME

Βλέπω εν συντομία τα commits που έχει το branch με αύξουσα χρονική σειρά. Από αυτά θέλω να περάσω μόνο τα 2ad6ecb, fd9815f και ae80ef7.

 

% git cherry-pick 2ad6ecb fd9815f ae80ef7
[migf1-approved 5e3b215] Fix my_sleep_msecs argument type
 1 file changed, 1 insertion(+), 1 deletion(-)
[migf1-approved e3cb6f8] Check for linux before unix
 1 file changed, 5 insertions(+), 5 deletions(-)
error: could not apply ae80ef7... Document VMIN and VTIME
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

Όπως βλέπουμε, ένα-ένα τα commits εφαρμόζονται στο branch. Το τρίτο commit δεν μπόρεσε να εφαρμοστεί γιατί υπάρχει κάποια διένεξη. Η περιγραφή των VMIN, VTIME έγινε από μέρους μου στο αρχείο os-unix.c το οποίο όμως δεν υπάρχει γιατί δεν εφάρμοσα το commit που το δημιουργούσε. Έτσι πρέπει να υπάρχει χειροκίνητη επίλυση της διένεξης για να συνεχίσει η διαδικασία.

 

% git cherry-pick --continue
% git log --oneline --reverse master..migf1-approved  
5e3b215 Fix my_sleep_msecs argument type
e3cb6f8 Check for linux before unix
c8901f3 Document VMIN and VTIME

Μετά την επίλυση της διένεξης, το νέο branch περιέχει μόνο τα commits που πρέπει. Παρατηρούμε ότι το αναγνωριστικό τους έχει αλλάξει. Αυτό γίνεται γιατί ουσιαστικά είναι διαφορετικά commits λόγω ότι έχουν διαφορετικό parent και διαφορετική ώρα που δημιουργήθηκαν.

 

Τώρα μπορώ να δημιουργήσω ένα νέο commit που να μετατρέπει τα replay files σε CRLF και να στείλω το νέο branch στον geomagas.

 

2) Interactive Rebase.

 

Η rebase είπαμε ότι είναι από τις πιο δυνατές εντολές και μας επιτρέπει να κάνουμε ένα σωρό πράγματα. Μία από τις δυνατότητες της είναι η διαδραστική λειτουργία.

 

% git co myc-restructure
Switched to branch 'myc-restructure'
% git rebase --interactive master

Αλλάζω στο branch που θέλω να δουλέψω και του λέω ποια commits θέλω να πειράξω. Το commit που δίνω θα πρέπει να είναι ένα πριν από το πρώτο που θέλω να πειράξω. Εδώ έχω δηλώσει master που (αυτή τη στιγμή) είναι το commit από το οποίο ξεκίνησε το branch μου (οπότε και ένα πριν από αυτό που θέλω να ξεκινήσω).

 

pick 2ad6ecb Fix my_sleep_msecs argument type
pick e373134 Remove MY_C macro
pick fd9815f Check for linux before unix
pick 0d33935 Split functions into OS specific files
pick ae80ef7 Document VMIN and VTIME

# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.

Μου ανοίγει ο editor και παίρνω ένα παράθυρο που μεταξύ άλλων αναφέρει τα παραπάνω. Μου λέει ότι τα commits που θέλω να πειράξω είναι τα παραπάνω και μου έχει από τη μάνα του τη λέξη pick σε κάθε commit. Αν εγώ θέλω σε ένα commit να προσθέσω κάτι που είχα ξεχάσει μπορώ να του αλλάξω το pick σε edit ώστε πριν το περάσει να με περιμένει να το πειράξω.

 

Μια συνήθης χρήση της interactive λειτουργίας είναι η squash. Παλαιότερα στα centralized VCS (όπως το CVS και το Subversion) συνηθιζόταν να κρατούν τις αλλαγές οι devs και να κάνουν τεράστια commits με άσχετες μεταξύ τους αλλαγές. Αυτό φυσικά δεν ήταν καλή πρακτική αλλά γινόταν αναγκαστικά επειδή αργούσε πολύ το commit (ή και επειδή βρίσκονταν σε αεροπλάνο - τρένο - κάπου χωρίς δίκτυο). Στα DVCS όλες οι λειτουργίες γίνονται τοπικά και έτσι ταχύτατα οπότε προάγεται ένας διαφορετικός τρόπος δουλειάς με πολλά και σύντομα commits που το καθένα έχει ξεκάθαρο νόημα.

 

Όταν όμως τελειώσει η δουλειά του branch και είναι να γίνει push στο blessed repo, πολλά commits ίσως να μην έχουν πια νόημα για την ιστορία (δεν ενδιαφέρει κάποιον να δει 100 commits "fix typo" με μια σειρά αλλαγών). Σε αυτό έρχεται η δυνατότητα squash της rebase που σου επιτρέπει να ενώσεις πολλά commits σε ένα.

 

Σε αυτή τη περίπτωση η δουλειά που έχω να κάνω είναι πολύ απλή δηλαδή όπως με ενημερώνει η τελευταία γραμμή, θα σβήσω απλά τις γραμμές 2,4 των commits που δεν θέλω.

% git rebase --interactive master    [myc-restructure]
error: could not apply ae80ef7... Document VMIN and VTIME

When you have resolved this problem, run "git rebase --continue".

Όπως ήταν λογικό, και εδώ παίρνω την ίδια διένεξη. Αφού επιλύσω τη διένεξη τρέχω --continue και το branch μου έχει και πάλι τα commits που θέλω. Επειδή τα commits του branch μου έχουν αλλάξει είτε μπορώ να κάνω force push (που σε αυτή την περίπτωση δεν πειράζει αλλά γενικά δεν ενδείκνυται) είτε να δημιουργήσω ένα νέο branch πάνω σε αυτό και να το στείλω στον geomagas.

 

Edit: Έστειλα το νέο request.

[geomagas]

Merged.

 

Πως θα γίνει να σε ψήσουμε να γράψεις κάπου μία σειρά άρθρων για git;

 

BTW, το WTFPL δεν ξέρεις από τι διλήμματα με έβγαλε!

[imitheos]

Merged.

 

Πως θα γίνει να σε ψήσουμε να γράψεις κάπου μία σειρά άρθρων για git;

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

 

BTW, το WTFPL δεν ξέρεις από τι διλήμματα με έβγαλε!

Δεν ξέρω αν φταίει η δυσλεξία ή το έχουν πολλοί αυτό το πρόβλημα αλλά δεν μπορώ με τίποτα να κατανοήσω τα νομικίστικα (είτε αγγλικά είτε ελληνικά). Είναι όπως το "αγόρι, όχι κορίτσι" - "αγόρι όχι, κορίτσι".

 

Η license που χρησιμοποιώ είναι η ISC που χρησιμοποιεί το OpenBSD ακριβώς γιατί λέει το ίδιο με τις άλλες (BSD, MIT, κτλ) με πιο λίγα και πιο απλά λόγια. Και να φανταστείς ότι ακόμη και με αυτή υπήρξαν προβλήματα παρερμηνίας με αποτέλεσμα να αλλαχτεί το "and distribute" σε "and / or distribute".

 

/*
 * Copyright (c) CCYY YOUR NAME HERE <[email protected]>
 *
 * Permission to use, copy, modify, and distribute this software for any
 * purpose with or without fee is hereby granted, provided that the above
 * copyright notice and this permission notice appear in all copies.
 *
 * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
 * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
 * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
 * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
 * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 */

Αυτή που είναι πιο τέλεια ακόμη και από την WTFPL (η οποία δεν έχει no-warranty που θα μπορούσαμε να πούμε ότι χρειάζεται σε κώδικα) είναι η Fair.

 

Fair License (Fair)

<Copyright Information>

Usage of the works is permitted provided that this instrument is retained with the works, so that any entity that uses the works is notified of this instrument.

DISCLAIMER: THE WORKS ARE WITHOUT WARRANTY.

Τρεις λεξούλες και τέλος. Συγγνώμη προς τους δικηγόρους αναγνώστες του φόρουμ αλλά αν μπορούσα θα σας έδερνα όλους

[migf1]

Κι εμένα δεν μπορείτε να φανταστείτε πόσο μου τη σπάει όλη αυτή η μανούρα με τα licenses για free stuff. Στα δικά μου 3 πράγματα θέλω μόνο εγώ: να μην προσπαθήσουν να βγάλουν κέρδος, να τα διατηρούν free και να περιλαμβάνουν το original package σε όλα τα derivatives.

 

Λοιπόν, και το mingw toolchain δεν έχει πρόβλημα με τα makefiles (το αντίθετο) αλλά, για παράδειγμα το gnu-makefile που χρησιμοποιούν τα Linux από default δεν είναι το default make utility σε διάφορα unix distributions (το εκεί make καταλαβαίνει ένα ελαφρώς διαφορετικό φορμά των makefiles, από ότι θυμάμαι). Μετά, στα Windows π.χ. τόσο το VS όσο και η Pelles C έχουν δικά τους make-like utilities (και προφανώς δικά τους φορμά στα αντίστοιχα makefile τους). Σε OSX δεν έχω ιδέα τι παίζει (δεν έχω πρόσβαση).

 

Οπότε για να είμαστε cross-platform (όπως διαφημιζόμαστε ) δεν πρέπει να παράσχουμε οδηγίες και αντίστοιχα makefiles για τα δημοφιλή tοol-chains στις υποστηριζόμενες πλατφόρμες;

 

Παρεμπιπτόντως, το Visual Studio έχει πολύ ανάπηρη υποστήριξη σε C99, οπότε λογικά δεν πρέπει να γίνεται compile έτσι κι αλλιώς το 2048cc εκεί, άρα μάλλον δεν μας ενδιαφέρει και τι κάνει με τα EOL (αν και φυσικά είναι ωραίο που προστέθηκε σαν feature στο project).

 

Αυτό που δεν πολυ-έπιασα με τα EOL είναι το γιατί πρέπει να ξαναφτιαχτούν τα replay-files μετά το τελευταίο merge. Αφού υποτίθεται πως η s_fixeol() κάνει handle και τα 3 είδη των eol (\r\n, \n, \r).

 

Επίσης, προς μεγάλη μου απογοήτευση μόλις διαπίστωσα πως επιχειρώντας να κάνω Save ένα replay με πάρα πολλές κινήσεις (πάνω από 5500) προκαλεί failure της realloc()... γνώριζα πως ο τρόπος που κάνω τα save είναι τελείως inefficient αλλά ήλπιζα πως δεν θα είχε πρόβλημα... τώρα πρέπει να αλλάξω τον κώδικα, και λογικά θα το βάλω να κάνει save/load ανά chunks (πιο εύκολο στα λόγια, παρλα στην πράξη... αφού αναγκαστικά μπαίνει και η αναπαραγωγή των replays στο παιχνίδι... που πρέπει κι αυτή να προσαρμοστεί ανάλογα... καμια άλλη ιδεά ίσως; ).

 

EDIT:

 

On a 2nd thought, @@ κάνει handle η s_fixeol()... θα την αλλάξω ως εξής και θα κάνω pull-request. Ρίξτε μια ματιά μήπως έχω κάνει βλακεία πάλι (κι αν είναι ΟΚ να την στείλω στο blessed repo)...

 

/* WRONG
char *s_fixeol( char *s  )
{
	if ( NULL == s ) {
		DBGF( "%s", "NULL pointer argument!" );
		return s;
	}
#if defined( CC2048_OS_WINDOWS )

	if ( NULL == strstr(s, "\r\n") ) {
		return s_char_replace( s, '\r', '\n' );
	}

	return s;

#elif defined( CC2048_OS_UNIX ) || defined( CC2048_OS_LINUX )
	if ( strstr(s, "\r\n") ) {
		return s_char_replace( s, '\r', '\n' );
	}

	return s_strip( s, "\r" );

#elif defined( CC2048_OS_OSX )
	if ( strstr(s, "\r\n") ) {
		return s_char_replace( s, '\r', '\n' );
	}

	return s_strip( s, "\n" );

#else
	return s;
#endif
}
*/

ΥΓ. Ιδανικά θέλει μια συνάρτηση που να μπορεί να κάνει replace substrings αντί για σκέτα chars που κάνει η s_char_replace(), αλλά δεν έχω φτιαγμένη.

 

EDIT:

 

Μπα, άκυρη η συνάρτηση... θέλει να την δω με ησυχία (δεν μπορώ αυτή τη στιγμή).