commonmarker 0.0.1 → 0.1.0

data/test/progit/latex/template.tex

@@ -0,0 +1,155 @@
+\documentclass[a4paper]{book}
+\usepackage[
+	%urlbordercolor = {1 1 1},
+	%linkbordercolor = {1 1 1},
+	%citebordercolor = {1 1 1},
+	urlcolor = blue,
+	colorlinks = true,
+	citecolor = black,
+	linkcolor = black]{hyperref}
+\usepackage{graphicx}
+\usepackage{xltxtra}
+\usepackage{fancyhdr}
+\usepackage{booktabs}
+\usepackage{indentfirst}
+\usepackage{framed,color}
+\usepackage{caption}
+\usepackage{longtable}
+\captionsetup{font=bf,position=below}
+
+\usepackage{ctable}
+
+\definecolor{shadecolor}{gray}{0.90}
+
+\setromanfont[Mapping=tex-text,BoldFont=<%= config['bold'] %>]{<%= config['font'] %>}
+\setmonofont[Scale=.85]{<%= config['mono'] %>}
+
+\XeTeXlinebreaklocale{<%= lang %>}
+<%= config['langrule'] %>
+
+\settowidth{\parindent}{<%= config['indent'] %>}
+
+\title{Pro Git}
+\author{Scott Chacon}
+
+\makeatletter
+\let\savedauthor=\@author
+\let\savedtitle=\@title
+\def\imgwidth{.6\linewidth}
+\def\maxwidth{\ifdim\Gin@nat@width>\imgwidth\imgwidth
+\else\Gin@nat@width\fi}
+\makeatother
+
+\title{\textbf{\savedtitle}}
+\author{\textbf{\savedauthor}\thanks{<%= config['thanks'] %>}}
+\def\w3cdtfymd{\the\year-\ifnum\month<10 0\fi\the\month-\ifnum\day<10 0\fi\the\day}
+\date{\w3cdtfymd}
+\renewcommand{\thefootnote}{\fnsymbol{footnote}}
+
+\makeatletter
+  \setlength\headheight{12\p@}
+  \setlength\headsep   {.25in}
+  \setlength\topskip   {10\p@}
+  \setlength\footskip{.35in}
+  \setlength\textwidth{400\p@}
+  
+  \setlength\@tempdima{\paperheight}
+  \addtolength\@tempdima{-2in}
+  \divide\@tempdima\baselineskip
+  \@tempcnta=\@tempdima
+  \setlength\textheight{\@tempcnta\baselineskip}
+  \addtolength\textheight{\topskip}
+  
+  \setlength\@tempdima        {\paperwidth}
+  \addtolength\@tempdima      {-\textwidth}
+  \setlength\oddsidemargin    {\paperwidth}
+  \addtolength\oddsidemargin  {-2.35in}
+  \addtolength\oddsidemargin  {-\textwidth}
+  \setlength\marginparwidth   {0pt}
+  \@settopoint\oddsidemargin
+  \@settopoint\marginparwidth
+  \setlength\evensidemargin  {\paperwidth}
+  \addtolength\evensidemargin{-2.35in}
+  \addtolength\evensidemargin{-\textwidth}
+  \@settopoint\evensidemargin
+  
+  \setlength\topmargin{\paperheight}
+  \addtolength\topmargin{-2in}
+  \addtolength\topmargin{-\headheight}
+  \addtolength\topmargin{-\headsep}
+  \addtolength\topmargin{-\textheight}
+  \addtolength\topmargin{-\footskip}     % this might be wrong!
+  \addtolength\topmargin{-.5\topmargin}
+  \@settopoint\topmargin
+\makeatother
+
+\fancypagestyle{plain}{\fancyhf{}\fancyfoot[LE,RO]{\footnotesize\textbf\thepage}}
+\pagestyle{plain}
+
+\renewcommand{\headrulewidth}{0pt}
+\renewcommand{\footrulewidth}{0pt}
+
+\newcounter{img}[chapter]
+\renewcommand{\theimg}{\thechapter.\arabic{img}}
+\newcommand{\img}[1]{\begin{figure}[ht!]
+	\refstepcounter{img}
+	\label{img:\theimg}
+	\centering\IfFileExists{figures/\theimg.pdf}{\includegraphics[width=\maxwidth]{figures/\theimg.pdf}}{\includegraphics[width=\maxwidth]{figures/\theimg.png}}
+
+	\caption{#1}
+\end{figure}}
+
+\newcounter{tab}[chapter]
+\renewcommand{\thetab}{\thechapter.\arabic{tab}}
+
+\newcommand{\prechap}{<%= config['prechap'] %>}
+\newcommand{\postchap}{<%= config['postchap'] %>}
+\newcommand{\presect}{<%= config['presect'] %>}
+\newcommand{\postsect}{<%= config['postsect'] %>}
+\renewcommand{\chaptermark}[1]{\markboth{\textbf{\prechap \thechapter \postchap}\hspace*{1ex}#1}{}}
+\renewcommand{\sectionmark}[1]{\markright{\textbf{\presect \thesection \postsect}\hspace*{1ex}#1}}
+\newcommand{\chap}[1]{\newpage\thispagestyle{empty}\chapter{#1}\label{chap:\thechapter}}
+\newcommand{\chapref}[1]{\hyperref[chap:#1]{\prechap #1\postchap}}
+\newcommand{\imgref}[1]{\hyperref[img:#1]{<%= config['fig'] %>#1}}
+\newcommand{\tabref}[1]{\hyperref[tab:#1]{<%= config['tab'] %>#1}}
+\newcommand{\e}[1]{$ \times 10^{#1}$}
+\renewcommand{\contentsname}{<%= config['con'] %>}
+\renewcommand{\figurename}{<%= config['fig'] %>}
+\renewcommand{\tablename}{<%= config['tab'] %>}
+
+\makeatletter
+\def\@makechapterhead#1{%
+  \vspace*{50\p@}%
+  {\parindent \z@ \raggedright \normalfont
+    \ifnum \c@secnumdepth >\m@ne
+      \if@mainmatter
+        \huge\bfseries \prechap \thechapter \postchap
+        \par\nobreak
+        \vskip 20\p@
+      \fi
+    \fi
+    \interlinepenalty\@M
+    \Huge \bfseries #1\par\nobreak
+    \vskip 40\p@
+  }}
+\makeatother
+
+\linespread{1.3}
+
+\begin{document}
+\frontmatter
+\maketitle
+\thispagestyle{empty}
+\setcounter{tocdepth}{4}
+\tableofcontents\newpage\thispagestyle{empty}
+
+\mainmatter
+\fancyhf{}
+\fancyhead[LE]{{\small\leftmark}}
+\fancyhead[RO]{{\small\rightmark}}
+\fancyhead[RE,LO]{{\small\savedauthor\hspace*{1ex}\textbf{\savedtitle}}}
+\fancyfoot[LE,RO]{\small\textbf\thepage}
+\pagestyle{fancy}
+
+<%= latex %>
+\end{document}

data/test/progit/makeebooks

@@ -0,0 +1,125 @@
+#!/usr/bin/env ruby
+# encoding: utf-8
+# This script convers markdown book to one of the serveral e-book
+# formats supported with calibre (http://calibre-ebook.com)
+#
+# Samples:
+#
+# Build e-book for amazon kindle for english and russian languages
+# 	$ ruby makeebooks en ru
+# or
+# 	$ FORMAT=mobi ruby makeebooks en ru
+#
+# Build e-book in 'epub' format for russian only
+# 	$ FORMAT=epub ruby makeebooks ru
+
+require 'rubygems'
+require 'rdiscount'
+require 'fileutils'
+include FileUtils
+
+def figures(lang,&block)
+	begin
+		Dir["figures/18333*.png"].each do |file|
+			cp(file, file.sub(/18333fig0(\d)0?(\d+)\-tn/, '\1.\2'))
+		end
+		Dir["#{lang}/figures/*.png"].each do |file|
+			cp(file,"figures")
+		end
+		Dir["#{lang}/figures-dia/*.dia"].each do |file|
+			png_dest= file.sub(/.*fig0(\d)0?(\d+).dia/, 'figures/\1.\2.png')
+			system("dia -e #{png_dest} #{file}")
+		end
+		block.call
+	ensure
+		Dir["figures/18333*.png"].each do |file|
+			rm(file.gsub(/18333fig0(\d)0?(\d+)\-tn/, '\1.\2'))
+		end
+	end
+end
+
+
+if ARGV.length == 0
+  puts "you need to specify at least one language. For example: makeebooks en"
+  exit
+end
+
+format = ENV['FORMAT'] || 'mobi'
+puts "using .#{format} (you can change it via FORMAT environment variable. try 'mobi' or 'epub')"
+
+ARGV.each do |lang|
+  figures (lang) do
+    puts "convert content for '#{lang}' language"
+
+    figure_title = 'Figure'
+    book_title = 'Pro Git - professional version control'
+    authors = 'Scott Chacon'
+    comments = 'licensed under the Creative Commons Attribution-Non Commercial-Share Alike 3.0 license'
+    if lang == 'ko'
+      figure_title = '그림'
+    elsif lang == 'ja'
+      figure_title = '図'
+    elsif lang == 'ru'
+      figure_title = 'Рисунок'
+      book_title = 'Pro Git — профессиональный контроль версий'
+      authors = 'Скот Чакон'
+      comments = 'Лицензия: Creative Commons Attribution-Non Commercial-Share Alike 3.0 license'
+    elsif lang == 'es'
+      figure_title = 'Figura'
+    elsif lang == 'it'
+      figure_title = 'Figura'
+      comments = 'distribuito sotto licenza Creative Commons Attribution-Non Commercial-Share Alike 3.0'
+    elsif lang == 'zh'
+      figure_title = '图'
+    elsif lang == 'zh-tw'
+      figure_title = '圖'
+    elsif lang == 'pt-br'
+      figure_title = 'Figura'
+    elsif lang == 'pl'
+      figure_title = 'Rysunek'
+      book_title = 'Pro Git — profesjonalna kontrola wersji'
+      comments = 'udostępnione na licencji Creative Commons Attribution-Non Commercial-Share Alike 3.0 license'
+    elsif lang == 'cs'
+      figure_title = 'Obrázek'
+      book_title = 'Pro Git — profesionální správa verzí'
+      comments = 'Licence: Creative Commons Attribution-Non Commercial-Share Alike 3.0 license'
+    elsif lang == "no-nb"
+        figure_title = 'Figur'
+        book_title = 'Pro Git - profesjonell versjonkontroll'
+        comments = 'Lisens: Creative Commons Attribution-Non Commercial-Share Alike 3.0 license'
+      
+    end
+
+    book_content = %(<html xmlns="http://www.w3.org/1999/xhtml"><head><title>#{book_title}</title></head><body>)
+    dir = File.expand_path(File.join(File.dirname(__FILE__), lang))
+    Dir[File.join(dir, '**', '*.markdown')].sort.each do |input|
+      puts "processing #{input}"
+      content = File.read(input)
+      content.gsub!(/Insert\s18333fig\d+\.png\s*\n.*?(\d{1,2})-(\d{1,2})\. (.*)/, '![\1.\2 \3](figures/\1.\2.png "\1.\2 \3")')
+      book_content << RDiscount.new(content).to_html
+    end
+    book_content << "</body></html>"
+
+    File.open("progit.#{lang}.html", 'w') do |output|
+      output.write(book_content)
+    end
+
+    $ebook_convert_cmd = ENV['ebook_convert_path'].to_s
+    if $ebook_convert_cmd.empty?
+      $ebook_convert_cmd = `which ebook-convert`.chomp
+    end
+    if $ebook_convert_cmd.empty?
+      mac_osx_path = '/Applications/calibre.app/Contents/MacOS/ebook-convert'
+      $ebook_convert_cmd = mac_osx_path
+    end
+
+    system($ebook_convert_cmd, "progit.#{lang}.html", "progit.#{lang}.#{format}",
+           '--cover', 'ebooks/cover.png',
+           '--authors', authors,
+           '--comments', comments,
+           '--level1-toc', '//h:h1',
+           '--level2-toc', '//h:h2',
+           '--level3-toc', '//h:h3',
+           '--language', lang)
+  end
+end

data/test/progit/makepdfs

@@ -0,0 +1,47 @@
+#!/bin/bash
+
+baseDir=`dirname $0`
+outputDir=${baseDir}/pdf
+
+exclude=('figures' 'figures-dia' 'figures-source' 'latex' 'makepdfs' 'pdf' 'README')
+dirContent=`ls $baseDir`
+argString=""
+
+  echo $i;
+
+for dir in $dirContent; do
+	if [ -n $dir ]; then
+		
+		isLang=1
+		for i in ${exclude[@]}; do
+			if [ $i == $dir ]; then
+				isLang=0
+			fi
+		done
+		
+		if [ $isLang -eq 1 ]; then
+			if [ "$1" = "" ]; then
+				argString="${argString} ${dir}"
+			else
+				for i in ${@}; do
+					if [ $i = $dir ]; then
+						argString="${argString} ${dir}"
+					fi
+				done
+			fi
+		fi
+	fi
+done
+
+echo "Will generate pdf for the following languages:"
+echo "	"$argString
+
+mkdir -p $outputDir
+
+echo 
+echo "The generation process will start now."
+time ${baseDir}/latex/makepdf $argString
+
+echo
+echo
+echo "Done!"

data/test/progit/mk/01-introduction/01-chapter1.markdown

@@ -0,0 +1,258 @@
+# Како да започнам #
+
+Ова поглавје се однесува на тоа како да започнете со Git.  На почетокот ќе започнеме со објаснување на позадината на алатките за контрола на верзии, понатаму ќе продолжиме со тоа како да го покренете Git на вашиот систем и конечно како да го подесите и да работите со него.  На крајот од ова поглавје ќе разберете зошто е направен Git, зошто треба да го користите и што се треба да направите за да го користите.
+
+## За контрола на верзиите ##
+
+Што е контрола на верзии, и зошто би требало да се грижите? Контрола на верзии е систем кој што ги бележи промените во една датотека или во група од датотеки со текот на времето така што подоцна би можеле да се вратите на одредена верзија. За примерите во оваа книга ќе користите изворен код од софтвер како датотеки кои што ќе бидат верзионирани, инаку истото можете да го правите со било каков тип на датотеки.
+
+Ако си графички дизајнер и сакаш да ја сочуваш секоја верзија од сликата или нацртот (секако дека би сакал), тогаш користење на Систем за Контрола на Верзии (VCS од англиски Version Control System) е разумен начин да се постигне тоа. Тој ви овозможува одредени датотеки да ги вратите во претходна состојба, целиот проект да го вратите во претходна состојба, да ги споредите измените кои што се направени во одреден временски период, да видите кој последен менувал и дали тоа предизвикало некој проблем, кој и кога вовел неправилност итн. Користење на VCS генерално значи дури и да уништите или изгубите датотеки, секогаш може лесно да ги вратите назад. Дополнително, сето тоа го добивате за сосема мал напор.
+
+### Локални системи за контрола на верзии ###
+
+Многу луѓе како систем за верзионирање го користат методот на копирање на датотеките во друга папка (можеби папка со датум во името). Овој пристап е многу вообичаен затоа што е едноставен, но неверојатно многу е склон на грешки. Многу е лесно да заборавите во која папка се наоѓате моментално, и по грешка да запишете или да пребришете датотека.
+
+За да се справат со овој проблем, програмерите одамна развиле локални VCS-и кои што имале едноставна база во која што се бележеле сите промени во датотеките кои што биле ставен под системот за контрола на верзиите (види Сл 1-1).
+
+Insert 18333fig0101.png 
+Слика 1-1. Дијаграм на локален систем за контрола на верзиите.
+
+Еден од попопуларните VCS алатки бил системот наречен rcs, кој што и денеска сеуште се користи. Дури и популарниот Mac OS X оперативен систем ја вклучува наредбата rcs кога ќе инсталирате развојни алатки. Оваа алатка работи на тој начин што чува серија од закрпи (разлики помеѓу датотеките) од една до друга промена во специјален формат на дискот; понатаму на тој начин може да ја добие секоја состојба што ја имала датотеката во одредено време со додавање на закрпите.
+
+### Централизирани системи за контрола на верзиите ###
+
+Следен голем проблем со кој што се судриле луѓето е неможноста да колаборираат со програмерите на други системи. За да се разреши овој проблем биле развиени Централизи-рани Системи за Контрола на Верзиите (CVCSs - Centralized Version Control Systems). Овие системи, како што се CVS, Subversion, и Perforce, имаат централен сервер кој што ги содржи сите верзионирани датотеки, и голем број на клиенти кои што ги менуваат или прегледуваат датотеките од тоа централно место. Многу години тоа беше стандард за контрола на верзиите (види Слика 1-2).
+
+Insert 18333fig0102.png 
+Слика 1-2. Дијаграм на централизиран систем за контрола на верзиите.
+
+Ваквата поставка нуди многу предности, особено во однос на локалните VCS-и. На пример, секој во одредена мерка знае што работат другите на проектот. Администраторите фино може да подесат кој што може да работи, и далеку е поедноставно да се администрира CVCS отколку да се администрираат базите на секој клиент.
+
+Но, ваквата поставка исто така има и сериозни недостатоци. Најочигледен е тоа што постои една точка која доколку откаже целиот систем ќе престане да функционира, а таа точка е централниот сервер. Ако тој сервер биде исклучен еден час на пример, во тој час никој воопшто нема да може да колаборира, ниту пак да ги зачува верзионираните промени на она на што работи. Доколку хард-дискот се корумпира, и доколку не постои соодветен бекап, тогаш апсолутно се е загубено - целосниот историјат на проектот, освен копиите кои што луѓето случајно би ги имале на локалните компјутери. Локалните VCS системи се подложни на истите проблеми - доколку целосната историја на проектот е на едно место, тогаш ризикувате да загубите се.
+
+### Дистрибуирани системи за контрола на верзиите ###
+
+Тука стапуваат на сцена Дистрибуираните Системи за Контрола на Верзиите (DVCSs - Distributed Version Control Systems). Кај DVCS (како што е Git, Mercurial, Bazaar или Darcs), клиентите не ја прегледуваат само последната состојба од датотеките туку прават целосна копија од репозиторито. Така, доколку некој од серверите биде уништен, било која копија од клиентите може да биде земена за да се реставрира серверот. Секое прегледување е целосен бекап на сите податоци (види Слика 1-3).
+
+Insert 18333fig0103.png 
+Слика 1-3. Дијаграм на дистрибуирани системи за контрола на верзиите.
+
+Дополнително, многу од овие системи одлично се снаоѓаат при работа со повеќе оддале-чени репозиторија, така што можете да колаборирате со различни групи луѓе на различни начини истовремено во рамките на ист проект. Тоа ви овозможува да поставите повеке типови на начини на работа кои што не се возможни во централизираните системи, како што се хиерархискиот модели.
+
+## Кратка историја на Git ##
+
+Како и со многу големи работи во животот, Git настана со мала креативна деструкција и жестока расправија. Линукс кернелот е проект со отворен код и сосема широк делокруг. Одржувањето за поголемиот дел од животниот век на Линукс кернелот (1991-2002) се одвивалот на тој начин што измените во софтверот се предавале како закрпи и архиви. Во 2002 Линукс кернел проектот почнал да користи лиценциран DVCS систем наречен BitKeeper.
+
+Во 2005, врската помеѓу заедницата која што го развиваше Линукс кернелот и компанијата која што го разви BitKeeper се распадна, и алатката повеќе не можеше да се користи бесплатно. Тоа и наложи на Линукс развојната заедница (а посебно на Линус Торвалдс, авторот на Линукс) да развијат сопствена алатка базирана на некои лекции кои што ги научија додека го користеа BitKeeper. Некои од целите на новиот систем беа:
+
+*	Брзина
+*	Едноставен дизајн
+*	Силна подршка за не-линеарен начин на развој (илјадници паралелни гранки на развој)
+*	Целосно дистрибуиран
+*	Ефикасно да може да подржи големи проекти како Линукс кернелот (брзина и количина на податоци)
+
+Од неговото раѓање во 2005, Git еволуираше во систем кој што е лесен за користење и сеуште ги задржува иницијалните цели. Тој е извонредно брз, многу ефикасен со големи проекти, и има извонреден систем за гранање за не-линеарен начин на развој (Види поглавје 3).
+
+## Основи на Git ##
+
+Во неколку збора, што е Git? Оваа секција е многу битно да ја разберете, бидејќи ако разберете што е Git и основите како работи, тогаш ефикасното користење на Git веројатно ќе биде многу едноставно за вас. Додека учите за Git, пробајте да ги изолирате работите што евентуално ги знаете за другите VCS, како што е Subversion и Perforce; на тој начин ќе ја избегнете забуната при користењето на алатката. Git ги складира и обработува информациите многу поразлично од другите системи, иако корисничкиот интерфејс е прилично сличен; доколку ги разберете тие разлики ќе ги избегнете забуните при неговото користење.
+
+### Целосни слики, наместо закрпи ###
+
+Најголемата разлика помеѓу Git и било кој друг VCS (Subversion и сл.) е во начинот на кој Git ги обработува податоците. Концептуално, повеќето други системи информациите ги складираат како листа од промени над поединечните датотеки. Тие системи (CVS, Subversion, Perforce, Bazaar итн) информациите ги чуваат како множества од датотеки и промените настанати над тие датотеки со текот на времето, како што е прикажано на Слика 1-4.
+
+Insert 18333fig0104.png 
+Слика 1-4. Другите системи чуваат закрпи за секоја датотека.
+
+Git не ги третира или чува податоците на тој начин. Наместо тоа, Git податоците ги третира како множества од целосни слики/копии од мини фајлсистем. Секогаш кога сакате да ја зачувате состојбата во која се наоѓа проектот во Git, тој едноставно прави слика од тоа како изгледаат сите датотеки во тој момент и зачувува референца до таа слика. За да биде ефикасен, доколку датотеките не се променети, Git не прави копија од датотеките туку само прави линк до претходно зачуваната идентична датотека. Git ги третира податоците како што е прикажано на сликата 1-5.
+
+Insert 18333fig0105.png 
+Слика 1-5. Git ги зачувува податоците како целосни копии од проектот.
+
+Ова е битна разлика помеѓу Git и речиси сите други VCS. Со тоа Git ги преиспитува речиси сите аспекти од системите за контрола на верзиите, за разлика од другите системи кои што едноставно ги копирале од претходните генерации. Тоа го прави Git да личи помалку на мини фајлсистем со извонредно моќни алатки над него, отколку како едноставен VCS. Ќе ги истражиме придобивките од таквото третирање на податоците при обработка на гранањето во Git во Поглавје 3.
+
+### Речиси секоја операција е локална ###
+
+За повеќето операции што ги изведува Git му се потребни само локални датотеки и ресурси - генерално никакви информации од друг компјутер на мрежата не се потребни. Ако сте навикнати на користење на CVCS каде што повеќето операции имаат мрежна латенција, овој аспект на Git ќе ве натера да си помислите дека боговите на брзината го надариле Git со неискажлива моќ. Бидејќи целосниот историјат од проектот го имате локално на вашиот хард диск, повеќето операции изгледаат речиси моментални.
+
+На пример, за да ја прегледате историјата на проектот, Git не треба да оди до серверот за да ја земе историјата и да ви ја прикаже - туку едноставно ја чита директно од вашата локална база на податоци. Тоа значи дека историјатот на проектот го гледате речиси моментално. Доколку сакате да ги видите разликите помеѓу сегашната верзија на некоја датотека и верзијата од пред еден месец, Git може да ја види состојбата на датотеката од пред еден месец и локално да ви ги пресмета разликите, наместо да испрати барање за тоа до оддалечен сервер, или пак да побара постара верзија за датотеката од некој сервер за да ја пресмета разликата локално.
+
+Тоа значи дека нема многу работи кои што нема да може да ги направите доколку сте офјалн или не сте на VPN. Доколку се качите на авион или воз, и сакате малку да поработите, можете да правите нови состојби од проектот (commit) се додека не добиете мрежна врска и тогаш ќе ги аплоадирате. Ако сте дома и не може да го натерате вашиот VPN клиент да проработи, сепак можете да си работите на проектот. Кај многу други системи, ваквиот начин на работа или е невозможен или многу тешко изводлив. Со Perforce, на пример, речиси ништо не можете да правите доколку немате конекција со серверот; кај Subversion и CVS, може да ги едитирате датотеките, меѓутоа не може да направите нова состојба од проектот (commit) бидејќи базата на податоци е на сервер. Можеби сето ова не изгледа како некоја голема работа, меѓутоа може да се изненадите колкава разлика може да ви направи.
+
+### Git има интегритет ###
+
+Пред да се зачуваат работите во Git, им се пресметува контролна сума, а подоцна истите работи се референцираат преку таа сума. Тоа значи дека е невозможно да се промени содржината на некоја датотека без Git да дознае за тоа. Тоа функционалност е вградена во Git во најниските нивоа и е интегрален дел од неговата филозофија. Не може да изгубите информација при пренос или да имате корумпирана датотека без Git да го детектира тоа.
+
+Механизмот кој што го користи Git за пресметување на контролната сума се вика SHA-1 хеш. Тоа е стринг од 40 знаци составен од хексадекадни знаци (0-9 и a-f) и се пресметува врз основа на содржината на датотеката или папката во Git. SHA-1 хешот изгледа отприлика вака:
+
+	24b9da6552252987aa493b52f8696cd6d3b00373
+
+Насекаде ќе ги гледате ваквите хеш вредности во Git затоа што тој насекаде ги користи. Всушност, Git сите работи ги зачувува не според името на датотеката, туку во база на податоци која е адресабилна според хеш вредноста на нивната содржина.
+
+### Во основа Git само додава податоци ###
+
+Кога изведувате операции во Git, речиси сите тие само додаваат податоци во Git базата на податоци. Речиси е невозможно да го натерате системот да направи нешто што подоцна не може да се врати на претходната состојба, или пак да го натерате да избрише некои податоци. Како и со секој VCS, може да ги загубите податоците кои што не сте ги комитувале; но откако ќе ги комитувате и кога Git ќе направи слика од тоа, тогаш навистина е тешко да загубите нешто, особено доколку редовно вашата база ја синхронизирате (push) со друго репозитори.
+
+Тоа го прави користењето на Git вистинско задоволство бидејќи знаеме дека може да експериментираме без притоа да се плашиме дека може да ги уништиме работите. Поде-тално за тоа како Git ги складира податоците и како може да ги реставрирате податоците кои изгледаат дека се загубени погледнете во "Под хаубата" во поглавје 9.
+
+### Трите нивоа ###
+
+Сега внимавајте. Ова е главната работа што треба да се запомни за Git доколку сакате понатамошниот процес на учење да ви оди лесно. Git има три нивоа во кои што може да се најдат датотеките: комитувани (committed), променети (modified) и поставени (staged). Комитувани значи дека податоците безбедно се зачувани во локалната база на податоци. Променети значи дека датотеките се променети, меѓутоа сеуште не се комитувани. Поста-вени (staged) значи дека сте ги маркирале променетите датотеки во нивната тековна состојба да бидат зачувани во следниот комит.
+
+Тоа не води до главните три секции од еден Git проект: Git папката, работна папка, и сцена (staging area).
+
+Insert 18333fig0106.png 
+Слика 1-6. Работна папка, сцена, и git папката.
+
+Git папката е местото каде што Git ги складира мета-податоците и базата на податоци за вашиот проект. Тоа е најзначајниот дел од Git, и тоа е она што се копира кога клонирате репозитори од друг компјутер.
+
+Работната папка е поглед (checkout) на една верзија/состојба од проектот. Датотеките се извлечени од компресираната база на податоци од Git папката и се поставени на хард дискот за да ги користите или менувате.
+
+Сцена (staging area) е едноставна датотека, обично е сместена во Git папката, и во неа се наоѓаат информации за тоа што ќе оди во следниот комит. Понекогаш за ова се користи терминот индекс (index), но се поприфатен термин е да се нарекува сцена (staging area).
+
+Вообичаениот начин на работа со Git отприлика изгледа вака:
+
+1. Ги менувате датотеките од вашата локална папка.
+2. Ги поставувате датотеките на сцена, т.е. се прават слики од нив и се додаваат на сцената (staging area).
+3. Правите комит, кој што ги зема датотеките како што се поставени на сцената и таа слика перманентно ја зачувува во локалната Git папка.
+
+Ако одредена верзија од датотеката се наоѓа во git папката, тогаш таа се смета за комитува-на. Доколку датотеката е променета и ако е додадена на сцена (staging area) тогаш таа се наоѓа во нова состојба - staged. Доколку пак датотеката е променета во однос на тоа кога е направен нов поглед во Git (checkout), и доколку променетата состојба не е додадена на сцена, тогаш датотеката едноставно се наоѓа во состојба која се нарекува променета. Во поглавје 2, ќе научите повеќе за тие состојби и како истите да ги искористите, или пак комплетно да го прескокнете чекорот од додавање на датотеката на сцена.
+
+## Инсталација на Git ##
+
+Да почнеме со користење на Git. Како прво треба да го инсталирате. Може да дојдете до него на повеќе начини, двата најчести начини се да го инсталирате од изворен код или да го инсталирате како постоечки пакет за вашата платформа.
+
+### Инсталација од изворен код ###
+
+Доколку сте во можност, генерално е покорисно да го инсталирате Git од изворен код, бидејќи на тој начин ја добивате најновата верзија. Секоја верзија од Git се труди да вклучи корисни подобрувања во корисничкиот интерфејс, па земајќи ја најновата верзија на Git од изворниот код вообичаено е најдобро доколку се чувствувате спремни да компајлирате софтвер од изворен код. Исто така чест случај е многу Линукс дистрибуции да содржат многу стари пакети; па освен ако ја немате најажурираната дистрибуција, инсталацијата на Git од изворен код е најсигурниот потег.
+
+За да го инсталирате Git, треба да ги имате овие библиотеки од кои што зависи Git: curl, zlib, openssl, expat, и libiconv. На пример доколку користите систем кој што има yum (како што е Fedora) или пак apt-get (како што се Debian базираните дистрибуции), може да повикате една од овие наредби за да ги инсталирате сите овие зависности:
+
+	$ yum install curl-devel expat-devel gettext-devel \
+	  openssl-devel zlib-devel
+
+	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
+	  libz-dev
+	
+Кога ќе ги имате сите овие зависности разрешено, може да ја симнете најновата верзија од Git сајтот:
+
+	http://git-scm.com/download
+	
+Потоа, компајлирајте го и инсталирајте го:
+
+	$ tar -zxf git-1.6.0.5.tar.gz
+	$ cd git-1.6.0.5
+	$ make prefix=/usr/local all
+	$ sudo make prefix=/usr/local install
+
+Откако ќе го направите сетоа тоа, исто така ќе можете најновите измени во Git да ги земате преку самиот Git:
+
+	$ git clone git://git.kernel.org/pub/scm/git/git.git
+	
+### Инсталирање на Линукс ###
+
+Доколку сакате да го инсталирате Git на Линукс преку бинарен инсталатер, тоа може да го направите преку алатките за менеџирање на пакети кои што доаѓаат со вашата дистрибуција. Доколку користите Fedora, може да користите yum:
+
+	$ yum install git-core
+
+Или пак доколку користите Debian-базирани дистрибуции како Ubuntu, пробајте со apt-get:
+
+	$ apt-get install git
+
+### Инсталирање на Мекинтош ###
+
+Постојат два лесни начини како да го инсталирате Git на Мекинтош. Најлесниот е да го користите графичкиот Git инсталатор, кој што може да го симнете до SourceForge страната (види слика 1-7):
+
+	http://sourceforge.net/projects/git-osx-installer/
+
+Insert 18333fig0107.png 
+Слика 1-7. Git OS X инсталатор.
+
+Другиот начин е да го инсталирате Git преку MacPorts (`http://www.macports.org`).
+Доколку веќе го имате инсталирано MacPorts, тогаш инсталирајте го Git преку
+
+	$ sudo port install git-core +svn +doc +bash_completion +gitweb
+
+Не мора да ги имате сите додатоци, но најверојатно би сакале да го вклучите +svn во случај да сакате да го користите Git со Subversion репозиторија (види поглавје 8).
+
+### Инсталирање на Windows ###
+
+Инсталирањето на Git на Windows е многу едноставно. msysGit проектот има еден од најлесните инсталациски процедури. Едноставно симнете го инсталерот од GitHub страната, и стартувајте го:
+
+	http://msysgit.github.com/
+
+По инсталацијата, ги имате и верзијата од командна линија (вклучувајќи SSH клиент кој што ќе ви се најде подоцна) и верзија со стандарден графички интерфејс.
+
+## Прво поставување на Git ##
+
+Сега кога го имате Git на вашиот систем, ќе сакате да направите неколку работи за да ја подесите вашата Git околина. Овие работи треба да ги направите само еднаш, и тие ќе си останат такви и после надградбите. Исто така може да ги промените во било кое време извршувајќи соодветни наредби.
+
+Git доаѓа со алатка наречена git config која што ви овозможува да прегледате и да ги поставите конфигурациските променливи кои што ги контролираат сите аспекти за тоа како изгледа и како се однесува Git. Тие променливи може да бидат поставени на три различни места:
+
+*	`/etc/gitconfig` датотека: Содржи параметри за сите корисници на системот и сите нивни репозиторија. Ако го додадете аргументот` --system` на `git config`, тогаш тој чита и запишува од оваа датотека.
+*	`~/.gitconfig` датотека: Специфична за секој корисник. Git чита и запишува во оваа датотека со додавање на аргументот `--global`. 
+*	конфигурациска датотека во git папката (т.е., `.git/config`) од репозиторито кое момен-тално го користите: Се однесува единствено на тоа репозитори. Секое ниво ги засенува вредностите од претходното ниво, па така, вредностите во `.git/config` ги засенуваат вредностите во `/etc/gitconfig`.
+
+На Windows системите, Git ја бара `.gitconfig` датотеката во `$HOME` папката (најчесто `C:\Documents and Settings\$USER`). Исто така ја бара и /etc/gitconfig, иако таа патека е релативна во однос на MSys коренот, кој се наоѓа онаму каде што сте одлучиле да го инсталирате Git на Windows.
+
+### Вашиот идентитет ###
+
+Прва работа што треба да ја направите по инсталирањето на Git е да го подесите вашето име и e-mail адреса. Ова е важно затоа што секој Git комит ги користи тие информации, и истите се вградени во секој комит што ќе го направите:
+
+	$ git config --global user.name "John Doe"
+	$ git config --global user.email johndoe@example.com
+
+Ова треба да го направите само еднаш доколку како аргумент во наредбата ја користите `--global` опцијата, бидејќи во тој случај Git секогаш ќе ги користи тие информации за сите активности што ги изведувате на тој систем. Доколку за одреден проект сакате да користите поинакво име и e-mail адреса, тогаш повикајте ги наредбите без `--global` опцијата кога се наоѓате во тој проект.
+
+### Вашиот едитор ###
+
+Сега кога вашиот идентитет е подесен, може да подесите и кој стандарден текстуален едитор ќе биде користен од Git кога ќе треба да внесете некоја порака. Стандардно, Git како едитор ќе го користи системскиот стандарден едитор, кој што вообичаено е Vi или Vim. Доколку сакате да користите друг текстуален едитор како што е Emacs, тоа може да го направите на следниов начин:
+
+	$ git config --global core.editor emacs
+	
+### Вашата Diff алатка ###
+
+Друга корисна опција која што можеби би сакале да ја подесите е која diff алатка да се користи за разрешување на конфликти при спојување (merge) на гранки. Доколку за таа намена сакате да го користите vimdiff:
+
+	$ git config --global merge.tool vimdiff
+
+Git ги прифаќа kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge и opendiff како валидни алатки за разрешување конфликти. Исто така за таа намена може да подесите и произволна алатка - за повеќе информации како се прави тоа видете во поглавје 7.
+
+### Прегледување на вашите подесувања ###
+
+Доколку сакате да ги проверите вашите подесувања, може да ја користите наредбата `git config --list` за да ги излистате сите подесувања кои ги користи Git во тој момент:
+
+	$ git config --list
+	user.name=Scott Chacon
+	user.email=schacon@gmail.com
+	color.status=auto
+	color.branch=auto
+	color.interactive=auto
+	color.diff=auto
+	...
+
+Можеби ќе видите ист клуч повеќе пати, бидејќи Git го чита истиот клуч од различни датотеки (`/etc/gitconfig` и `~/.gitconfig`, на пример). Во тој случај, Git ја користи последната вредност за секој пронајден клуч.
+
+Може да проверите која вредност ја користи Git за некој клуч со испишување на `git config {key}`:
+
+	$ git config user.name
+	Scott Chacon
+
+## Добивање помош ##
+
+Доколку ви затреба помош околу користењето на Git, постојат три начини да ги добиете страниците со кориснички упатства (manpage) за било која Git наредба:
+
+	$ git help <verb>
+	$ git <verb> --help
+	$ man git-<verb>
+
+На пример, корисничкото упатство за config наредбата го добивате со извршување на наредбата
+
+	$ git help config
+
+Овие наредби се корисни бидејќи може да ги извршите билокаде, дури и офлајн.
+Доколку страниците со кориснички упатства и оваа книга не ви се доволни, и ви треба лице за контакт, може да се обидете на `#git` или `#github` каналите на Freenode IRC серверот (irc.freenode.net). Овие канали вообичаено се посетени од стотици луѓе кои се одлични познавачи на Git и честопати се спремни да ви помогнат.
+
+## Преглед ##
+
+Би требало да добиете основно разбирање за тоа што е Git и колку е различен од CVCS кој можеби сте го користеле. Исто така сега би требало да имате работна верзија од Git на вашиот систем каде што е подесен вашиот идентитет. Сега е време да научите за некои основни работи во Git.