9.2 Το Git και άλλα συστήματα - Μετανάστευση στο Git

Όπως αναφέρεται στην προηγούμενη ενότητα σχετικά με τη χρήση του git svn, μπορούμε εύκολα να χρησιμοποιήσουμε αυτές τις οδηγίες για να κλωνοποιήσουμε ένα αποθετήριο SVN με την git svn clone· στη συνέχεια, σταματούμε να χρησιμοποιούμε τον διακομιστή Subversion, ωθούμε στον νέο διακομιστή Git και αρχίζουμε να χρησιμοποιούμε αυτόν. Εάν θέλουμε το ιστορικό, αυτό είναι κάτι που μπορούμε να το πετύχουμε τόσο γρήγορα όσο γρήγορα μπορούμε να τραβήξουμε τα δεδομένα από τον διακομιστή Subversion (αυτό μπορεί να πάρει διαρκέσει αρκετά).

Ωστόσο, η εισαγωγή δεν είναι τέλεια· και επειδή θα διαρκέσει τόσο πολύ ούτως ή άλλως, ας την κάνουμε σωστά. Το πρώτο πρόβλημα είναι οι πληροφορίες του συγγραφέα. Στο Subversion, κάθε άτομο που υποβάλλει έχει έναν χρήστη στο σύστημα που καταγράφεται καταγραφεί στις πληροφορίες της υποβολής. Τα παραδείγματα στην προηγούμενη ενότητα δείχνουν schacon σε ορισμένα σημεία, όπως στις εξόδους των blame και git svn log. Εάν θέλουμε να αντιστοιχίσουμε αυτό για να βελτιώσουμε τις πληροφορίες των συγγραφέων στο Git, χρειάζεστε μια απεικόνιση από τους χρήστες του Subversion στους συγγραφείς του Git. Δημιουργούμε ένα αρχείο με όνομα users.txt που έχει αυτήν την απεικόνιση στην παρακάτω μορφή:

Για να αποκτήσουμε μια λίστα με τα ονόματα συγγραφέων που χρησιμοποιεί το SVN, μπορούμε να εκτελέσουμε το εξής:

Αυτό δίνει την έξοδο του αρχείου καταγραφής σε μορφή XML, διατηρεί μόνο τις γραμμές με πληροφορίες συγγραφέα, απορρίπτει διπλότυπα, απομακρύνει τις ετικέτες XML. (Προφανώς αυτό λειτουργεί μόνο σε ένα μηχάνημα που έχει εγκατεστημένα τα προγράμματα grep, sort και perl.) Στη συνέχεια, ανακατευθύνουμε την έξοδο στο αρχείο users.txt, ώστε να μπορούμε να προσθέσουμε τα αντίστοιχα δεδομένα χρήστη Git δίπλα σε κάθε καταχώρηση.

Μπορούμε να δώσουμε αυτό το αρχείο στην git svn για να το βοηθήσουμε να αντιστοιχίσει τα δεδομένα των συγγραφέων με μεγαλύτερη ακρίβεια. Μπορούμε επίσης να πούμε στο git svn να μην συμπεριλάβει τα μεταδεδομένα που εισάγει το Subversion υπό κανονικές συνθήκες, περνώντας την επιλογή --no-metadata στην εντολή clone ή την init. Αυτό κάνει την εντολή import μας να μοιάζει με αυτή:

Τώρα θα πρέπει να έχουμε μια καλύτερη εισαγωγή από το Subversion στον κατάλογο my_project. Αντί οι υποβολές που μοιάζουν με αυτό:

μοιάζουν με αυτό:

Όχι μόνο το πεδίο “Author” φαίνεται πολύ καλύτερα, αλλά επιπλέον το git-svn-id δεν βρίσκεται πια εκεί.

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

Για να μετακινήσουμε τις ετικέτες ώστε να είναι κατάλληλες ετικέτες Git, εκτελούμε:

