<?xml version="1.0" encoding="ISO-8859-15"?>
<rss version="2.0"><channel>
<title>git ja muutosalgebra</title>
<link>http://sange.fi/~atehwa/cgi-bin/piki.cgi/</link>
<description>Recent changes in git ja muutosalgebra</description>
<item><title>git ja muutosalgebra</title>
<link>http://sange.fi/~atehwa/cgi-bin/piki.cgi/git%20ja%20muutosalgebra</link>
<guid>http://sange.fi/~atehwa/cgi-bin/piki.cgi/#1406582600</guid>
<description>&lt;p&gt;&lt;ins&gt;(nettipäiväkirja 04.12.2012) Joudun opettelemaan [git]in 
käyttöä. Myönnän, että minulla on asennevammakin sen suhteen, mutta 
jotenkin ärsyttää, kun ne esittelevät gitin ominaisuuksia jotenkin 
edistyksellisinä. Gitissä on kaksi merge-tapaa, CVS:n ajoilta periytyvä 
3-way merge (jolle tiedetään paljon tapauksia, jossa on mahdotonta 
löytää järkevää merge basea; ks. esim. 
http://www.gelato.unsw.edu.au/archives/git/0504/2279.html) sekä 
loistava uusi rebase, joka tekee eri brancheissa oleville muutoksille 
käytännössä samaa kuin [darcs] eli linearisoi ne yhdeksi historiaksi. 
Nimi "rebase" tulee siitä, että muutokset pysyvät samoina mutta 
siirretään uuteen kontekstiin, toisten muutosten päälle.&lt;/ins&gt; 

&lt;p&gt;&lt;ins&gt;Hyvä, git osaa tehdä mergejä samaan tapaan kuin darcs. Paitsi 
että: toisiin repositoryihin siirrettyjä muutoksia ei voi yhdistellä 
rebasella, koska niistä tulee rebasen jälkeen uusia muutoksia, ja 
ihmisille on haittaa molempien muutosten saamisesta. Darcs selviää 
tästä tilanteesta sillä, että muutoksella on identiteetti (tunniste), 
jonka perusteella darcs tietää sen samaksi muutokseksi, vaikka se 
olisikin kommutoitu eri kontekstiin (darcsin perustoimintoja on 
patchien järjestyksen muuttelu siten, että lopputulos pysyy samana). 
Git ei voi tehdä näin, koska se ei seuraa muutoksia vaan muutosten 
lopputuloksia, ja rebasen jälkeen muutos ''on'' eri muutos, koska siitä 
on eri lopputulos.&lt;/ins&gt; 

&lt;p&gt;&lt;ins&gt;Toinen järjestelmä, jolla on vaikeuksia muutosten yhdistelyssä 
mielivaltaisessa järjestyksessä, on [GNU arch]. Arch kylläkin 
käsittelee muutoksia muutoksina, mutta ei takaa, että muutokset 
tuottavat saman lopputuloksen tultuaan yhdistellyiksi eri 
järjestyksissä. Niinpä jokainen muutosten yhdistelmä vaatii oman merge 
patchinsa, jotka sitten voivat taas olla konfliktissa.&lt;/ins&gt; 

&lt;p&gt;&lt;ins&gt;* [merkintä: 2012-12] * [atehwa] * [kategoria: 
päiväkirjamerkintä] * [muutosten merge] * [versionhallinta]&lt;/ins&gt;

</description>
<pubDate>Mon, 28 Jul 2014 21:23:20 +0000</pubDate>
</item>

</channel></rss>
