Άλλαξα το διοχέτευση (για το pipe) σε παροχέτευση.

Author: csaragiotis

book/02-git-basics/sections/viewing-history.asc

@@ -229,7 +229,7 @@ $ git log --pretty=format:"%h %s" --graph
 Επιπλέον, η εντολή `git log` χρησιμοποιείται με πολλές επιλογές για περιορισμό των αποτελεσμάτων της. Οι επιλογές αυτές θα μας αφήσουν να δούμε μόνο ένα υποσύνολο των συνολικών υποβολών.
 Έχουμε ήδη δει μια τέτοια επιλογή, την `-2`, η οποία θα μας εμφανίσει τις δύο τελευταίες υποβολές μόνο.
 Στην πραγματικότητα, μπορούμε να χρησιμοποιήσουμε `-<n>`, όπου `n` είναι ένας ακέραιος που αντιστοιχεί στις τελευταίες `n` υποβολές.
-Στην πραγματικότητα βέβαια, είναι σχετικά απίθανο να χρησιμοποιούμε αυτήν την επιλογή συχνά, καθώς το Git εκ προεπιλογής εμφανίζει μόνο μια σελίδα με τα στοιχεία καταγραφής κάθε φορά.
+Στην πραγματικότητα, βέβαια, είναι σχετικά απίθανο να χρησιμοποιούμε αυτήν την επιλογή συχνά, καθώς το Git εκ προεπιλογής παροχετεύει την έξοδο σε έναν σελιδοποιητή οπότε βλέπουμε μόνο μια σελίδα με τα στοιχεία του μητρώου κάθε φορά.
 
 Ωστόσο, θα μας φανούν πολύ χρήσιμες οι επιλογές που περιορίζουν τον αριθμό των αποτελεσμάτων με χρονικά κριτήρια.
 Για παράδειγμα, η εντολή αυτή θα μας δώσει μια λίστα με τις υποβολές που έγιναν τις τελευταίες δύο εβδομάδες:

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

@@ -458,7 +458,7 @@ uid                  Scott Chacon <[email protected]>
 sub   2048g/45D02282 2009-02-09 [expires: 2010-02-09]
 -----
 
-Στη συνέχεια, μπορούμε να εισάγουμε απευθείας το κλειδί στη βάση δεδομένων Git, εξάγοντάς το και διοχετεύοντας ότι μέσα από το `git hash-object`, το οποίο γράφει ένα νέο blob με αυτά τα περιεχόμενα στο Git και μας επιστρέφει το SHA-1 του blob:
+Στη συνέχεια, μπορούμε να εισάγουμε απευθείας το κλειδί στη βάση δεδομένων Git, αν το εξάγουμε και το παροχετεύσουμε στο `git hash-object`, το οποίο γράφει ένα νέο blob με αυτά τα περιεχόμενα στο Git και μας επιστρέφει τον SHA-1 του blob:
 
 [source,console]
 -----

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

@@ -190,7 +190,7 @@ in 0.1 seconds automatically...
 Ας σημειωθεί ότι το ``0.1 seconds'' προκύπτει από την τιμή 1 στην οποία θέσαμε το  `help.autocorrect`, αφού στην πραγματικότητα η `help.autocorrect` είναι ένας ακέραιος που αναπαριστά δέκατα του δευτερολέπτου.
 Έτσι, αν τη θέσουμε στην τιμή 50, το Git θε περιμένει 5 δευτερόλεπτα να αλλάξουμε γνώμη πριν εκτελέσει αυτο-διορθωμένη εντολή.
 
-==== Colors in Git
+==== Χρώματα στο Git
 
 (((color)))
 Το Git υποστηρίζει πλήρως την έγχρωμη εκτύπωση στο τερματικού, η οποία βοηθά σημαντικά στη γρήγορη και εύκολη παραγωγή των εντολών.
@@ -206,9 +206,9 @@ in 0.1 seconds automatically...
 $ git config --global color.ui false
 ----
 
