Format arkusza kalkulacyjnego przyjazny dla Gita? [Zamknięte]

Staramy się przenieść proces dokumentacji projektu z Dokumentów Google do zestawu hostowanych przez siebie repozytoriów Git.

Dokumenty tekstowe są wystarczająco przyjazne dla Gita, ponieważ zwykle nie potrzebujemy żadnego fantazyjnego formatowania, po prostu przekonwertujemy wszystko na, powiedzmy, multimarkdown z opcją osadzenia LaTeXa w skomplikowanych przypadkach.

Ale arkusze kalkulacyjne to zupełnie inna historia ... Czy istnieje format (podobny do arkusza kalkulacyjnego), który jest przyjazny dla systemów kontroli wersji (a najlepiej jest tak czytelny dla ludzi jak Markdown)?

„Przyjazny format”: Git dobrze współpracuje z formatem (nie obsługuje XML) i generuje różnice czytelne dla człowieka ( dodatkowa konfiguracja z użyciem zewnętrznych narzędzi jest OK).

Oczywiście, smaki Markdown pozwalają budować statyczne tabele, ale chciałbym móc używać rzeczy takich jak SUM()itp ... (Uwaga: CSV ma ten sam problem.) Żadne WYSIWYG nie jest OK, ale przyzwoita obsługa edytora / narzędzi byłaby miły.

Aktualizacja: Proszę tylko o odpowiedzi przyjazne dla systemu Linux. Brak materiałów MS Office.

Możesz także użyć libreOffice / open-office-spreadsheet-non-zip-xml-fileformat „* .fods”, który jest zwykłym plikiem xml. Komentarz @glenatron dotyczy również tego formatu.

Standardowy format otwartego pakietu kalkulacyjnego „* .ods” jest skompresowany xml i nie jest tak odpowiedni dla git (podobny do odpowiedzi @ Egryan / @ emuddudley).

To może nie pasować do twoich potrzeb, ale może pasować do innych. Zawiera tryb Org dla Emacsa table.el, który wraz ze szczególnymi ulepszeniami trybu Org zapewnia niezwykle niezawodne rozwiązanie dla arkuszy kalkulacyjnych, wszystkie w postaci zwykłego tekstu. Więcej informacji (znacznie więcej niż zakres tej strony) jest dostępnych na stronie internetowej i podręczniku trybu organizacji , w szczególności samouczku arkusza kalkulacyjnego .

Co z pyspread ? Jest potężny i ma ładne GUI.

Według strony Pierwsze kroki :

Format pliku pys zmienił się w wersji 0.2.0. Jest to teraz plik tekstowy w formacie bzip2 o następującej strukturze:

[Wersja pliku zapisu Pyspread]

0,1

[kształt]

1000 100 3

[krata]

7 22 0 „Kod testowy 1”

8 9 0 „Testcode2”

[atrybuty]

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

[] [] [] [] [(0, 0)] 0 'pointize' 20

[row_heights]

0 0 56,0

7 0 25,0

[col_widths]

0 0 80,0

[makra]

Tekst makra

Fakt, że jest to bzip2-ed, nie pomaga, ale przynajmniej możesz uzyskać dostęp do dość czytelnego tekstu.

Licencja to GPLv3.

CSV (wartości oddzielone przecinkami)

Jeśli pracujesz tylko z danymi, jest to prawdopodobnie najprostszy i najczęściej obsługiwany format.

Powinno to ułatwić życie, jeśli chcesz różnicować wersje.

Aha, a Dokumenty Google w pełni obsługują import / eksport CSV.

Aktualizacja:

Następnie po prostu napisz skrypt Google Apps, aby skreślić formuły przy eksporcie i zrobić odwrotnie przy imporcie. Musisz użyć pomysłowości, ponieważ format, którego szukasz, nie istnieje.

Wiem, że Microsoft Office 2007 i nowsze wersje domyślnie przyjmują format XML z propitiatory podczas zapisywania. To powinno być przyjazne dla Gita. Open Office zapisuje również do formatu xml, jeśli chcesz użyć bardziej otwartego oprogramowania. Ponieważ XML jest formatem tekstowym, git powinien być w stanie obsługiwać go dość dobrze

Ponieważ przenosisz go z Dokumentów Google, możesz je pobrać, ma otwarte dokumenty oparte na XML.

Edytować

Ponieważ zależy Ci na rozwiązaniu innym niż Microsoft / XML, które zawsze możesz zapisać, masz CSV w otwartym biurze, ale nie jestem pewien, ile utracisz funkcjonalności, zapisując w tym formacie.

To może nie być dokładnie to, co chcesz. Uważam, że libre office pozwala odwoływać się do pliku zewnętrznego. Możesz mieć arkusz kalkulacyjny, który traktujesz jak bazę danych i mieć statyczny plik libre, który byłby twoim interfejsem. Utraciłbyś łatwy dostęp do sumowania w wersjonowanych plikach, chyba że oddzwonisz, ale to zadziała.

Innym dość dużym problemem jest to, że jest to jeden kierunek.