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

[migf1]

Ωχ, εγώ το 'σβησα το εκτελέσιμο ε;

 

Βάλτο με συντομογραφία "2048cc" αντί για "2048 Console Clone" να έχουμε ευχέρεια μετά να το μεταφράσουμε αλλιώς αν αλλάξει... Cool Clone, Cumulative Clone, C Clone, δεν μου έρχονται άλλα τώρα

[geomagas]

Μ' αρέσει ο τρόπος που σκέφτεσαι! :D

 

Done! Για τις "επιπτώσεις", εδώ.

[migf1]

@imitheos:

 

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

 

Οπότε, να λέγαμε ας πούμε μια διαδικασία κάπως έτσι για τα local και forked repos του καθένα μας:

 

1. Pull blessed/master

2. Create & switch to new branch

3. Make changes

4. Add & Commit changes

5. Push branch to origin/ (our own fork)

6. Από github.com make a pull request to blessed/master for the new branch

 

Και την επόμενη φορά, όταν έχει γίνει accepted το branch μας...

 

0. Delete branch

1.

2.

...

6.

 

Πώς σας ακούγεται κάτι τέτοιο (ελπίζω να μην μου έχει ξεφύγει κάτι χτυπητό)

 

@geomagas: Εσύ είσαι πολύ γρήγορος

[geomagas]

@geomagas: Εσύ είσαι πολύ γρήγορος

 

Ε δεν ήταν και τίποτα... ενα google search και τρία clicks (και δύο keystrokes: "cc" )

[imitheos]

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

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

 

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

[migf1]

Λοιπόν, απορία 1η:

 

Πως γίνεται να βάλω διαφορετικά blobs (σημειώσεις) σε διαφορετικά αρχεία όταν κάνω commit?

 

Απορία 2η:

 

