Merge pull request #33 from progit2-gr/cs/fix-monopati-diadromh

Cs/fix monopati diadromh

Author: csaragiotis

book/03-git-branching/sections/remote-branches.asc

@@ -16,7 +16,7 @@
 
 Ας τα ξεμπερδέψουμε όλα αυτά με ένα παράδειγμα. 
 Ας υποθέσουμε ότι έχουμε έναν διακομιστή Git στο δίκτυό μας στη διεύθυνση `git.ourcompany.com`.
-Αν τον κλωνοποιήσουμε, η εντολή `clone` του Git θα τον ονομάσει `origin`, θα έλξει όλα τα δεδομένα και θα δημιουργήσει έναν δείκτη που δείχνει εκεί που βρίσκεται ο κλάδος του `master` και θα τον ονομάσει τοπικά `origin/master`.
+Αν τον κλωνοποιήσουμε, η εντολή `clone` του Git θα τον ονομάσει `origin`, θα έλξει όλα τα δεδομένα και θα δημιουργήσει έναν δείκτη που δείχνει εκεί όπου βρίσκεται ο κλάδος του `master` και θα τον ονομάσει τοπικά `origin/master`.
 Το Git επισης μας δίνει τον δικό μας τοπικό κλάδο `master` που ξεκινά από το ίδιο σημείο που ξεκινά και ο κλάδος `master` του αποθετηρίου `origin`, ώστε να έχουμε κάτι πάνω στο οποίο να δουλέψουμε.
 
 [ΣΗΜΕΙΩΣΗ]
@@ -98,7 +98,7 @@ To https://github.com/schacon/simplegit
 Περισσότερες πληροφορίες σχετικά με τις διάφορες επιλογές προσωρινής αποθήκευσης διαπιστευτηρίων βλ. <<ch07-git-tools#_credential_caching>>.
 ====
 
-Την επόμενη φορά που κάποιος από τους συνεργάτες μας ανακτά από τον διακομιστή, θα πάρει μία αναφορά που θα δείχνει εκεί που βρίσκεται ο κλάδος `serverfix` του διακομιστή, δηλαδή κάτω από τον απομακρυσμένο κλάδο `origin/serverfix`:
+Την επόμενη φορά που κάποιος από τους συνεργάτες μας ανακτά από τον διακομιστή, θα πάρει μία αναφορά που θα δείχνει εκεί όπου βρίσκεται ο κλάδος `serverfix` του διακομιστή, δηλαδή κάτω από τον απομακρυσμένο κλάδο `origin/serverfix`:
 
 [source,console]
 ----

book/04-git-server/sections/protocols.asc

@@ -30,7 +30,7 @@ $ git clone file:///opt/git/project.git
 Αν καθορίσουμε ακριβώς τη διαδρομή, το Git προσπαθεί να χρησιμοποιήσει σκληρούς συνδέσμους (hardlinks) ή να αντιγράψει απευθείας τα αρχεία που χρειάζονται.
 Εάν καθορίσουμε το `file://`, το Git ενεργοποιεί τις διαδικασίες που συνήθως χρησιμοποιεί για τη μεταφορά δεδομένων μέσω δικτύου, μία μέθοδο μεταφοράς των δεδομένων γενικά πολύ λιγότερο αποτελεσματική.
 Ο βασικός λόγος που θα θέλαμε να χρησιμοποιήσουμε το `file://` είναι η περίπτωση κατά την οποία θέλουμε ένα καθαρό αντίγραφο του αποθετηρίου με εξωτερικές αναφορές ή αντικείμενα που απομένουν --συνήθως μετά από εισαγωγή από ένα άλλο σύστημα ελέγχου εκδόσεων ή κάτι παρόμοιο (βλ. <<_ git_internals>> για σχετικές εργασίες συντήρησης).
-Στη παρακάτω παράδειγμα θα χρησιμοποιήσουμε το μονοπάτι χωρίς το `file://` επειδή αυτό είναι σχεδόν πάντα πιο γρήγορο.
+Στη παρακάτω παράδειγμα θα χρησιμοποιήσουμε τη διαδρομή χωρίς το `file://` επειδή αυτό είναι σχεδόν πάντα πιο γρήγορο.
 
 Για να προσθέσουμε ένα τοπικό αποθετήριο σε ένα υπάρχον έργο Git, μπορούμε να εκτελέσουμε κάτι σαν:
 