Το παραπάνω παίρνει τις αναφορές που ήταν απομακρυσμένοι κλάδοι που ξεκίνησαν με remotes/origin/tags/ και τα κάνει πραγματικές (ελαφριές) ετικέτες.

Στη συνέχεια μετακινούμε τις υπόλοιπες αναφορές του φακέλου refs/remotes ώστε να είναι τοπικοί κλάδοι:

Τώρα όλοι οι παλιοί κλάδοι είναι πραγματικοί κλάδοι Git και όλες οι παλιές ετικέτες είναι πραγματικές ετικέτες Git. Το τελευταίο πράγμα που πρέπει να κάνουμε είναι να προσθέσουμε τον νέο μας διακομιστή Git ως απομακρυσμένο και να τον ωθήσουμε. Ακολουθεί ένα παράδειγμα προσθήκης του διακομιστή μας ως απομακρυσμένου αποθετηρίου:

Επειδή θέλουμε να ανέβουν όλοι οι κλάδοι και οι ετικέτες μας, μπορούμε τώρα να εκτελέσουμε το εξής:

Όλοι οι κλάδοι μας και οι ετικέτες μας θα πρέπει να βρίσκονται στο νέο μας διακομιστή Git σε μια ωραία και καθαρή εισαγωγή.

Δεδομένου ότι τα Mercurial και Git έχουν αρκετά παρόμοια μοντέλα για να αναπαριστούν τις εκδόσεις και καθώς το Git είναι λίγο πιο ευέλικτο, η μετατροπή ενός αποθετηρίου από το Mercurial στο Git είναι αρκετά απλή, χάρη σε ένα εργαλείο που ονομάζεται hg-fast-export, το οποιο θα χρειαστούμε:

Το πρώτο βήμα της μετατροπής είναι να αποκτήσουμε έναν πλήρη κλώνο του αποθετηρίου Mercurial που θέλουμε να μετατρέψουμε:

Το επόμενο βήμα είναι να δημιουργήσουμε ένα αρχείο αντιστοίχισης των συγγραφέων. Το Mercurial είναι λίγο πιο συγχωρητικό από το Git όσον αφορά σε αυτά που θα θέσει στο πεδίο author για το σύνολο των αλλαγών, γι' αυτό είναι μια καλή ευκαιρία για ένα μικρό συμμάζεμα. Το συμμάζεμα είναι μία εντολή της μιας γραμμής στο κέλυφος bash:

Αυτό θα διαρκέσει μερικά δευτερόλεπτα, ανάλογα με το πόσο εκτενές είναι το ιστορικό του έργου μας και μετά το αρχείο /tmp/authors θα μοιάζει με αυτό:

Σε αυτό το παράδειγμα, το ίδιο άτομο (Bob) δημιούργησε σύνολα αλλαγών κάτω από τέσσερα διαφορετικά ονόματα, ένα από τα οποία φαίνεται πραγματικά σωστό και ένα από τα οποία θα ήταν εντελώς άκυρο για μια υποβολή Git. Η hg-fast-export μάς επιτρέπει να το διορθώσουμε προσθέτοντας ={νέο όνομα και νέα διεύθυνση e-mail} στο τέλος κάθε γραμμής που θέλουμε να αλλάξουμε και αφαιρώντας τις γραμμές για όλα τα ονόματα χρήστη που θέλουμε να αφήσουμε ανέγγιχτα. Αν όλα τα ονόματα χρηστών φαίνονται ωραία, δεν θα χρειαστεί καθόλου αυτό το αρχείο. Σε αυτό το παράδειγμα, θέλουμε το αρχείο μας να μοιάζει με αυτό:

Το επόμενο βήμα είναι να δημιουργήσουμε το νέο μας αποθετήριο Git και να εκτελέσουμε το script εξαγωγής:

