update 4 more files of 07-git-tools module

Author: marrinosnis

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

@@ -9,29 +9,32 @@
 Αν εντοπίζουμε ένα σφάλμα στον κώδικά μας και θέλουμε να μάθουμε πότε εισήχθη και γιατί, η επισημείωση (annotation) του αρχείου είναι συχνά το καλύτερο εργαλείο μας.
 Μας δείχνει ποια ήταν η τελευταία υποβολή που τροποποποίησε κάθε γραμμή οποιουδήποτε αρχείου.
 Έτσι, εάν δούμε ότι μια μέθοδος στον κώδικά μας έχει σφάλματα, μπορούμε να επισημειώσουμε το αρχείο με `git blame` για να δούμε πότε άλλαξε τελευταία φορά κάθε γραμμή της μεθόδου και από ποιον.
-Αυτό το παράδειγμα χρησιμοποιεί την επιλογή `-L` για να περιορίσει την έξοδο στις γραμμές 12 έως 22:
+
+Το παρακάτω παράδειγμα χρησιμοποιεί την `git blame` για να καθορίσει ποια υποβολή και ποιος υποβολέας ήταν υπεύθυνος για τις γραμμές στο πάνω-επίπεδο του Linux kernel `Makefile` και, επιπλέον, χρησιμοποιεί την επιλογή `-L` για να περιορίσει την έξοδο στις γραμμές 69 έως 82 αυτού του αρχείου:
 
 [source,console]
 ----
-$ git blame -L 12,22 simplegit.rb
-^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 12)  def show(tree = 'master')
-^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 13)   command("git show #{tree}")
-^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 14)  end
-^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 15)
-9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 16)  def log(tree = 'master')
-79eaf55d (Scott Chacon  2008-04-06 10:15:08 -0700 17)   command("git log #{tree}")
-9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 18)  end
-9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 19)
-42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 20)  def blame(path)
-42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 21)   command("git blame #{path}")
-42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 22)  end
+$ git blame -L 69,82 Makefile
+b8b0618cf6fab (Cheng Renquan  2009-05-26 16:03:07 +0800 69) ifeq ("$(origin V)", "command line")
+b8b0618cf6fab (Cheng Renquan  2009-05-26 16:03:07 +0800 70)   KBUILD_VERBOSE = $(V)
+^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 71) endif
+^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 72) ifndef KBUILD_VERBOSE
+^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 73)   KBUILD_VERBOSE = 0
+^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 74) endif
+^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 75)
+066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 76) ifeq ($(KBUILD_VERBOSE),1)
+066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 77)   quiet =
+066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 78)   Q =
+066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 79) else
+066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 80)   quiet=quiet_
+066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 81)   Q = @
+066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 82) endif
 ----
 
 Παρατηρούμε ότι το πρώτο πεδίο είναι ο μερικός αριθμός SHA-1 της υποβολής που τροποποίησε τελευταία αυτήν τη γραμμή.
 Τα επόμενα δύο πεδία είναι τιμές που εξάχθηκαν από αυτήν την υποβολή —το όνομα συγγραφέα και η ημερομηνία επεξεργασίας αυτής της υποβολής— για να μπορούμε εύκολα να δούμε ποιος τροποποίησε αυτήν τη γραμμή και πότε.
 Ακολουθούν ο αριθμός γραμμής και το περιεχόμενο του αρχείου.
-Ο αριθμός SHA-1 `^4832fe2` υποδηλώνει ότι οι γραμμές με αυτόν τον αριθμό ήταν στην αρχική υποβολή αυτού του αρχείου.
-Αυτή είναι η υποβολή με την οποία το αρχείο αυτό προστέθηκε για πρώτη φορά σε αυτό το έργο και οι γραμμές αυτές δεν έχουν αλλάξει από τότε.
+Επισής σημειώνουμε ότι `^1da177e4c3f4` γραμμές υποβολής, όπου το `^` πρόθεμα υποδηλώνει ότι οι γραμμές εισήχθησαν στην πρώτη υποβολή του αποθετηρίου και δεν έχουν αλλάξει από τότε.
 Αυτό δημιουργεί μία μικρή σύγχυση, καθώς μέχρι στιγμής έχουμε δει τουλάχιστον τρεις διαφορετικούς τρόπους με τους οποίους το Git χρησιμοποιεί το `^` για να τροποποιήσει τον αριθμό SHA-1 μίας υποβολής, αλλά εδώ σημαίνει αυτό το πράγμα.
 
 Ένα άλλο πολύ ωραίο χαρακτηριστικό για το Git είναι ότι δεν παρακολουθεί απόλυτα το όνομα του αρχείου.