book/05-distributed-git/sections/distributed-workflows.asc

@@ -57,7 +57,7 @@ image::images/integration-manager.png[Ροή εργασίας με διαχει
 (((απόσχιση)))
 Αυτή είναι μια πολύ συνηθισμένη ροή εργασίας με εργαλεία όπως το GitHub ή το GitLab, που βασίζονται σε κεντρικούς κόμβους και στην οποία είναι εύκολο να κλωνοποιήσουμε ένα έργο και να ωθήσουμε τις αλλαγές μας στον δικό μας κλώνο, όπου μπορούν να τις δουν όλοι.
 Ένα από τα κύρια πλεονεκτήματα αυτής της προσέγγισης είναι ότι μπορούμε να συνεχίσουμε να εργαζόμαστε και ο συντηρητής του κύριου αποθετηρίου μπορεί να έλξει τις αλλαγές μας όποτε θέλει. 
-Οι συνεισφέροντες δεν χρειάζεται να περιμένουν να το έργο να ενσωματώσει τις αλλαγές τους --ο καθένας μπορεί να εργαστεί με τον δικό του ρυθμό.
+Οι συνεισφέροντες δεν χρειάζεται να περιμένουν το έργο να ενσωματώσει τις αλλαγές τους --ο καθένας μπορεί να εργαστεί με τον δικό του ρυθμό.
 
 ==== Ροή εργασίας δικτάτορα και υπολοχαγών
 

book/06-github/sections/5-scripting.asc

@@ -279,7 +279,7 @@ end
 Σε αυτόν τον χειριστή αγκίστρων ιστού εξετάζουμε κάθε υποβολή που μόλις ωθήθηκε, αναζητούμε τη συμβολοσειρά `Signed-off-by` στο μήνυμα της υποβολής και τέλος κάνουμε POST μέσω HTTP στο σημείο σύνδεσης `/repos/<χρήστης>/<αποθετήριο>/statuses/<sha_υποβολής>` την κατάσταση.
 
 Σε αυτή την περίπτωση μπορούμε να στείλουμε μια κατάσταση ('επιτυχία', 'αποτυχία', 'σφάλμα'), μια περιγραφή του τι συνέβη, μια διεύθυνση URL στην οποία μπορεί να μεταβεί ο χρήστης για περισσότερες πληροφορίες και ένα ``πλαίσιο'' (context) σε περίπτωση που υπάρχουν πολλαπλές καταστάσεις για μία μόνο υποβολή.
-Για παράδειγμα, μια υπηρεσία δοκιμών μπορεί να παρέχει μια κατάσταση και μια υπηρεσία επικύρωσης, όπως αυτή, μπορεί επίσης να παρέχει μια κατάσταση --το πεδίο ``context'' είναι εκεί που διαφοροποιούνται.
+Για παράδειγμα, μια υπηρεσία δοκιμών μπορεί να παρέχει μια κατάσταση και μια υπηρεσία επικύρωσης, όπως αυτή, μπορεί επίσης να παρέχει μια κατάσταση --το πεδίο ``context'' είναι εκεί όπου διαφοροποιούνται.
 
 Εάν κάποιος ανοίξει ένα νέο αίτημα έλξης στο GitHub και αυτό το άγκιστρο έχει στηθεί, ίσως δούμε κάτι σαν <<_commit_status>>.
 

book/07-git-tools/sections/advanced-merging.asc

@@ -113,7 +113,7 @@ Automatic merge failed; fix conflicts and then commit the result.
 
 Έχουμε κάποιες επιλογές.
 Πρώτον, ας δούμε πώς θα βγούμε από αυτή την κατάσταση.
-Εάν δεν περιμέναμε τις συγκρούσεις και δεν θέλουμε να ασχοληθούμε με αυτήν την κατάσταση, μπορούμε απλά να βγούμε από τη συγχώνευση με την εντολή `git merge --abort`.
+Εάν δεν αναμέναμε τις συγκρούσεις και δεν θέλουμε να ασχοληθούμε με αυτήν την κατάσταση, μπορούμε απλά να βγούμε από τη συγχώνευση με την εντολή `git merge --abort`.
 
 [source,console]
 ----
@@ -549,7 +549,7 @@ image::images/undomerge-start.png[Ακούσια υποβολή συγχώνευ
 
 ===== Fix the references
 
-Εάν η ανεπιθύμητη υποβολή συγχώνευσης υπάρχει μόνο στο τοπικό αποθετήριο, η ευκολότερη και καλύτερη λύση είναι να μετακινήσουμε τους κλάδους ώστε να δείχνουν εκεί που θέλουμε.
+Εάν η ανεπιθύμητη υποβολή συγχώνευσης υπάρχει μόνο στο τοπικό αποθετήριο, η ευκολότερη και καλύτερη λύση είναι να μετακινήσουμε τους κλάδους ώστε να δείχνουν εκεί όπου θέλουμε.
 Στις περισσότερες περιπτώσεις, αν μετά από μία `git merge` εκτελέσουμε την `git reset --hard HEAD~`, αυτό θα επαναφέρει τους δείκτες κλάδων, οπότε θα μοιάζουν με αυτό:
 
 .Το ιστορικό μετά την `git reset --hard HEAD~`.
@@ -558,7 +558,7 @@ image::images/undomerge-reset.png[Το ιστορικό μετά την `git res
 Καλύψαμε την `reset` στην ενότητα <<_git_reset>>, επομένως δεν πρέπει να είναι πολύ δύσκολο να καταλάβουμε τι συμβαίνει εδώ.
 Ορίστε μία γρήγορη υπενθύμιση: η `reset --hard` συνήθως περνάει από τρία βήματα:
 
-. Μετακινούμε τον κλάδο στον οποίο δείχνει τον HEAD. Σε αυτήν την περίπτωση, θέλουμε να μετακινήσουμε τον `master` εκεί που βρισκόταν πριν την υποβολή συγχώνευσης (`C6`).
+. Μετακινούμε τον κλάδο στον οποίο δείχνει τον HEAD. Σε αυτήν την περίπτωση, θέλουμε να μετακινήσουμε τον `master` εκεί όπου βρισκόταν πριν την υποβολή συγχώνευσης (`C6`).
 . Κάνουμε το ευρετήριο να μοιάζει με τον HEAD.
 . Κάνουμε τον κατάλογο εργασίας να μοιάζει με το ευρετήριο.
 

book/07-git-tools/sections/credentials.asc

@@ -83,8 +83,8 @@ password=s3cre7
 ----
 
 <1> Αυτή είναι η γραμμή εντολών που ενεργοποιεί την αλληλεπίδραση.
-<2> Η `git credential` στη συνέχεια περιμένει είσοδο από το stdin.
-    Το παρέχουμε με τα πράγματα που γνωρίζουμε: το πρωτόκολλο και το όνομα του κεντρικού υπολογιστή.
+<2> Η `git credential` στη συνέχεια αναμένει είσοδο από το stdin.
+    Το παρέχουμε με αυτά που γνωρίζουμε: το πρωτόκολλο και το όνομα του κεντρικού υπολογιστή.
 <3> Μια κενή γραμμή υποδεικνύει ότι η είσοδος είναι πλήρης και το σύστημα διαπιστευτηρίων πρέπει να απαντήσει με αυτό που γνωρίζει.
 <4> Η `git credential` γράφει στο stdout τις πληροφορίες που βρήκε.
 <5> Εάν δεν εντοπιστούν διαπιστευτήρια, το Git ζητάει από τον χρήστη το όνομα χρήστη και τον κωδικό πρόσβασης και τα επαναφέρει στην κλήση του stdout (εδώ είναι συνδεδεμένα στην ίδια κονσόλα).

book/07-git-tools/sections/replace.asc

@@ -172,7 +172,7 @@ e146b5f fifth commit
 c1822cf first commit
 ----
 
-Καλή φάση, σωστά; Χωρίς να χρειάζεται να αλλάξουμε όλα τα SHA-1s upstream, μπορέσαμε να αντικαταστήσουμε μια υποβολή στο ιστορικό μας με μια εντελώς διαφορετική υποβολή και όλα τα συνήθη εργαλεία (`bisect`, `blame` κ.λπ.) θα δουλεύουν με τον τρόπο με τον οποίο θα περιμέναμε.
+Καλή φάση, σωστά; Χωρίς να χρειάζεται να αλλάξουμε όλα τα SHA-1s upstream, μπορέσαμε να αντικαταστήσουμε μια υποβολή στο ιστορικό μας με μια εντελώς διαφορετική υποβολή και όλα τα συνήθη εργαλεία (`bisect`, `blame` κ.λπ.) θα δουλεύουν με τον τρόπο με τον οποίο θα αναμέναμε.
 
 image::images/replace5.png[]
 

book/07-git-tools/sections/rerere.asc

@@ -174,7 +174,7 @@ Failed to merge in the changes.
 Patch failed at 0001 i18n one word
 ----
 
-Τώρα, πήραμε την ίδια σύγκρουση συγχώνευσης όπως περιμέναμε, αλλά επιπλέον υπάρχει η γραμμή `Resolved FILE using previous resolution`.
+Τώρα, πήραμε την ίδια σύγκρουση συγχώνευσης όπως αναμέναμε, αλλά επιπλέον υπάρχει η γραμμή `Resolved FILE using previous resolution`.
 Αν εξετάσουμε το αρχείο, θα δούμε ότι έχει ήδη επιλυθεί, δεν υπάρχουν επισημάνσεις σύγκρουσης συγχώνευσης.
 
 [source,console]

book/07-git-tools/sections/reset.asc

@@ -201,7 +201,7 @@ image::images/reset-hard.png[]
 
 ==== Επαναφορά με διαδρομή
 
-Τα προηγούμενα καλύπτουν τη συμπεριφορά της `reset` στη βασική της μορφή, αλλά μπορούμε επίσης να της παράσχουμε ένα μονοπάτι στο οποίο να δράσει.
+Τα προηγούμενα καλύπτουν τη συμπεριφορά της `reset` στη βασική της μορφή, αλλά μπορούμε επίσης να της παράσχουμε μία διαδρομή στην οποία να δράσει.
 Αν καθορίσουμε μια διαδρομή, η `reset` θα παραλείψει το Βήμα 1 και θα περιορίσει το υπόλοιπο των ενεργειών της σε ένα συγκεκριμένο αρχείο ή σύνολο αρχείων.
 Αυτό πραγματικά έχει μία λογική --ο HEAD είναι απλώς ένας δείκτης και δεν μπορεί να δείχνει σε ένα τμήμα μίας υποβολής και σε ένα τμήμα μίας άλλης.
 Αλλά το Ευρετήριο και ο Κατάλογος Εργασίας _μπορούν_ να ενημερώνονται εν μέρει, οπότε η `reset` συνεχίζει με τα Bήματα 2 και 3.
@@ -266,7 +266,7 @@ image::images/reset-squash-r3.png[]
 Τέλος, θα μπορούσε να αναρωτηθεί κανείς ποια είναι η διαφορά ανάμεσα στις `checkout` και `reset`.
 Όπως η `reset`, έτσι και η `checkout` χειρίζεται τα τρία δέντρα και είναι λίγο διαφορετική ανάλογα με το αν της δίνουμε και μια διαδρομή αρχείου ή όχι.
 
-===== Χωρίς μονοπάτι
+===== Χωρίς διαδρομή
 
 Το τρέξιμο της `git checkout [branch]` είναι αρκετά παρόμοιο με το τρέξιμο της `git reset --hard [branch]` επειδή ενημερώνει και τα τρία δέντρα ώστε να μοιάζουν με τον `[branch]`, αλλά υπάρχουν δύο σημαντικές διαφορές.
 

book/08-customizing-git/sections/attributes.asc

@@ -65,7 +65,7 @@ Binary files a/chapter1.docx and b/chapter1.docx differ
 
 Καταρχήν, θα χρειαστεί να εγκαταστήσουμε το `docx2txt`· μπορούμε να το κατεβάσουμε από http://docx2txt.sourceforge.net[].
 Ακολουθούμε τις οδηγίες στο αρχείο `INSTALL` για να το βάλουμε κάπου, όπου το κέλυφός μας μπορεί να το βρει.
-Στη συνέχεια, θα γράψουμε ένα script wrapper για να μετατρέψουμε την έξοδο στη μορφή που περιμένει το Git.
+Στη συνέχεια, θα γράψουμε ένα script wrapper για να μετατρέψουμε την έξοδο στη μορφή που αναμένει το Git.
 Δημιουργούμε ένα αρχείο, κάπου στη διαδρομή μας, που ονομάζεται `docx2txt` και προσθέτουμε αυτά τα περιεχόμενα:
 
 [source,console]