-Η προεπιλεγμένη ρύθμιση είναι `auto`, με την οποία τα χρωματίζεται η έξοδος όταν πηγαίνει κατευθείαν σε ένα τερματικό, αλλά ο χρωματισμός των κωδικών ελέγχου παραλείπονται όταν η έξοδος είναι αρχείο ή διοχετεύεται.
+Η προεπιλεγμένη ρύθμιση είναι `auto`, με την οποία τα χρωματίζεται η έξοδος όταν πηγαίνει κατευθείαν σε ένα τερματικό, αλλά ο χρωματισμός των κωδικών ελέγχου παραλείπεται όταν η έξοδος ανακατευθύνεται σε παροχέτευση (pipe) ή αρχείο.
 
-Μπορούμε επίσης να τη ρυθμίσουμε σε `always` για να αγνοήσουμε τη διαφορά μεταξύ των τερματικών και των διοχετεύσεων (pipes).
+Μπορούμε επίσης να τη ρυθμίσουμε σε `always` για να αγνοήσουμε τη διαφορά μεταξύ των τερματικών και των παροχετεύσεων.
 Αυτό είναι κάτι που Θα το θέλουμε σπάνια· στις περισσότερες περιπτώσεις εάν θέλουμε χωρματικούς κώδικες χρώματος στην έξοδο, μπορούμε απλά να περάσουμε μια σημαία `--color` στην εντολή Git για να την εξαναγκάσουμε να χρησιμοποιήσει χρωματικούς κώδικες.
 Η προεπιλεγμένη ρύθμιση είναι σχεδόν πάντα αυτό που θα θελήσουμε.
 

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

@@ -117,7 +117,7 @@ check_message_format
 
 Το πρώτο πράγμα που θα κάνουμε είναι να γράψουμε τη λίστα ACL.
 Εδώ θα χρησιμοποιήσουμε μια μορφή που μοιάζει πολύ με τον μηχανισμό ACL στα CVS: χρησιμοποιεί μια σειρά γραμμών, στις οποίες το πρώτο πεδίο είναι `avail` ή` unavail`, το επόμενο πεδίο είναι η λίστα χρηστών, που διαχωρίζονται με κόμμα, για τους οποίους ισχύει ο κανόνας και το τελευταίο πεδίο είναι η διαδρομή στην οποία εφαρμόζεται αυτός ο κανόνας (αν αυτό το πεδίο είναι κενό εξυπονοείται ανοικτή πρόσβαση).
-Όλα αυτά τα πεδία οριοθετούνται από ένα χαρακτήρα σωλήνα (`|`).
+Όλα αυτά τα πεδία οριοθετούνται από έναν χαρακτήρα παροχέτευσης (`|`).
 
 Σε αυτή την περίπτωση, έχουμε μερικούς διαχειριστές, μερικούς συγγραφείς τεκμηρίωσης με πρόσβαση στον κατάλογο `doc` και έναν προγραμματιστή που έχει πρόσβαση μόνο στους καταλόγους` lib` και `tests`· το αρχείο ACL μοιάζει με αυτό:
 

book/09-git-and-other-scms/sections/import-custom.asc

@@ -8,7 +8,7 @@
 Αυτή η εντολή διαβάζει απλές οδηγίες από τη stdin και γράφει συγκεκριμένα δεδομένα Git.
 Είναι πολύ πιο εύκολο να δημιουργήσουμε αντικείμενα Git με αυτόν τον τρόπο από το να εκτελέσουμε τις εντολές του Git ή να προσπαθήσουμε να γράψουμε τα ανεπεξέργαστα αντικείμενα (για περισσότερες πληροφορίες, βλ. το <<_git_internals>>).
 Με αυτόν τον τρόπο, μπορούμε να γράψουμε ένα script εισαγωγής που διαβάζει τις απαραίτητες πληροφορίες από το σύστημα από το οποίο εισάγουμε και εκτυπώνει απλές οδηγίες στη stdout.