@@ -69,13 +72,13 @@ ad11ac80 GITPackUpload.m    (Scott 2009-03-24 150)
 
 Η επισημείωση ενός αρχείου βοηθάει αν ξέρουμε ήδη πού βρίσκεται το πρόβλημα.
 Αν δεν ξέρουμε τι είναι χαλασμένο και υπήρξαν δεκάδες ή εκατοντάδες υποβολές από την τελευταία κατάσταση όπου γνωρίζουμε ότι ο κώδικας λειτουργούσε, πιθανότατα θα στραφούμε προς την `git bisect` για βοήθεια.
-Η εντολή `bisect` (διχοτόμηση) κάνει μια δυαδική αναζήτηση μέσα στο ιστορικό των υποβολών μας για να μας βοηθήσει να εντοπίσουμε το συντομότερο δυνατό ποια είναι υποβολή εισήγαγε ένα πρόβλημα.
+Η εντολή `bisect` (διχοτόμηση) κάνει μια δυαδική αναζήτηση μέσα στο ιστορικό των υποβολών μας για να μας βοηθήσει να εντοπίσουμε το συντομότερο δυνατό ποια υποβολή εισήγαγε ένα πρόβλημα.
 
 Ας υποθέσουμε ότι μόλις ωθήσαμε μια έκδοση του κώδικά μας στην παραγωγή, παίρνουμε αναφορές σφαλμάτων σχετικά με κάτι που δεν συνέβαινε στο περιβάλλον ανάπτυξης και δεν μπορούμε να φανταστούμε γιατί ο κώδικας το κάνει αυτό.
 Πηγαίνουμε πίσω στον κώδικά μας και αποδεικνύεται ότι μπορούμε να αναπαραγάγουμε το πρόβλημα, αλλά δεν μπορούμε να καταλάβουμε τι το δημιουργεί.
 Μπορούμε να _διχοτομήσουμε_ τον κώδικα για να το ανακαλύψουμε.
 Αρχικά τρέχουμε την `git bisect start` για να ξεκινήσει η διαδικασία της διοχοτόμησης και στη συνέχεια την `git bisect bad` για να πούμε στο σύστημα ότι η τρέχουσα υποβολή που χρησιμοποιούμε είναι χαλασμένη.
-Στη συνέχεια, πρέπει να πούμε στην `bisect` ποια ήταν η τελευταία γνωστή καλή κατάσταση, χρησιμοποιώντας την `git bisect good [good_commit]`:
+Στη συνέχεια, πρέπει να πούμε στην `bisect` ποια ήταν η τελευταία γνωστή καλή κατάσταση, χρησιμοποιώντας την `git bisect good <good_commit>`:
 
 [source,console]
 ----
@@ -89,7 +92,7 @@ Bisecting: 6 revisions left to test after this
 Το Git κατάλαβε ότι περίπου 12 υποβολές ήρθαν μεταξύ της υποβολής που σημειώσαμε ως της τελευταίας καλής υποβολής (v1.0) και της τρέχουσας κακής έκδοσης, και μετέβη (checkout) τη μεσαία για εμάς.
 Σε αυτό το σημείο, μπορούμε να εκτελέσουμε κάποια δοκιμασία για να διαπιστώσουμε εάν υπάρχει το πρόβλημα σε αυτήν την υποβολή.
 Εάν υπάρχει, τότε εισήχθη κάποια στιγμή πριν από αυτήν τη μεσαία υποβολή· αν δεν υπάρχει, τότε το πρόβλημα εισήχθη κάποια στιγμή μετά τη μεσαία υποβολή.
