Git-freundliches Tabellenformat? [geschlossen]

Wir versuchen, unseren Projektdokumentationsprozess von Google Documents auf eine Reihe von selbst gehosteten Git-Repositorys zu verlagern.

Textdokumente sind Git-freundlich genug, da wir normalerweise keine ausgefallene Formatierung benötigen. Wir konvertieren einfach alles in beispielsweise Multimarkdown mit der Option, LaTeX für komplexe Fälle einzubetten.

Aber Tabellenkalkulationen sind eine ganz andere Geschichte ... Gibt es ein Tabellenkalkulationsformat, das für Versionskontrollsysteme geeignet ist (und das vorzugsweise so gut lesbar ist wie Markdown)?

"Freundliches Format": Git funktioniert gut mit dem Format (es funktioniert nicht mit XML) und es generiert für Menschen lesbare Diffs ( zusätzliche Konfiguration mit externen Tools ist in Ordnung).

Offensichtlich erlauben Markdown-Varianten das Erstellen statischer Tabellen, aber ich möchte gerne Dinge wie SUM()etc ... verwenden können. (Beachten Sie, dass CSV das gleiche Problem hat.) WYSIWYG ist in Ordnung, aber eine anständige Editor- / Tool-Unterstützung wäre in Ordnung nett.

Update: Bitte nur Linux-freundliche Antworten. Kein MS Office Zeug.

Sie können auch libreOffice / open-office-tabellenkalkulation-non-zip-xml-dateiformat "* .fods" verwenden, bei dem es sich um reines xml handelt. Der Kommentar von @glenatron gilt auch für dieses Format.

Das Standard-Open-Office-Tabellenkalkulationsformat "* .ods" ist XML-komprimiert und nicht für Git geeignet (ähnlich wie bei @ Egryan / @ emuddudley answer).

Dies passt möglicherweise nicht zu Ihren Anforderungen, aber möglicherweise zu denen eines anderen. Der Org-Modus für Emacs enthält table.el, zusammen mit den besonderen Verbesserungen des Org-Modus, eine äußerst robuste Lösung für Tabellenkalkulationen, die alle im Nur-Text-Format vorliegen. Weitere Informationen (weitaus mehr als der Umfang dieser Website) sind auf der Website und im Handbuch von Org-mode verfügbar , insbesondere in der Tabellenkalkulationsanleitung .

Was ist mit pyspread ? Es ist leistungsstark und kommt mit einer schönen GUI.

Laut der Seite Erste Schritte :

Das pys-Dateiformat hat sich in Version 0.2.0 geändert. Es ist jetzt eine bzip2-ed-Textdatei mit der folgenden Struktur:

[Pyspread-Dateiversion speichern]

0,1

[gestalten]

1000 100 3

[Gitter]

7 22 0 'Testcode1'

8 9 0 'Testcode2'

[Attribute]

[] [] [] [] [(0, 0)] 0 'textfont' u'URW Chancery L '

[] [] [] [] [(0, 0)] 0 'Punktgröße' 20

[row_heights]

0 0 56,0

7 0 25,0

[col_widths]

0 0 80,0

[Makros]

Makrotext

Die Tatsache, dass es sich um bzip2-ed handelt, hilft nicht, aber zumindest können Sie auf einen gut lesbaren Text zugreifen.

Lizenz ist GPLv3.

CSV (kommagetrennte Werte)

Wenn Sie nur mit Daten arbeiten, ist dies wahrscheinlich das einfachste und am häufigsten unterstützte Format.

Sollte das Leben leichter machen, wenn Sie zwischen den Versionen unterscheiden möchten.

Oh, und Google Docs unterstützt den CSV-Import / Export.

Aktualisieren:

Dann schreiben Sie einfach ein Google Apps-Skript, um die Formeln beim Export zu präzisieren und beim Import umgekehrt vorzugehen. Sie müssen etwas Einfallsreichtum verwenden, da das gesuchte Format nicht vorhanden ist.

Ich weiß, dass Microsoft Office 2007 und höher standardmäßig ein günstiges XML-Format verwenden, wenn sie speichern. Das sollte also für Git freundlich sein. Open Office speichert auch in einem XML-Format, wenn Sie eine Open Source-Lösung verwenden möchten. Da ein XML ein Textformat ist, sollte git in der Lage sein, es ziemlich gut zu verarbeiten

Da Sie es aus Google Documents verschieben, können Sie es herunterladen, wenn geöffnete Dokumente auf XML-Basis vorliegen.

Bearbeiten

Da Sie eine Nicht-Microsoft / XML-Lösung wünschen, die Sie jederzeit speichern können, gibt es eine CSV in Open Office, obwohl ich nicht sicher bin, wie viel Funktionalität Sie verlieren, wenn Sie in diesem Format speichern.

Dies ist möglicherweise nicht genau das, was Sie wollen. Ich glaube, mit libre office können Sie auf externe Dateien verweisen. Sie könnten eine Kalkulationstabelle haben, die Sie wie eine Datenbank behandeln, und eine statische libre-Datei, die Ihre Schnittstelle wäre. Sie würden den einfachen Zugriff auf Ihre versionierten Dateien verlieren, wenn Sie sie nicht zurückrufen, aber es würde funktionieren.

Ein weiteres ziemlich großes Problem dabei wäre, dass es eine Richtung ist.