Η σημαία -r λέει στο hg-fast-export πού θα βρει το αποθετήριο Mercurial που θέλουμε να μετατρέψουμε και η σημαία -A του λέει πού θα βρει το αρχείο αντιστοίχισης των συγγραφέων. Το script αναλύει τα σύνολα αλλαγών του Mercurial changesets και τα μετατρέπει σε ένα script για τη λειτουργία “γρήγορης εισαγωγής” του Git (η οποία θα συζητηθεί λεπτομερώς λίγο αργότερα). Αυτό διαρκεί λιγάκι (αν και είναι πολύ πιο γρήγορα από ό,τι θα ήταν πάνω από το δίκτυο) και η έξοδος είναι αρκετά λεπτομερής:

Σε γενικές γραμμές αυτό ήταν όλο. Όλες οι ετικέτες του Mercurial έχουν μετατραπεί σε ετικέτες Git και τα οι κλάδοι και σελιδοδείκτες του Mercurial έχουν μετατραπεί σε κλάδους του Git. Τώρα είμαστε έτοιμοι να ωθήσουμε το αποθετήριο στον διακομιστή που θα είναι το νέο του σπίτι:

Το επόμενο σύστημα από το οποίο θα εξετάσουμε την εισαγωγή είναι το Perforce. Όπως συζητήσαμε παραπάνω, υπάρχουν δύο τρόποι να αφήσουμε τα Git και Perforce να μιλήσουν μεταξύ τους: οι git-p4 και Perforce Git Fusion.

Αν η ομάδα μας μετατρέπει τον έλεγχο πηγαίου κώδικα από το TFVC στο Git, θα θελήσουμε να έχουμε την πιο πιστή μετατροπή που μπορούμε να αποκτήσουμε. Αυτό σημαίνει ότι, αν και είδαμε τόσο την git-tfs όσο και την git-tf στην ενότητα της διαλειτουργικότητας, θα δούμε μόνο την git-tfs σε αυτό το μέρος, επειδή η git-tfs υποστηρίζει κλάδους κάτι που είναι απαγορευτικά δύσκολο με την git-tf.

Το πρώτο πράγμα που πρέπει να κάνουμε είναι να αντιστοιχίσουμε τα ονόματα χρηστών. Το TFVC είναι αρκετά φιλελεύθερο με αυτό που πηγαίνει στο πεδίο author για σύνολα αλλαγών, αλλά το Git θέλει ένα ανθρωπανάγνωστο όνομα και διεύθυνση e-mail. Μπορούμε να λάβουμε αυτές τις πληροφορίες από τον πελάτη γραμμής εντολών tf, όπως π.χ.:

Αυτό τραβάει όλα τα σύνολα αλλαγών στο ιστορικό του έργου και τα βάζει στο αρχείο AUTHORS_TMP που θα επεξεργαστούμε για την εξαγωγή των δεδομένων της στήλης User (2η στήλη). Ανοίγουμε το αρχείο και βρίσκουμε ποιοι χαρακτήρες ξεκινούν και τελειώνουν τη στήλη αυτή και αντικαθιστούμε στην ακόλουθη γραμμή εντολών τις παραμέτρους 11-20 της εντολής cut με αυτούς που βρέθηκαν:

Η εντολή cut διατηρεί μόνο τους χαρακτήρες μεταξύ των θέσεων 11 και 20 από κάθε γραμμή. Η εντολή tail παραλείπει τις δύο πρώτες γραμμές, οι οποίες είναι κεφαλίδες πεδίων και υπογραμμίσεις ASCII-art. Το αποτέλεσμα όλων αυτών παροχετεύεται στη uniq για να εξαλείψει τις διπλές καταχωρήσεις και αποθηκεύεται σε ένα αρχείο που ονομάζεται AUTHORS. Το επόμενο βήμα είναι χειροκίνητο· για να μπορέσει η git-tfs να χρησιμοποιήσει αποτελεσματικά αυτό το αρχείο, κάθε γραμμή πρέπει να είναι σε αυτήν τη μορφή:

Το τμήμα στα αριστερά είναι το πεδίο “User” από το TFVC και το τμήμα στη δεξιά πλευρά του = είναι το όνομα χρήστη που θα χρησιμοποιηθεί για τις υποβολές Git.