Στο.... "ανταγωνιστικό" Github project που έδωσε ο φίλος pmav99 (https://github.com/bfontaine/term2048) υπάρχει ένα Releases option, που άμα το πατήσουμε έχει ιστορικό όλων των versions μαζί με download links

https://github.com/bfontaine/term2048/releases. Πώς το κάνουμε αυτό;

 

Απορία 3η:

 

Έχω κάνει αλλαγές (σε branch) που αλλάζουν το φορμά των replays, άρα θέλω να δηλώσω στον geomagas πως αυτές οι αλλαγές θα πρέπει να χαρακτηριστούν ως νέο version (στην προκειμένη περίπτωση σε 0.3a3 ... έβαλα να δείχνει και την επόμενη κίνηση στα replays). Τι πρέπει να κάνω πριν του στείλω pull request?

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

[pmav99]

1. Διαφορετικά commits?

 

2. Είναι τα tags

[imitheos]

Λοιπόν, απορία 1η:

 

Πως γίνεται να βάλω διαφορετικά blobs (σημειώσεις) σε διαφορετικά αρχεία όταν κάνω commit?

Δεν κατάλαβα τι εννοείς εδώ. Ένα commit μπορεί να περιέχει όσα αρχεία (και καταλόγους) θέλεις.

 

% echo blob1 > file1
% echo blob2 > file2
% git add file1 file2
% git commit -m "a commit containing two files"

Απορία 2η:

 

Στο.... "ανταγωνιστικό" Github project που έδωσε ο φίλος pmav99 (https://github.com/bfontaine/term2048) υπάρχει ένα Releases option, που άμα το πατήσουμε έχει ιστορικό όλων των versions μαζί με download links (https://github.com/bfontaine/term2048/releases). Πώς το κάνουμε αυτό;

Το git σου παρέχει μια μαγκιά που λέγεται tag. Όταν το project σου φτάσει σε κάποιο σημείο, μαρκάρεις το συγκεκριμένο commit με μία tag δηλαδή ένα συμβολικό όνομα που περιγράφει το project σε εκείνο το σημείο. Η πιο συνήθης χρήση των tags είναι για να δηλώνουν versions.

 

% cd linux-bare.git
% git show v3.15
tag v3.15
Tagger:     Linus Torvalds <[email protected]>
TaggerDate: Sun Jun 8 11:20:02 2014 -0700

Linux 3.15

commit 1860e379875dfe7271c649058aeddffe5afd9d0d
Author:     Linus Torvalds <[email protected]>
AuthorDate: Sun Jun 8 11:19:54 2014 -0700
Commit:     Linus Torvalds <[email protected]>
CommitDate: Sun Jun 8 11:19:54 2014 -0700

    Linux 3.15

Η tag "v3.15" ισοδυναμεί με το στιγμιότυπο του πυρήνα όπως αυτό αντικατοπτριζόταν στο commit 1860e379.

 

Το github εδώ και κάποιο διάστημα σου δίνει τη δυνατότητα των "releases". Μπορεί να σου zipάρει την συγκεκριμένη tag (ή και να κάνεις compile το πρόγραμμά σου, να πάρεις το binary και να το πετάξεις και αυτό μέσα). Μπορούν να χρησιμοποιηθούν και ανεξάρτητα από τις git tags αλλά συνήθως έτσι δουλεύονται.

 

Δουλεύεις το cli του git, κάποιο gui frontend του ή το ui του github ? Δοκίμασες να δημιουργήσεις κάποιο annotated tag και μετά να κάνεις push στο github ?

 

Απορία 3η:

 

Έχω κάνει αλλαγές (σε branch) που αλλάζουν το φορμά των replays, άρα θέλω να δηλώσω στον geomagas πως αυτές οι αλλαγές θα πρέπει να χαρακτηριστούν ως νέο version (στην προκειμένη περίπτωση σε 0.3a3 ... έβαλα να δείχνει και την επόμενη κίνηση στα replays). Τι πρέπει να κάνω πριν του στείλω pull request?

Δες απορία 2 για τις tags

[migf1]

Δουλεύω με το TortoiseGit, το οποίο όπως έγραψα προχτές το κατέβασα στον επιτραπέζιο επειδή το Github for Windows σταμάτησε να δουλεύει με XP (ελέω requirement για .net έκδοσης μεγαλύτερης από την μέγιστη που υποστηρίζουν τα XP).

 

Αυτό που θέλω να κάνω είναι να κάνω ένα commit που θα το πω ας πούμε "version 0.3a3" (θα τα κοιτάξω τα tags, thanks) αλλά σε κάθε αρχείο που έχει αλλαχτεί να περιέχονται διαφορετικά descriptions, π.χ.

gs.c "added netxmv field in gamestate, adopted (de)serialization routines"

tui.c "shows next-move in replays"

readme.md "adopted to version 0.3a3"

mvhist.c "comments adopted to v0.3a3"

κλπ κλπ

 

Από ότι κατάλαβα μάλλον δεν γίνεται, και πρέπει να κάνω διαφορετικά commits, όπως είπε ο pmav99. Aλλά αυτό είναι πρόβλημα... π.χ. σε όλα *.c αρχεία αναγράφεται η centralized έκδοσή του game σε comments στην αρχή... όταν το tui.c έχει KAI την αλλαγή που περιγράφω παραπάνω πως θα διαχωρίσω τα commits μεταξύ mvhist.c και των υπόλοιπων; Θα κάνω π.χ 1 commit που θα λέει "comments adopted to v0.3a3" σε όλα τα αρχεία, και μετά θα κάνω commit π.χ. το tui.c με comment "shows next-move in replays" το οποίο όμως δεν θα έχει καμία διαφορά από το προηγούμενο commit?

[imitheos]

Αυτό που θέλω να κάνω είναι να κάνω ένα commit που θα το πω ας πούμε "version 0.3a3" (θα τα κοιτάξω τα tags, thanks) αλλά σε κάθε αρχείο που έχει αλλαχτεί να περιέχονται διαφορετικά descriptions, π.χ.

gs.c "added netxmv field in gamestate, adopted (de)serialization routines"

tui.c "shows next-move in replays"

readme.md "adopted to version 0.3a3"

mvhist.c "comments adopted to v0.03a3"

κλπ κλπ

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

 

Υλοποίηση UI

 

Προστέθηκε μια πρώτη σχεδίαση του UI. Επιμέρους αλλαγές:

 

gs.c "added netxmv field in gamestate, adopted (de)serialization routines"

tui.c "shows next-move in replays"

Αυτό όμως έχει το "πρόβλημα" ότι οι επιμέρους αλλαγές δεν θα φαίνονται στο tree view του github (πχ εδώ). Το github εμφανίζει ως λόγο αλλαγής του αρχείου, τον τίτλο του πιο πρόσφατου commit στο οποίο έχει αλλαχτεί το αρχείο οπότε για να εμφανίζονται εκεί οι επιμέρους αλλαγές του κάθε αρχείου, θα πρέπει αυτές να είναι ξεχωριστό commit.

 

Aλλά αυτό είναι πρόβλημα... π.χ. σε όλα *.c αρχεία αναγράφεται η centralized έκδοσή του game σε comments στην αρχή... όταν το tui.c έχει KAI την αλλαγή που περιγράφω παραπάνω πως θα διαχωρίσω τα commits μεταξύ mvhist.c και των υπόλοιπων; Θα κάνω π.χ 1 commit που θα λέει "comments adopted to v0.3a3" σε όλα τα αρχεία, και μετά θα κάνω commit π.χ. το tui.c με comment "shows next-move in replays" το οποίο όμως δεν θα έχει καμία διαφορά από το προηγούμενο commit?

Το cvs υποστήριζε κάποια ειδικά headers στην αρχή των αρχείων τα οποία άλλαζαν αυτόματα με κάθε commit και έτσι μπορούσες να έχεις την έκδοση σε κάθε αρχείο. Στα DVCS λόγω του τρόπου που δουλεύουν δεν υποστηρίζεται αυτό γιατί θα εμπόδιζε το merging.

 

Αυτό που γίνεται συνήθως και μπορείς να κάνεις είναι όχι να κάνεις ένα commit με όλες τις αλλαγές και μετά ένα άδειο commit αλλά θα κάνεις κανονικά το commit σου με τίτλο "shows next-move in replays" το οποίο θα περιέχει τις αλλαγές που αναφέρει ο τίτλος του. Την version δεν την πειράζεις καθόλου.

 

Μετά κάνεις ένα άλλο commit με τίτλο "Version Bump" το οποίο πειράζει όλα τα αρχεία και αλλάζει την έκδοση στην καινούρια. Αυτό το commit το κάνεις και tag οπότε έχεις την release σου.

 

Edit: Αν έχεις κάνει ήδη τις αλλαγές και έχεις άσχετες μεταξύ τους αλλαγές, μπορείς να εκμεταλλευτείς το index του git.

 

diff --git a/src/board.c b/src/board.c
index fa40c4a..16437ee 100644
--- a/src/board.c
+++ b/src/board.c
@@ -2,7 +2,7 @@
  * This file is part of the "2048 Console Clone" game.
  *
  * Author:       migf1 <[email protected]>
- * Version:      0.3a2
+ * Version:      0.3a3
  * Date:         July 9, 2014
  * License:      Free Software (see comments in main.c for limitations)
  * Dependencies: common.h, board.h
@@ -20,7 +20,7 @@
 #include "board.h"
 
 /* Macro for indexing the grid of the board (it's an 1D buffer). */
-#define _IDX(i,j,ncols)    ( (i) * (ncols) + (j) )
+#define _IDX(i,j,ncols)    ( (i) * (ncols) + (j) + 1)
 
 /* Validation macro for the supported single-dimensions of a board.
  * They are defined in "board.h".

Ας υποθέσουμε ότι έχω κάνει τις παραπάνω αλλαγές. Την ώρα που είχα αλλάξει τις εκδόσεις σε όλα τα αρχεία, βλέπω ότι έχω κάνει ένα λάθος και στο IDX έπρεπε να βάλω +1 (δεν είναι λάθος φυσικά αλλά αυτό μου ήρθε να πειράξω ).

 

Τώρα πως θα γίνει ? Θα κάνω όπως είπες commit τις εκδόσεις και μετά θα κάνω ένα commit που θα είναι κενό και θα έχει τίτλο "Fix off by one" ? Όχι βέβαια.

 

Το git σε αντίθεση με άλλα DVCS έχει την έννοια του index (αλλιώς staging area) η οποία σε βοηθάει σε τέτοιες περιπτώσεις. Όταν κάνεις commit δεν κάνεις το αλλαγμένο περιεχόμενο του tree σου αλλά μόνο ότι έχεις εισάγει στο index.

 

Σίγουρα θα το έχεις δει αυτό σε επίπεδο αρχείων. Έχεις δηλαδή 15 αλλαγμένα αρχεία και κάνεις add -> commit μόνο τα 3. Αυτό όμως γίνεται και μέσα στο ίδιο αρχείο.

 

Στη παραπάνω περίπτωση δηλαδή, αντί να κάνω "git add src/board.c" θα χρησιμοποιήσω την interactive κατάσταση τρέχοντας "git add -p src/board.c".

% git add -p src/board.c                                                                                                                                                                                  [master U]
diff --git a/src/board.c b/src/board.c
index fa40c4a..16437ee 100644
--- a/src/board.c
+++ b/src/board.c
@@ -2,7 +2,7 @@
  * This file is part of the "2048 Console Clone" game.
  *
  * Author:       migf1 <[email protected]>
- * Version:      0.3a2
+ * Version:      0.3a3
  * Date:         July 9, 2014
  * License:      Free Software (see comments in main.c for limitations)
  * Dependencies: common.h, board.h
Stage this hunk [y,n,q,a,d,/,j,J,g,e,?]? n
@@ -20,7 +20,7 @@
 #include "board.h"
 
 /* Macro for indexing the grid of the board (it's an 1D buffer). */
-#define _IDX(i,j,ncols)    ( (i) * (ncols) + (j) )
+#define _IDX(i,j,ncols)    ( (i) * (ncols) + (j) + 1)
 
 /* Validation macro for the supported single-dimensions of a board.
  * They are defined in "board.h".
Stage this hunk [y,n,q,a,d,/,K,g,e,?]? y

Πρόσεξε τα μηνύματα "Stage this hunk". Πέρασα στο index μόνο το 2ο hunk οπότε μόνο εκείνο θα είναι μέρος του commit.

 

% git commit -m "Fix off by one"
[master 784cf3f] Fix off by one
 1 file changed, 1 insertion(+), 1 deletion(-)
% git show
commit 784cf3fb2f690e60ea0ee2421a6769450375657c
Author:     Imitheos <[email protected]>
AuthorDate: Fri Jul 11 18:08:56 2014 +0300
Commit:     Imitheos <[email protected]>
CommitDate: Fri Jul 11 18:08:56 2014 +0300

    Fix off by one

diff --git a/src/board.c b/src/board.c
index fa40c4a..d72260b 100644
--- a/src/board.c
+++ b/src/board.c
@@ -20,7 +20,7 @@
 #include "board.h"
 
 /* Macro for indexing the grid of the board (it's an 1D buffer). */
-#define _IDX(i,j,ncols)    ( (i) * (ncols) + (j) )
+#define _IDX(i,j,ncols)    ( (i) * (ncols) + (j) + 1)^M
 
 /* Validation macro for the supported single-dimensions of a board.
  * They are defined in "board.h".

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

 

Μετά δημιουργείς κανονικά το άλλο commit που πειράζει την έκδοση σε όλα τα αρχεία.

% git add --update .
% git commit -m "Bump Version"
[master 88e0621] Bump Version
 1 file changed, 1 insertion(+), 1 deletion(-)
% git tag -a 0.3a3 -m ""

Τώρα αυτό το git add πέρασε στο index όλες τις υπόλοιπες αλλαγές δηλαδή την αλλαγή στις εκδόσεις. Οπότε κάνω και πάλι commit και μετά δημιουργώ και ένα annotated tag.

 

Η Interactive κατάσταση θα υποστηρίζεται σίγουρα κάπως και από το TortoiseGit.

[Radiant]

Δουλεύω με το TortoiseGit, το οποίο όπως έγραψα προχτές το κατέβασα στον επιτραπέζιο επειδή το Github for Windows σταμάτησε να δουλεύει με XP (ελέω requirement για .net έκδοσης μεγαλύτερης από την μέγιστη που υποστηρίζουν τα XP).

Άσχετος με το project αλλά επειδή πρόσφατα άρχισα να χρησιμοποιώ git ,μετά από αρκετό διάβασμα, δε νομίζω ότι χρειάζεσαι το github for windows. Καλύτερα να διαβάσεις το pro-git για να κατανοήσεις πως λειτουργεί το κάθε gui και σε ποιές εντολές αντοστοιχεί.(αν δε το εχεις κανει ηδη φυσικα)

 

 

http://git-scm.com/book

[migf1]

@imitheos:

 

Αχά, thanks! Αυτό που γράφεις στο τέλος θα κάνω (ελπίζω να βγει σωστό )

 

YG. Btw, στο github αν αφήσεις ακίνητο το ποντίκι πάνω σε ένα commit description, σου δείχνει και τα υπόλοιπα comments που δεν εμφανίζονται αρχικά.

 

@Radiant:

 

Το TortoiseGit προσπαθώ να μάθω εδώ και 1-2 μέρες. Δεν δείχνει κακό, καλό μου φαίνεται (αν και λίγο δύστροπο σε μερικά σημεία)

 

...

Σίγουρα θα το έχεις δει αυτό σε επίπεδο αρχείων. Έχεις δηλαδή 15 αλλαγμένα αρχεία και κάνεις add -> commit μόνο τα 3. Αυτό όμως γίνεται και μέσα στο ίδιο αρχείο.

...

Η Interactive κατάσταση θα υποστηρίζεται σίγουρα κάπως και από το TortoiseGit.

...

Το πρόβλημα είναι πως δεν είμαι εξοικειωμένος ούτε με το git ούτε με το cli του ούτε με το TortoiseGit. Το συγκεκριμένο παράδειγμα που αναφέρεις στο edit, δηλαδή να κάνεις επιλεκτικά Add το έχω δει, αλλά αφενός δεν μου εμφανίζει πάντα σχετική επιλογή (προφανώς κάποιον λόγο θα έχει, εγώ δεν τον ξέρω) κι αφετέρου δεν έχω βρει ακόμα πως κι εάν μπορώ να κάνω Remove κάποια previously added files.

[imitheos]

Το πρόβλημα είναι πως δεν είμαι εξοικειωμένος ούτε με το git ούτε με το cli του ούτε με το TortoiseGit. Το συγκεκριμένο παράδειγμα που αναφέρεις στο edit, δηλαδή να κάνεις επιλεκτικά Add το έχω δει, αλλά αφενός δεν μου εμφανίζει πάντα σχετική επιλογή (προφανώς κάποιον λόγο θα έχει, εγώ δεν τον ξέρω) κι αφετέρου δεν έχω βρει ακόμα πως κι εάν μπορώ να κάνω Remove κάποια previously added files.

Για να αφαιρέσεις από το index αρχεία, αυτό γίνεται με την εντολή git reset και είναι πάρα πολύ σημαντικό κομμάτι του git οπότε σίγουρα στο επιτρέπει το Tortoise και σίγουρα θα την έχει σε εύκολα προσβάσιμο σημείο χωρίς να χρειάζεται 30 κλικ.

 

Από εκεί και πέρα δεν μπορώ να βοηθήσω γιατί δεν έχω δει καν πως είναι οπτικά το TortoiseGit αφενός λόγω μη χρήσης Windows αφετέρου μια παραξενιά μου είναι να μην μπορώ να δουλέψω GUI σε τέτοιες εφαρμογές. Ειδικά σε κάτι όπως το git που έχει 500 υπό-εντολές με 30 παραμέτρους η καθεμία, τα frontends με δυσκολεύουν αντί να με ευκολύνουν. Πρέπει να ψάχνω σε τεράστια μενού να βρω την επιλογή που πρέπει να πατήσω για κάτι που μπορώ να τρέξω γράφοντας 10 γραμματάκια στο τερματικό

[migf1]

Καθόλου δεν σε αδικώ! Κι εγώ αν ήξερα το git από την γραμμή-εντολών θα το δούλευα δεν το συζητώ (εδώ δουλεύω τον gdb σε text-mode ). Αλλά μέχρι να δεήσω να εντρυφήσω στο git, τα GUI μου παρέχουν κάποιες σημαντικές ευκολίες για τα basics.

[migf1]

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

 

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