-Στη συνέχεια μπορούμε να εκτελέσουμε αυτό το πρόγραμμα και να διοχετεύσουμε την έξοδό του μέσω της `git fast-import`.
+Στη συνέχεια μπορούμε να εκτελέσουμε αυτό το πρόγραμμα και να παροχετεύσουμε την έξοδό του μέσω της `git fast-import`.
 
 Για μία γρήγορη επίδειξη, θα γράψουμε έναν απλό εισαγωγέα.
 Ας υποθέσουμε ότι εργαζόμαστε στον `current`, δημιουργούμε αντίγραφα ασφαλείας του έργου μας αντιγράφοντας περιστασιακά τον κατάλογο σε έναν χρονοσημασμένο `back_YYYY_MM_DD` κατάλογο αντιγράφων ασφαλείας και θέλουμε να τον εισαγάγουμε στο Git.
@@ -303,7 +303,7 @@ M 644 inline README.md
 (...)
 ----
 
-Για να τρέξουμε τον εισαγωγέα, διοχετεύουμε αυτήν την έξοδο μέσω της `git fast-import` ενώ βρισκόμαστε στον κατάλογο Git που θέλουμε να εισάγουμε.
+Για να τρέξουμε τον εισαγωγέα, παροχετεύουμε αυτήν την έξοδο μέσω της `git fast-import` ενώ βρισκόμαστε στον κατάλογο Git που θέλουμε να εισάγουμε.
 Μπορούμε να δημιουργήσουμε ένα νέο κατάλογο και στη συνέχεια να εκτελέσουμε την `git init` μέσα σε αυτόν για να δημιουργήσουμε ένα σημείο εκκίνησης και στη συνέχεια να εκτελέσουμε το script μας:
 
 [source,console]

book/09-git-and-other-scms/sections/import-tfs.asc

@@ -30,7 +30,7 @@ PS> cat AUTHORS_TMP | cut -b 11-20 | tail -n+3 | uniq | sort > AUTHORS
 
 Η εντολή `cut` διατηρεί μόνο τους χαρακτήρες μεταξύ των θέσεων 11 και 20 από κάθε γραμμή.
 Η εντολή `tail` παραλείπει τις δύο πρώτες γραμμές, οι οποίες είναι κεφαλίδες πεδίων και υπογραμμίσεις ASCII-art.
-Το αποτέλεσμα όλων αυτών διοχετεύεται στη `uniq` για να εξαλείψει τις διπλές καταχωρήσεις και αποθηκεύεται σε ένα αρχείο που ονομάζεται `AUTHORS`.
+Το αποτέλεσμα όλων αυτών παροχετεύεται στη `uniq` για να εξαλείψει τις διπλές καταχωρήσεις και αποθηκεύεται σε ένα αρχείο που ονομάζεται `AUTHORS`.
 Το επόμενο βήμα είναι χειροκίνητο· για να μπορέσει η `git-tfs` να χρησιμοποιήσει αποτελεσματικά αυτό το αρχείο, κάθε γραμμή πρέπει να είναι σε αυτή τη μορφή:
 
 [source,text]

book/10-git-internals/sections/maintenance.asc

@@ -250,7 +250,7 @@ size-garbage: 0
 Σε αυτήν την περίπτωση, ξέρουμε ήδη τι αρχείο είναι.
 Αλλά ας υποθέσουμε ότι δεν ξέρουμε· πώς θα προσδιορίζαμε ποιο αρχείο ή αρχεία καταλάμβαναν τόσο μεγάλο χώρο;
 Αν εκτελέσουμε την `git gc`, θα δούμε ότι όλα τα αντικείμενα βρίσκονται σε ένα πακέτο· μπορούμε να προσδιορίσουμε τα μεγάλα αντικείμενα, αν τρέξουμε μια άλλη εντολή διοχέτευσης που ονομάζεται `git verify-pack` και ταξινομήσουμε με βάση το τρίτο πεδίο στην έξοδο, που είναι το μέγεθος των αρχείων.
-Μπορούμε επίσης αυτήν την έξοδο να τη διοχετεύσουμε στην εντολή `tail`, επειδή ενδιαφερόμαστε μόνο για τα τελευταία (τα μεγαλύτερα) αρχεία:
+Μπορούμε επίσης αυτήν την έξοδο να την παροχετεύσουμε στην εντολή `tail`, επειδή ενδιαφερόμαστε μόνο για τα τελευταία (τα μεγαλύτερα) αρχεία:
 
 [source,console]
 ----