-Αποδεικνύεται ότι το πρόβλημα δεν υπάρχει εδώ και το λέμε αυτό στο Git ότι πληκτρολογώντας `git bisect good` και συνεχίζουμε την αναζήτηση του σφάλματος:
+Αποδεικνύεται ότι το πρόβλημα δεν υπάρχει εδώ και το λέμε αυτό στο Git πληκτρολογώντας `git bisect good` και συνεχίζουμε την αναζήτηση του σφάλματος:
 
 [source,console]
 ----
@@ -108,7 +111,7 @@ Bisecting: 1 revisions left to test after this
 [f71ce38690acf49c1f3c9bea38e09d82a5ce6014] drop exceptions table
 ----
 
-Αυτή η υποβολή είναι μια χαρά, και τώρα η Git διαθέτει όλες τις πληροφορίες που χρειάζεται για να προσδιορίσει πού εισήχθη το πρόβλημα.
+Αυτή η υποβολή είναι μια χαρά, και τώρα το Git διαθέτει όλες τις πληροφορίες που χρειάζεται για να προσδιορίσει πού εισήχθη το πρόβλημα.
 Μας λέει τον αριθμό SHA-1 της πρώτης κακής υποβολής και μας δείχνει μερικές από τις πληροφορίες της υποβολής και ποια αρχεία τροποποιήθηκαν σε αυτήν την υποβολή, ώστε να μπορούμε να καταλάβουμε τι ήταν αυτό που μπορεί να έχει εισάγει αυτό το σφάλμα:
 
 [source,console]

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

@@ -1,4 +1,4 @@
-[[rch_rerere]]
+[[r_ref_rerere]]
 === Rerere
 
 Η λειτουργικότητα `git rerere` είναι ένα λίγο κρυμμένο χαρακτηριστικό.
@@ -22,12 +22,12 @@
 $ git config --global rerere.enabled true
 ----
 
-Μπορούμε επίσης να την ενεργοποιήσουμε δημιουργώντας έναν κατάλογο `.git/rr-cache` σε ένα συγκεκριμένο αποθετήριο, αλλά η ρύθμιση της παραμέτρου με την `config` είναι σαφέστερη και μπορεί να γίνει καθολικά.
+Μπορούμε επίσης να την ενεργοποιήσουμε δημιουργώντας έναν κατάλογο `.git/rr-cache` σε ένα συγκεκριμένο αποθετήριο, αλλά η ρύθμιση της παραμέτρου με την config είναι σαφέστερη και μπορεί να γίνει καθολικά.
 
 Τώρα ας δούμε ένα απλό παράδειγμα, παρόμοιο με το προηγούμενο.
 Ας υποθέσουμε ότι έχουμε ένα αρχείο που μοιάζει με αυτό:
 
-[source,console]
+[source,ruby]
 ----
 #! /usr/bin/env ruby
 
@@ -38,7 +38,8 @@ end
 
 Σε έναν κλάδο αλλάζουμε τη λέξη "`hello`" σε "`hola`", στη συνέχεια σε έναν άλλο κλάδο αλλάζουμε το "`world`" σε "`mundo`", ακριβώς όπως πριν.
 
-image::images/rerere1.png[]
+.Δύο κλάδοι αλλάζουν το ίδιο μέρος ίδιου αρχείου διαφορετικά
+image::images/rerere1.png[Δύο κλάδοι αλλάζουν το ίδιο μέρος ίδιου αρχείου διαφορετικά]
 
 Όταν συγχωνεύσουμε τους δύο κλάδους, θα πάρουμε σύγκρουση συγχώνευσης:
 
@@ -109,7 +110,7 @@ $ git ls-files -u
 100644 54336ba847c3758ab604876419607e9443848474 3	hello.rb
 ----
 
-Τώρα μπορούμε να επιλύσουμε τη σύγκρουση (ας πούμε ότι αποφασίζουμε να είναι `puts 'hola mundo'`) και μπορούμε να εκτελέσουμε ξανά την εντολή `rerere diff` για να δούμε τι θα θυμάται η `rerere`:
+Τώρα μπορούμε να επιλύσουμε τη σύγκρουση (ας πούμε ότι αποφασίζουμε να είναι `puts 'hola mundo'`) και μπορούμε να εκτελέσουμε ξανά την εντολή `git rerere diff` για να δούμε τι θα θυμάται η `rerere`:
 
 [source,console]
 ----
