Miten Git-historia saadaan vastaamaan lainsäädäntöhistoriaa?

[pe3]

FODE-ryhmän keskustelussa heitettiin ajatus, että olisi hienoa, jos Suomen lakia voisi selata GitHubissa historiallisessa tapahtumajärjestyksessä. Tai ainakin niin keskustelun itse ymmärsin. Minusta se olisi aivan mahtavaa. Tällöin minkä tahansa nykylainlain nykymuodon alkuperän voisi helposti selvittää blame toiminnolla. Tähän tavoitteeseen pääseminen ei kuitenkaan git-teknisesti ole aivan helppoa.

Historiallinen git-historia vaatisi rankkaa git-historian uudelleenkirjoittamista ja Git:in kaikkein monimutkaisimpien toimintojen käyttämistä. Pelkästään lakitekstejä lisäämällä ja muokkaamalla päädytään tätä lakitekstin GitHubiin keräämistä kuvaavaan git-historiaan. Eli että päivänä x käyttäjä y lisäsi vuoden z version repoon.

Historiallista muutoshistoriaa rakennettaessa haluttaisiin enemminkin väärentää git-historiaa, niin että commitin time stamp viittaisi vuoteen 1889 ja commitin tehnyt käyttäjä olisi lain säätänyt elin. Nuo ovat varmasti vielä kohtuu helposti tehtävissä. Haastavampaa lienee committien järjestyksen muuttaminen. Tähän repoon pitää pystyä seuraavaksi tuomaan tämän päivän lakiversio, siten että 1900-luvulla säädetty version voidaan lisätä vasta joskus myöhemmin, kun ne yllättäen jostakin löytyvät. Kaikkein haastavinta lienee kuitenkin GitHubin käyttäminen yhteistyöalustana samalla kun repon historiaa muokataan. Muokkauksien pitäisi nimittäin välittyä kaikille tähän projektiin osallistuville ja muutostietojen välittäminen perustuu Gitissä ja GitHubissa git-historiaan :) Jotkut osallistujat saattavat jo paikallisesti työstää jostakin historiasta poistetusta muutoksesta haaroitettua haaraa. Uskoisin tämän johtavan ongelmatilanteisiin.

Nyt pitäisi keskustella tavoitteista ja palastella tätä isoa kokonaisongelmaa pienempiin ja ratkoa niitä jotekin. Jos tälle tielle siis halutaan lähteä.

Challenge accepted!

[pe3]

Hmmm... auttaisikohan jos luotaisiin git checkout --orphan historiallinen muista haaroista erillinen historiallinen-haara, jota vaan joku yksi käyttäjä muokkaa. Muut kontribuuttorit työstäisivät muissa haaroissa yaml-front-matter:illisia lakitekstejä, joihin kirjattaisiin tiedot ajankohdista ym. Historiallista haaraa ainoana henkilönä muokkaava integraattori-käyttäjä ajaisi yaml:illisia lakitekstejä git-historiaan valmiiksi kirjoitetuilla skripteillä. Kukaan ei tekisi historiahaaraan pull-requesteja.

[ion1]

git-plumbing-create-commit – An example program that demonstrates how to create commits using Git plumbing

[pe3]

kiitti! kommitteja syntyy! mutta mun pitää lisäopiskella gittiä, ennenkuin tajuan kaiken mitä toi tekee.

[e-t-u]

Jos tarkoitus ei ole säästää itse editointityön historiaa, kyllähän git sallii versioiden hyvin vapaan muuntelun.

Yksi ratkaisu voisi olla se, että todellinen työ tehtäisiin yhdessä git:ssä, jossa luotaisiin rinnakkaiset hakemistot eri vuosien versioille. Eli tässä vaiheessa käytettäisiin jotain diff-työkalua versioiden vertailuun, ei gittiä. Sitten joka kerta rakennettaisiin tuo "julkaistava" git skriptillä noista hakemistoista.

En ole suuri guru git:in käytössä, pitäisi opiskella tämä git plumbing kunnolla: http://git-scm.com/book/en/Git-Internals-Git-Objects

Mutta olen kohtuullisen varma, että homman voi tehdä ja vielä aika siististikin.

[pe3]

Joo useamman repon malli ja vuosikansioiden diff-vertailu olis hyvä toimintamalli. Seuraavaksi voisi testailla, että GitHub varmasti toimii 1800-luvun päivämäärillä.

[jannepeltola]

Tuo e-t-u:n tapa kuulostaisi fiksulta. Laithan pääsääntöisesti nimetään /-formaatissa, mikä tukisi kansiorakennetta.

Yhdellä eduskunnan päätöksellä voidaan (ja muutetaankin) muuttaa useampaa lakia kerrallaan. Näen kaksi teknistä vaihtoehtoa kansion sisällölle:

1. tiedostoja, jotka kukin on nimetty lain mukaan. Kukin sisältäisi aina sillä hetkellä ajantasaisen tekstin.
2. tiedostoja, joiden YAML front matter sisältää edellä nimeen koodatun viitteen.

Tässä herääkin sitten pari kysymystä:

1. Onko kaikilla laeilla yksikäsitteinen tekninen nimi, joka on palautettavissa vuoteen 1917 (tai aiempaan)?
2. Missä formaatissa OM antaa lait?

Tuosta hallinnointiprosessista en olisi huolissani. Pistetään jonnekin ajoon Jenkins, joka vain buildaa aina konsensuksen siitä, mitä ihmiset heittävät tuonne diffirepoon.

[pe3]

Mun mielestä olis toivottavaa, että jokainen lakitekstin lisääjä viilaisi itse sen sellaiseen kuntoon, että vertailtavuus muihin tiedostoihin toimii. Homman käynnistämisvaiheessa hallinnointiprosessista kannattaa lähinnä huomioida, että osallisilla on välineet ja ohjeistus tämän tekemiseen.

Miten kun tulee uusi laki - lukeeko siellä lakitekstissä aivan eksplisiittisesti mitkä uudet pykälät korvaavat mitä vanhoja pykäliä? Ja yksilöivätkö siis lakien nimet ja pykälät lakitekstihistorian "osoiteavaruuden"? Onko tarvetta osoittaa yksittäistä pykälää pienempää kohdetta?

[haphut]

git commit -manuaali antaa ymmärtää, että git käyttää UNIX-aikaleimoja. Tällöin vuotta 1970 edeltävät tapahtumat eivät olisi gitin sisällä mallinnettavissa. Kokeilla voi silti vielä.