Μόλις έχουμε αυτό το αρχείο, το επόμενο πράγμα που πρέπει να κάνουμε είναι να φτιάξουμε έναν πλήρη κλώνο του έργου TFVC που μας ενδιαφέρει:

Στη συνέχεια, θέλουμε να καθαρίσουμε τις ενότητες git-tfs-id από το κάτω μέρος των μηνυμάτων υποβολής. Αυτό μπορεί να γίνει με την ακόλουθη εντολή:

Αυτό χρησιμοποιεί την εντολή sed από το περιβάλλον Git-bash για να αντικαταστήσει οποιαδήποτε γραμμή που ξεκινά με git-tfs-id: με κενό, το οποίο το Git θα αγνοήσει.

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

Εάν το σύστημά μας δεν είναι ένα από τα παραπάνω, θα πρέπει να αναζητήσουμε έναν εισαγωγέα σε απευθείας σύνδεση —διατίθενται ποιοτικοί εισαγωγείς για πολλά άλλα συστήματα, όπως τα CVS, Clear Case, Visual Source Safe, ακόμη και έναν κατάλογο αρχειοθηκών. Εάν κανένα από αυτά τα εργαλεία δεν μας κάνει, έχουμε ένα πιο ανιγματώδες εργαλείο ή τέλος πάντων χρειαζόμαστε μια πιο εξατομικευμένη διαδικασία εισαγωγής, θα πρέπει να χρησιμοποιήσουμε την git fast-import. Αυτή η εντολή διαβάζει απλές οδηγίες από τη stdin και γράφει συγκεκριμένα δεδομένα Git. Είναι πολύ πιο εύκολο να δημιουργήσουμε αντικείμενα Git με αυτόν τον τρόπο από το να εκτελέσουμε τις εντολές του Git ή να προσπαθήσουμε να γράψουμε τα ανεπεξέργαστα αντικείμενα (για περισσότερες πληροφορίες, βλ. το [ch10-git-internals]). Με αυτόν τον τρόπο, μπορούμε να γράψουμε ένα script εισαγωγής που διαβάζει τις απαραίτητες πληροφορίες από το σύστημα από το οποίο εισάγουμε και εκτυπώνει απλές οδηγίες στη stdout. Στη συνέχεια μπορούμε να εκτελέσουμε αυτό το πρόγραμμα και να παροχετεύσουμε την έξοδό του μέσω της git fast-import.

Για μία γρήγορη επίδειξη, θα γράψουμε έναν απλό εισαγωγέα. Ας υποθέσουμε ότι εργαζόμαστε στον current, δημιουργούμε αντίγραφα ασφαλείας του έργου μας αντιγράφοντας περιστασιακά τον κατάλογο σε έναν χρονοσημασμένο back_YYYY_MM_DD κατάλογο αντιγράφων ασφαλείας και θέλουμε να τον εισαγάγουμε στο Git. Η δομή του καταλόγου μας μοιάζει με αυτό:

Για να εισαγάγουμε έναν κατάλογο Git, θα πρέπει να θυμηθούμε τον τρόπο με τον οποίο το Git αποθηκεύει δεδομένα. Όπως έχει αναφερθεί, το Git είναι βασικά μια συνδεδεμένη λίστα αντικειμένων υποβολής που δείχνουν σε ένα στιγμιότυπο του περιεχομένου. Το μόνο που έχουμε να κάνουμε είναι να πούμε στην fast-import ποια είναι τα στιγμιότυπα του περιεχομένου, ποια δεδομένα υποβολών δείχνουν σε αυτά και τη χρονική σειρά τους. Η στρατηγική μας θα είναι να περάσουμε από όλα τα στιγμιότυπα ένα προς ένα και να δημιουργήσουμε υποβολές με τα περιεχόμενα κάθε καταλόγου, συνδέοντας κάθε υποβολή με την προηγούμενη.