@@ -141,12 +142,13 @@ Recorded resolution for 'hello.rb'.
 [master 68e16e5] Merge branch 'i18n'
 ----
 
-Βλέπουμε ότι αναφέρει `Recorded resolution for FILE`.
+Βλέπουμε ότι αναφέρει "Recorded resolution for FILE".
 
-image::images/rerere2.png[]
+.Καταγραφή επίλυσης για το FILE
+image::images/rerere2.png[Καταγραφή επίλυσης για το FILE]
 
 Τώρα ας αναιρέσουμε αυτήν τη συγχώνευση και στη συνέχεια ας αλλάξουμε τη βάση του θεματικού κλάδου στον κύριο κλάδο.
-Μπορούμε να επαναφέρουμε τον κλάδο μας χρησιμοποιώντας την `reset` όπως είδαμε στην ενότητα <<r_git_reset>>.
+Μπορούμε να επαναφέρουμε τον κλάδο μας χρησιμοποιώντας την `git reset` όπως είδαμε στην ενότητα <<ch07-git-tools#r_git_reset>>.
 
 [source,console]
 ----
@@ -177,9 +179,8 @@ Patch failed at 0001 i18n one word
 Τώρα, πήραμε την ίδια σύγκρουση συγχώνευσης όπως αναμέναμε, αλλά επιπλέον υπάρχει η γραμμή `Resolved FILE using previous resolution`.
 Αν εξετάσουμε το αρχείο, θα δούμε ότι έχει ήδη επιλυθεί, δεν υπάρχουν επισημάνσεις σύγκρουσης συγχώνευσης.
 
-[source,console]
+[source,ruby]
 ----
-$ cat hello.rb
 #! /usr/bin/env ruby
 
 def hello
@@ -206,9 +207,10 @@ index a440db6,54336ba..0000000
   end
 ----
 
-image::images/rerere3.png[]
+.Αυτόματη επίλυση σύγκγουσγη συγχώνευσης χρησιμοποιώντας προηγούμενη επίλυση
+image::images/rerere3.png[Αυτόματη επίλυση σύγκγουσγη συγχώνευσης χρησιμοποιώντας προηγούμενη επίλυση]
 
-Μπορούμε επίσης να ξαναδημιουργήσουμε την κατάσταση σύγκρουσης του αρχείου με την εντολή `checkout`:
+Μπορούμε επίσης να ξαναδημιουργήσουμε την κατάσταση σύγκρουσης του αρχείου με την εντολή `git checkout`:
 
 [source,console]
 ----
@@ -225,8 +227,8 @@ def hello
 end
 ----
 
-Είδαμε ένα παράδειγμα αυτού στην ενότητα <<r_advanced_merging>>.
-Προς το παρόν, όμως, ας την ξαναεπιλύσουμε τρέχοντας την `rerere` ξανά:
+Είδαμε ένα παράδειγμα αυτού στην ενότητα <<ch07-git-tools#r_advanced_merging>>.
+Προς το παρόν, όμως, ας την ξαναεπιλύσουμε τρέχοντας την `git rerere` ξανά:
 
 [source,console]
 ----
@@ -250,5 +252,5 @@ $ git rebase --continue
 Applying: i18n one word
 ----
 
-Έτσι, εάν κάνουμε πολλές συγχωνεύσεις ή θέλουμε o θεματικός κλάδος μας να συμβαδίζει με τον κύριο κλάδο μας χωρίς να έχουμε πάμπολλες συγχωνεύσεις, μπορούμε είτε να κάνουμε συχνά αλλαγές βάσης, είτε να ενεργοποιήσουμε την `rerere` για να κάνουμε πιο εύκολη τη ζωή μας.
+Έτσι, εάν κάνουμε πολλές συγχωνεύσεις ή θέλουμε o θεματικός κλάδος μας να συμβαδίζει με τον `master` κλάδο μας χωρίς να έχουμε πάμπολλες συγχωνεύσεις, μπορούμε είτε να κάνουμε συχνά αλλαγές βάσης, είτε να ενεργοποιήσουμε την `rerere` για να κάνουμε πιο εύκολη τη ζωή μας.