Όπως κάναμε στην ενότητα Ένα παράδειγμα επιβολής πολιτικής από το Git, θα το γράψουμε σε Ruby, επειδή είναι αυτό που γενικά δουλεύουμε και είναι εύκολο να το διαβαστεί. Μπορούμε να γράψουμε αρκετά εύκολα το συγκεκριμένο script σε οποιαδήποτε γλώσσα με την οποία είμαστε εξοικειωμένοι —χρειάζεται μόνο να τυπώσουμε τις κατάλληλες πληροφορίες στη stdout. Και αν έχουμε Windows, αυτό σημαίνει ότι θα πρέπει να προσέξουμε να μην εισάγουμε χαρακτήρες επαναφοράς (CR) στο τέλος των γραμμών μας —η git fast-import είναι πολύ ιδιότροπη σε αυτό το θέμα και θέλει μόνο χαρακτήρες τροφοδότησης γραμμής (LF) και όχι χαρακτήρες επαναφοράς και τροφοδότησης γραμμής(CRLF) που χρησιμοποιούν τα Windows.

Αρχικά, θα μεταβούμε στον κατάλογο-στόχο και θα αναγνωρίσουμε κάθε υποκατάλογο, καθένας από τους οποίους είναι ένα στιγμιότυπο που θέλουμε να εισάγουμε ως υποβολή. Θα μεταβούμε σε κάθε υποκατάλογο και θα εκτυπώσουμε τις εντολές που είναι απαραίτητες για την εξαγωγή του. Ο βασικός μας κύριος βρόχος μοιάζει με αυτόν:

Εκτελούμε την print_export μέσα σε κάθε κατάλογο, ο οποίος λαμβάνει το δηλωτικό και το σημάδι του προηγούμενου στιγμιότυπου και επιστρέφει το δηλωτικό και το σημάδι αυτού. Με αυτόν τον τρόπο, θα μπορέσουμε να τα συνδέσουμε σωστά. “Σημάδι” (mark) είναι ο όρος της fast-import για ένα αναγνωριστικό που δίνουμε σε μια υποβολή· όταν δημιουργούμε υποβολές, δίνουμε σε καθεμία από αυτές ένα σημάδι το οποίο μπορούμε να χρησιμοποιήσουμε για να συνδεθούμε σε αυτήν από άλλες υποβολές. Έτσι, το πρώτο πράγμα που πρέπει να κάνουμε στη μέθοδο print_export μας είναι να δημιουργήσουμε ένα σημάδι από το όνομα του καταλόγου:

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

Τώρα που έχουμε μια ακέραια αναπαράσταση της υποβολής μας, χρειαζόμαστε μια ημερομηνία για τα μεταδεδομένα της υποβολής. Επειδή η ημερομηνία εκφράζεται στο όνομα του καταλόγου, θα την εξάγουμε κάνοντας συντακτική ανάλυση. Η επόμενη γραμμή στο αρχείο print_export είναι:

όπου η convert_dir_to_date ορίζεται ως:

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

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

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

Η μορφή αποτελείται από τη λέξη data, το μέγεθος των προς ανάγνωση δεδομένων, μια νέα γραμμή και τελικά τα δεδομένα. Επειδή πρέπει να χρησιμοποιήσουμε την ίδια μορφή για να καθορίσουμε αργότερα τα περιεχόμενα του αρχείου, δημιουργούμε μια βοηθητική μέθοδο, export_data:

Το μόνο που έχει απομείνει είναι να καθορίσουμε τα περιεχόμενα του αρχείου για κάθε στιγμιότυπο. Αυτό είναι εύκολο, επειδή το κάθε στιγμιότυπο είναι σε έναν κατάλογο —μπορούμε να εκτυπώσουμε την εντολή deleteall ακολουθούμενη από τα περιεχόμενα κάθε αρχείου στον κατάλογο. Το Git θα καταγράψει στη συνέχεια κάθε στιγμιότυπο κατάλληλα:

Σημείωση: Επειδή πολλά συστήματα ντιμετωπίζουν τις αναθεωρήσεις τους ως μεταβολές από μία υποβολή σε μία άλλη, η fast-import μπορεί επίσης να λάβει εντολές με κάθε υποβολή για να καθορίσει ποια αρχεία έχουν προστεθεί, αφαιρεθεί ή τροποποιηθεί και ποια είναι τα νέα περιεχόμενα. Θα μπορούσαμε να υπολογίσουμε τις διαφορές μεταξύ των στιγμιότυπων και να δώσουμε μόνο αυτά τα δεδομένα, αλλά αυτό είναι πιο περίπλοκο —μπορούμε απλά να δώσουμε στο Git όλα τα δεδομένα και να αφήσουμε αυτό να καταλάβει τι γίνεται. Αν κάτι τέτοιο ταιριάζει καλύτερα στα δεδομένα μας, καλό είναι να ελέγξουμε τη σελίδα του εγχειριδίου για την fast-import για λεπτομέρειες σχετικά με τον τρόπο παροχής των δεδομένων μας με αυτόν τον τρόπο.

Η μορφή εμφάνισης των νέων περιεχομένων του αρχείου ή ο προσδιορισμός ενός τροποποιημένου αρχείου με τα νέα περιεχόμενα είναι ο εξής:

Εδώ, 644 είναι ο τρόπος λειτουργίας (αν έχουμε εκτελέσιμα αρχεία, θα πρέπει να τα εντοπίσουμε και να θέσουμε τρόπο λειτουργίας 755 αντί 644), και η inline λέει ότι θα παραθέσουμε το περιεχόμενο αμέσως μετά από αυτήν τη γραμμή. Η μέθοδος inline_data μοιάζει με κάτι τέτοιο:

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

Το τελευταίο πράγμα που πρέπει να κάνουμε είναι να επιστρέψουμε το τρέχον σημάδι ώστε να μπορεί να μεταβιβαστεί στην επόμενη επανάληψη:

Αυτό ήταν. Ακολουθεί ολόκληρο το script:

Αν εκτελέσουμε αυτό το script, θα πάρουμε περιεχόμενο που μοιάζει με αυτό:

Για να τρέξουμε τον εισαγωγέα, παροχετεύουμε αυτήν την έξοδο μέσω της git fast-import ενώ βρισκόμαστε στον κατάλογο Git που θέλουμε να εισάγουμε. Μπορούμε να δημιουργήσουμε ένα νέο κατάλογο και στη συνέχεια να εκτελέσουμε την git init μέσα σε αυτόν για να δημιουργήσουμε ένα σημείο εκκίνησης και στη συνέχεια να εκτελέσουμε το script μας:

Όπως μπορούμε να δούμε, όταν ολοκληρώενται με επιτυχία, μας δίνει μια κάμποσα στατιστικά για το τι έχει επιτύχει. Σε αυτήν την περίπτωση, εισάγαμε 13 αντικείμενα συνολικά για 4 υποβολές σε 1 υποκατάστημα. Τώρα, μπορούμε να εκτελέσουμε την git log για να δούμε το νέο μας ιστορικό:

Αυτό ήταν! Ένα ωραίο, καθαρό αποθετήριο Git. Είναι σημαντικό να σημειώσουμε ότι τίποτα δεν έχει ανακτηθεί —αρχικά δεν έχουμε αρχεία στον κατάλογο εργασίας μας. Για να τα πάρουμε, πρέπει να επαναφέρουμε τον κλάδο μας στο σημείο όπου είναι τώρα ο master:

Μπορούμε να κάνουμε πολλά περισσότερα με το εργαλείο fast-import —να χειριστούμε διαφορετικά είδη, δυαδικά δεδομένα, πολλαπλούς κλάδους και συγχωνεύσεις, ετικέτες, δείκτες προόδου και πολλά άλλα. Ορισμένα παραδείγματα πιο σύνθετων σεναρίων είναι διαθέσιμα στον κατάλογο contrib/fast-import του πηγαίου κώδικα του Git.