Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #129251 > unrolled thread

Re: git

Back to article view | Back to de.comp.os.unix.linux.misc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: git Martin Vaeth <martin@mvath.de> - 2023-03-12 15:15 +0000
    Re: git Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-03-12 15:56 +0000
      Re: git Thomas Hochstein <thh@thh.name> - 2023-03-12 18:07 +0100
        Re: git Martin Vaeth <martin@mvath.de> - 2023-03-13 01:41 +0000
          Re: git Arno Welzel <usenet@arnowelzel.de> - 2023-03-17 17:01 +0100
          Re: git Thomas Hochstein <thh@thh.name> - 2023-03-18 20:24 +0100
            Re: git Martin Vaeth <martin@mvath.de> - 2023-03-21 16:09 +0000
              Re: git Thomas Dorner <dcoulm230321.dorner@spamgourmet.com> - 2023-03-21 19:09 +0100
                Re: git Martin Vaeth <martin@mvath.de> - 2023-03-22 17:45 +0000
                  Re: git Christian Garbs <mitch@cgarbs.de> - 2023-03-22 18:50 +0000
                    Re: git Martin Vaeth <martin@mvath.de> - 2023-03-25 04:38 +0000
                      Re: git Christian Garbs <mitch@cgarbs.de> - 2023-04-05 13:08 +0000
                        Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-04-05 19:40 +0200
                        Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-04-06 09:41 +0200
                          Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-04-07 08:47 +0200
                            Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-04-10 09:02 +0200
                              Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-04-10 09:46 +0200
                                Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-04-10 11:35 +0200
                                  Re: git Tim Landscheidt <tim@tim-landscheidt.de> - 2023-04-14 13:56 +0000
                      Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-04-06 09:35 +0200
                        Re: git Christian Garbs <mitch@cgarbs.de> - 2023-04-06 20:34 +0000
                  Re: git Thomas Dorner <dcoulm230323.dorner@spamgourmet.com> - 2023-03-23 18:56 +0100
                    Re: git Martin Vaeth <martin@mvath.de> - 2023-03-25 05:09 +0000
                      Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-25 10:02 +0100
                        Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-25 11:22 +0100
                          Re: git Martin Vaeth <martin@mvath.de> - 2023-03-26 16:22 +0000
                            Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-27 18:10 +0200
                        Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-25 12:39 +0100
                          Re: git Tim Landscheidt <tim@tim-landscheidt.de> - 2023-03-25 23:59 +0000
                            Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-26 09:04 +0200
                            Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-26 12:59 +0200
                              Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-26 13:18 +0200
                          Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-26 10:41 +0200
                          Re: git Christian Garbs <mitch@cgarbs.de> - 2023-04-05 12:42 +0000
                            Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-04-14 22:17 +0200
                              Re: git Christian Garbs <mitch@cgarbs.de> - 2023-04-15 07:50 +0000
                                Re: git Christian Garbs <mitch@cgarbs.de> - 2023-04-18 07:28 +0000
                                  Re: git Enrik Berkhan <Enrik.Berkhan@inka.de> - 2023-04-18 18:06 +0000
                                    Re: git Christian Garbs <mitch@cgarbs.de> - 2023-04-22 18:06 +0000
                                    Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-17 22:26 +0200
                                      Re: git Christian Garbs <mitch@cgarbs.de> - 2023-07-25 19:45 +0000
                                        Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-08-06 13:45 +0200
                                  Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-17 21:26 +0200
                              Re: git Enrik Berkhan <Enrik.Berkhan@inka.de> - 2023-04-15 12:15 +0000
                        Re: git Martin Vaeth <martin@mvath.de> - 2023-03-26 17:39 +0000
              Re: git Christian Garbs <mitch@cgarbs.de> - 2023-03-21 21:02 +0000
              Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-22 00:56 +0100
                Re: git Martin Vaeth <martin@mvath.de> - 2023-03-22 17:14 +0000
      Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-12 18:51 +0100
        Re: git Martin Vaeth <martin@mvath.de> - 2023-03-13 01:46 +0000
          Re: git Arno Welzel <usenet@arnowelzel.de> - 2023-03-17 17:02 +0100
            Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-18 11:23 +0100
              Re: git Laurenz Trossel <me@example.invalid> - 2023-03-18 12:18 +0000
              Re: git Arno Welzel <usenet@arnowelzel.de> - 2023-03-19 17:15 +0100
            Re: git Martin Vaeth <martin@mvath.de> - 2023-03-21 14:57 +0000

Page 1 of 3  [1] 2 3  Next page →

#129251 — Re: git

Stefan Ram <ram@zedat.fu-berlin.de> schrieb:
>
>   Ich möchte "git" einsetzen, aber die üblichen Einführungen in
>   git sind für mich unübersichtlich. Ich möchte das Repository
>   von git praktisch wie eine Sicherungskopie meiner Textdateien
>   verwenden, wobei git speicherplatzschonend vorgehen soll.

Wie andere schon geschrieben haben, ist git dafür das falsche
Tool, vor allem auch, weil es keinen Zeitstempel pro Datei kennt.

Git ist für Source-Verzeichnisse konzipiert, in denen es
wichtig ist, dass die Versionen der Dateien zueinander passen.
Wenn Du i.W. nur einzelne Dateien sichern und deren früheren
Status wiederherstellen willst - unabhängig von den anderen
Dateien - ist das klassische Unix-Tool "rcs" besser geeignet.

(Es "geht" zwar mit git, wenn Du mit einem Skriptverhau auch
die Zeitstempel in eine Datei schreibst und mitsicherst, ist
aber alles unnötig kompliziert.)

[toc] | [next] | [standalone]

#129254

Martin Vaeth <martin@mvath.de> wrote:

> Wie andere schon geschrieben haben, ist git dafür das falsche
> Tool, vor allem auch, weil es keinen Zeitstempel pro Datei kennt.

Aehh.. git sichert KEIN modification time?!
Das ist aber... MIST.


> Wenn Du i.W. nur einzelne Dateien sichern und deren früheren
> Status wiederherstellen willst - unabhängig von den anderen
> Dateien - ist das klassische Unix-Tool "rcs" besser geeignet.

Das muss man halt auch manuell aufrufen.

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    https://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#129260

Ulli Horlacher schrieb:

> Martin Vaeth <martin@mvath.de> wrote:
> 
>> Wie andere schon geschrieben haben, ist git dafür das falsche
>> Tool, vor allem auch, weil es keinen Zeitstempel pro Datei kennt.
> 
> Aehh.. git sichert KEIN modification time?!

Nein. Wozu auch?

> Das ist aber... MIST.

Weshalb? - In einer Versionsverwaltung lässt sich trivial feststellen,
wann eine Datei das letzte Mal (inhaltlich) geändert wurde. Das ist viel
relevanter, als wann sie das letzte Mal auf den Datenträger geschrieben
wurde.

-thh

[toc] | [prev] | [next] | [standalone]

#129270

Thomas Hochstein <thh@thh.name> schrieb:
> Ulli Horlacher schrieb:
>
>> Martin Vaeth <martin@mvath.de> wrote:
>>
>>> Wie andere schon geschrieben haben, ist git dafür das falsche
>>> Tool, vor allem auch, weil es keinen Zeitstempel pro Datei kennt.
>>
>> Aehh.. git sichert KEIN modification time?!
>
> Nein. Wozu auch?

Zur Dokumentation

>> Das ist aber... MIST.

Ja. Riesiger Mist.

> Weshalb? - In einer Versionsverwaltung lässt sich trivial feststellen,
> wann eine Datei das letzte Mal (inhaltlich) geändert wurde.

Nein. Es lässt sich nur feststellen, wann der letzte commit erfolgte,
in deren Verlauf die Datei *irgendwann* geändert wurde. Wenn Du
unabhängige Textdokumente hast, die über Jahre entstanden sind,
hast Du schon beim ersten Checkin alle Zeitinformationen verloren.

Und selbst dieser Zeitstempel wird per Default beim Wiederherstellen
einer Datei nicht gesetzt.

Das alles ist sinnvoll für den einzigen Anwendungsfall, für die git
gedacht ist - source-code - aber für so ziemlich alle anderen
Anwedungsfälle ist es genau nicht das, was man will.

[toc] | [prev] | [next] | [standalone]

#129433

Martin Vaeth, 2023-03-13 02:41:

> Thomas Hochstein <thh@thh.name> schrieb:
>> Ulli Horlacher schrieb:
>>
>>> Martin Vaeth <martin@mvath.de> wrote:
>>>
>>>> Wie andere schon geschrieben haben, ist git dafür das falsche
>>>> Tool, vor allem auch, weil es keinen Zeitstempel pro Datei kennt.
>>>
>>> Aehh.. git sichert KEIN modification time?!
>>
>> Nein. Wozu auch?
> 
> Zur Dokumentation

Die gibt es ja im Log.

>>> Das ist aber... MIST.
> 
> Ja. Riesiger Mist.

Nö. Welchen Timestamp man im Dateisystem hat, ist komplett irrelevant.

>> Weshalb? - In einer Versionsverwaltung lässt sich trivial feststellen,
>> wann eine Datei das letzte Mal (inhaltlich) geändert wurde.
> 
> Nein. Es lässt sich nur feststellen, wann der letzte commit erfolgte,
> in deren Verlauf die Datei *irgendwann* geändert wurde. Wenn Du
> unabhängige Textdokumente hast, die über Jahre entstanden sind,
> hast Du schon beim ersten Checkin alle Zeitinformationen verloren.

Was genau gewinnt man in Information, wenn man weiß, wann genau die
Änderung in der Datei vorgenommen wurde? Also wann genau ist das
notwendig zusätzlich zur Angabe, welche Änderungen genau erfolgt sind
und wann diese in das Repository übernommen wurden?

> Und selbst dieser Zeitstempel wird per Default beim Wiederherstellen
> einer Datei nicht gesetzt.

Ja, weil er schlicht nicht nötig ist.

> Das alles ist sinnvoll für den einzigen Anwendungsfall, für die git
> gedacht ist - source-code - aber für so ziemlich alle anderen
> Anwedungsfälle ist es genau nicht das, was man will.

Ich habe noch nie das Änderungsdatum einer Datei gebraucht, auch nicht
außerhalb von Source-Code. Darauf baut hier exakt gar nichts auf. Weder
Datensicherungen noch die Verwaltung von Inhalten. Wenn Datumsangaben
wichtig sind, müssen sie entweder Teil des Dateinamens sein oder separat
vorliegen. Allein auf Angaben in einem Dateisystem will ich mich sicher
nicht verlassen.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#129483

Martin Vaeth schrieb:

> Thomas Hochstein <thh@thh.name> schrieb:
>> Ulli Horlacher schrieb:
>>> Aehh.. git sichert KEIN modification time?!
>> Nein. Wozu auch?
> 
> Zur Dokumentation

Von was? Änderungen werden in den Metadaten dokumentiert, dafür hat man ja
eine Versionsverwaltung.
 
>>> Das ist aber... MIST.
> 
> Ja. Riesiger Mist.

Ich habe das nie vermisst. (Im Übrigen bleiben die Dateien im working tree
ja zunächst unverändert; da hast Du dann regelmäßig Dein passendes
Dateidatum.)

>> Weshalb? - In einer Versionsverwaltung lässt sich trivial feststellen,
>> wann eine Datei das letzte Mal (inhaltlich) geändert wurde.
> 
> Nein. Es lässt sich nur feststellen, wann der letzte commit erfolgte,
> in deren Verlauf die Datei *irgendwann* geändert wurde.

Dunkel bleibt Deiner Rede Sinn. Wenn die Datei geändert wurde, dann werden
die Änderungen zeitnah committet. Ob das nun mal zwei Stunden später
geschieht, ist von keiner mir erkennbaren Relevanz.

> Wenn Du
> unabhängige Textdokumente hast, die über Jahre entstanden sind,
> hast Du schon beim ersten Checkin alle Zeitinformationen verloren.

Nicht im working tree, aber ja - wenn Du bestehende Dateien in ein
Versionsverwaltungssystem "importierst", dann ist die
Bearbeitungsgeschichte zuvor nicht enthalten. Das ist keine große
Besonderheit und passiert auch dann, wenn die Datei per Mail oder Download
(Austausch über Nextcloud o.ä.) transferiert wird.

Wenn Dir das Datum furchtbar wichtig ist, fügst Du die Textdokumente
notfalls einzeln ein und setzt beim Commit mittels --date das Datum.

(Und die mtime ist nun wirklich von "alle Zeitinformationen" weit
entfernt, ist damit doch nur der letzte Schreibvorgang auf Datenträger
festgehalten - weder alle Änderungen noch ob damit überhaupt eine Ändeurng
verbunden war.)

> Und selbst dieser Zeitstempel wird per Default beim Wiederherstellen
> einer Datei nicht gesetzt.

Wozu auch? Die Datei wurde ja auch zuletzt beim "Wiederherstellen"
geschrieben.

> Das alles ist sinnvoll für den einzigen Anwendungsfall, für die git
> gedacht ist - source-code - aber für so ziemlich alle anderen
> Anwedungsfälle ist es genau nicht das, was man will.

Ich verwalte mit git primär Webseiten (das ist von "Sourcecode"
einigermaßen entfernt) und Textdateien. Das funktioniert ganz ausnehmend
gut - und auf meinem Hauptrechner stimmt im working tree regelmäßig auch
die mtime, nicht dass ich das für besonders relevant halten würde.

-thh

[toc] | [prev] | [next] | [standalone]

#129571

Thomas Hochstein <thh@thh.name> wrote:
> Martin Vaeth schrieb:
>
>> Thomas Hochstein <thh@thh.name> schrieb:
>>> Ulli Horlacher schrieb:
>>>> Aehh.. git sichert KEIN modification time?!
>>> Nein. Wozu auch?
>>
>> Zur Dokumentation
>
> Von was?

Vom Entstehungsdatum bzw. Änderungsdatum.

>Änderungen werden in den Metadaten dokumentiert

Eben nur die Änderungen. Wenn Du ein Verzeichnis mit
Dateien 1985-jetzt hast und das in Git eincheckst, hast
Du alle Deine Zeitinformationen auf einen Schlag
verloren.

>> Ja. Riesiger Mist.
>
> Ich habe das nie vermisst.

Das ist kein Argument, dass das für andere Leute unwichtig
sein soll.

> (Im Übrigen bleiben die Dateien im working tree
> ja zunächst unverändert

Betonung: Zunächst. Solange, bis Du git *benutzt*.
Danach sind die Informationen flöten.

>> Nein. Es lässt sich nur feststellen, wann der letzte commit erfolgte,
>> in deren Verlauf die Datei *irgendwann* geändert wurde.
>
> Dunkel bleibt Deiner Rede Sinn. Wenn die Datei geändert wurde, dann werden
> die Änderungen zeitnah committet.

Ja, nimm eine Datei von 1985, check sie ein, ändere sie und committe sie,
von mir aus zeitnah nach der Änderung. Wo siehst Du in git das Datum 1985
(wenn Du nicht manuell oder per Skript herumfrickelst; ersteres scheidet
bei einem größeren Verzeichnis aus).

> Nicht im working tree, aber ja - wenn Du bestehende Dateien in ein
> Versionsverwaltungssystem "importierst", dann ist die
> Bearbeitungsgeschichte zuvor nicht enthalten.

Dass die Bearbeitungsgeschichte weg ist, lässt sich nicht ändern.
Dass der lezte Zeitstempel verloren geht, liegt nur an git.

> und passiert auch dann, wenn die Datei per Mail oder Download
> (Austausch über Nextcloud o.ä.) transferiert wird.

Was ist das für ein Argument? Es gibt Mittel, nicht nur Zeitstempel
sondern auch Inhalt zu verlieren (rm etwa), also spricht das für
git!?

> Wenn Dir das Datum furchtbar wichtig ist, fügst Du die Textdokumente
> notfalls einzeln ein und setzt beim Commit mittels --date das Datum.

Wie gesagt: Mit einem riesigen Scriptverhau *kann* man auch git
dazu benutzen. Aber man muss dann *gegen* git arbeiten (zu Beginn
mit einem langen Script in der richtigen Reihenfolge einchecken,
über das Datum lügen, beim Auschecken das letzte Änderungsdatum
wiederherstellen usw., damit es *halbwegs* das tut, was man will.
Oder alternativ eine "Zeitstempeldatei" ändern, mitsichern und
anwenden usw. Beides habe ich je einmal versucht: Was'n Ranz!)
M.E. benutzt man besser eine Anwendung, die sich ohne Frickelei
vernünftig verhält, vor allem, wenn ein anderes Haupt-"Feature"
von git - dass die ganzen inhaltlich unabhängigen Dateien konsistent
zueinander gahalten werden - ebenfalls etwas ist, bei dem man
für Textdateien *gegen* git arbeitet.

> (Und die mtime ist nun wirklich von "alle Zeitinformationen" weit
> entfernt

In einem Verzeichnis mit ein paar Hundert Dateien sind das
sehr viele Zeitinformationen, und zwar alle, die man hat.

, ist damit doch nur der letzte Schreibvorgang auf Datenträger
> festgehalten - weder alle Änderungen noch ob damit überhaupt eine Ändeurng
> verbunden war.)

Menschen, die ich kenne, sichern genau aus diese Grund bei
Textdateien den Zeitstempel und werden kein sinnloses "touch"
durchführen. (Und falls das doch durch einen Fehler passert, wird der
Zeitstempel aus dem Backup wiederhergestellt). Bei einem
Versionierungsystem für Textdateien erwarten diese Menschen naturgemäß
Ähnliches. git liefert das nicht, wenn man nicht *gegen* git arbeitet.

>> Und selbst dieser Zeitstempel wird per Default beim Wiederherstellen
>> einer Datei nicht gesetzt.
>
> Wozu auch? Die Datei wurde ja auch zuletzt beim "Wiederherstellen"
> geschrieben.

Man sieht, dass Du anscheinend noch nie eine umfangreiche
Sammlung von Textdokumenten gepflegt hast. Wie gesagt wäre ein
Datum, das nicht der letzten Änderung entspricht, bei solchen
Dokumenten normalerwise ein Fall für Restauration vom Backup.
Bei Source-Code gelten andere Regeln - da ist der Zeitstempel
ja bestenfalls nur für make interessant - und git ist eben
*ausschließlich* darauf fixiert.

> Ich verwalte mit git primär Webseiten (das ist von "Sourcecode"
> einigermaßen entfernt)

html würde ich duchaus als Source-code bezeichnen, vor allem
weil der Bezug der Seiten zueinander hier wesentlich ist.

> und auf meinem Hauptrechner stimmt im working tree regelmäßig auch
> die mtime, nicht dass ich das für besonders relevant halten würde.

Ich würde schon gerne sehen, ob eine Seite jetzt historisch von
1985 ist, oder gerade letzte Woche aktualisiert wurde. Mag sein,
dass das bei Dir in den Dateien steht, aber dann bist Du auf
einen speziellen Editor oder andere Software dafür angewiesen.
Aber egal: Wenn git für Dich tut, was Du willst: Fein. Für mich
tut es das nicht, und für andere offensichtlich auch nicht.

[toc] | [prev] | [next] | [standalone]

#129581

Martin Vaeth <martin@mvath.de> writes:

> Eben nur die Änderungen. Wenn Du ein Verzeichnis mit
> Dateien 1985-jetzt hast und das in Git eincheckst, hast
> Du alle Deine Zeitinformationen auf einen Schlag
> verloren.

Dann mache halt einzelne commits mit --date.

Aber Du suchst ja anscheinend keine Versionsverwaltung, sondern ein
Backup-Werkzeug.

Viele Grüße, Thomas
-- 
Adresse gilt nur kurzzeitig!

[toc] | [prev] | [next] | [standalone]

#129593

Thomas Dorner <dcoulm230321.dorner@spamgourmet.com> wrote:
> Martin Vaeth <martin@mvath.de> writes:
>
>> Eben nur die Änderungen. Wenn Du ein Verzeichnis mit
>> Dateien 1985-jetzt hast und das in Git eincheckst, hast
>> Du alle Deine Zeitinformationen auf einen Schlag
>> verloren.
>
> Dann mache halt einzelne commits mit --date.

Für jede einzelne Datei manuell - nein danke. Dass es mit einem
Skriptverhau möglich ist, wenn man *gegen* git arbeiten will, habe
ich ja schon geschrieben. Spass hat man dabei aber nicht, weil man
letztlich ein inadäquates Tool für das Problem benutzt.

> Aber Du suchst ja anscheinend keine Versionsverwaltung, sondern ein
> Backup-Werkzeug.

Ich suche gar nichts, denn ich bin nicht der OP.
Aber ich habe gute Erfahrungen mit Versionsververwaltungen für
Textdokumente gemacht, die nicht ausschließlich auf Sourcecode
hochspezialisiert ist, wie z.B. rcs.
Wohlgemerkt: Für Sourcecode ist git gut geeignet, und da benutze ich
es auch gerne. Nur hat man leider eben "ohne Not" den
Nicht-Sourcecode-Fall sehr schwierig gemacht: Es wäre kein
großes Ding, den Zeitstempel mit einer geeigneten Option
mitzusichern bzw. wiederherzustellen und das Datei-orientierte
Arbeiten etwas übersichtlicher zu machen.
Übrigens ist im Prinzip jede Versionsverwaltung i.W. ein
inkrementeles Backup, nur mit einem Front-End für Dokumentation
und häufig benutzte Operationen.

[toc] | [prev] | [next] | [standalone]

#129596

Mahlzeit!

Martin Vaeth <martin@mvath.de> wrote:

> Wohlgemerkt: Für Sourcecode ist git gut geeignet, und da benutze ich
> es auch gerne. Nur hat man leider eben "ohne Not" den
> Nicht-Sourcecode-Fall sehr schwierig gemacht: Es wäre kein
> großes Ding, den Zeitstempel mit einer geeigneten Option
> mitzusichern bzw. wiederherzustellen und das Datei-orientierte
> Arbeiten etwas übersichtlicher zu machen.

Ich wette mit Dir, dass das eben nicht "kein großes Ding" ist, schon
hunderte Male auf der git-ML diskutiert worden ist und es handfeste
Gründe (z.B. irgendwelche git-Innereien, die dazu inkompatibel sind)
gibt, die dagegen sprechen.

Was mir jetzt spontan einfällt:


1. Wie sieht Dein Merge-Workflow aus, wenn zwei Dateien inhaltlich
gleich sind, aber einen unterschiedlichen Zeitstempel haben?

Wenn Du die Zeitstempel in einer getrennten Datei führst, ist das
trivial mit den Standard-Mitteln zu bearbeiten, dann steht in der
Zeitstempeldatei etwas in der Art:

<<<HEAD
foo.txt $gestern
===
foo.txt $heute
>>>MERGE

Wie machst Du das, wenn die Zeitstempel im Dateisystem liegen?



2. (ältere?) unter Windows genutzte Dateisysteme haben eine Auflösung
von 2 Sekunden oder so.  Das macht unter make schon regelmäßig
Probleme.  Da kannst Du die ausgecheckten Dateien gar nicht auf den
Zeitstempel setzen, den die Datei haben müsste.



Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
New processes are created by other processes, just like new humans.
New humans are created by other humans, of course, not by processes.
                               (Unix System Administration Handbook)

[toc] | [prev] | [next] | [standalone]

#129688

Christian Garbs <mitch@cgarbs.de> wrote:
> Mahlzeit!
>
> Martin Vaeth <martin@mvath.de> wrote:
>
>> Wohlgemerkt: Für Sourcecode ist git gut geeignet, und da benutze ich
>> es auch gerne. Nur hat man leider eben "ohne Not" den
>> Nicht-Sourcecode-Fall sehr schwierig gemacht: Es wäre kein
>> großes Ding, den Zeitstempel mit einer geeigneten Option
>> mitzusichern bzw. wiederherzustellen und das Datei-orientierte
>> Arbeiten etwas übersichtlicher zu machen.
>
> Ich wette mit Dir, dass das eben nicht "kein großes Ding" ist, schon
> hunderte Male auf der git-ML diskutiert worden ist und es handfeste
> Gründe (z.B. irgendwelche git-Innereien, die dazu inkompatibel sind)
> gibt, die dagegen sprechen.

Mag sein, dass git intern mittlerweile so vermurkst ist, dass
einfache Erweiterungen schwer einzubauen sind - da habe ich keinen
Einblick. Der Grund scheint mir aber eher zu sein, dass es eben
kein Feature ist, das für *Softwareentwicklung* nützlich ist,
und es deshalb eben "aus Prinzip" nicht unterstützt werden soll,
weil git dafür nicht gedacht ist.

> 1. Wie sieht Dein Merge-Workflow aus, wenn zwei Dateien inhaltlich
> gleich sind, aber einen unterschiedlichen Zeitstempel haben?

Viele Möglichkeiten. Eine wäre, das Verhalten bei Änderungen von
anderen Metadaten (z.B. dem X-Bit, es gibt vermutlich noch mehr)
zu imitieren. Eine andere, natürlichere Art (die man bei dem X-Bit
nicht hat), wäre die automatische Konfliktlösung zum älteren/neueren
Stempel bei identischen/unterschiedlichen Dateien.

> Wenn Du die Zeitstempel in einer getrennten Datei führst, ist das
> trivial mit den Standard-Mitteln zu bearbeiten

Das macht man bei anderen Metadaten wie dem X-Bit auch nicht.
Konsequenz in der Logik ist in solchen Fällen halt unpraktisch
für den Benutzer.

> 2. (ältere?) unter Windows genutzte Dateisysteme haben eine Auflösung
> von 2 Sekunden oder so.  Das macht unter make schon regelmäßig
> Probleme.  Da kannst Du die ausgecheckten Dateien gar nicht auf den
> Zeitstempel setzen, den die Datei haben müsste.

Diese älteren Dateisysteme haben auch kein X-Bit. Und?
Wer git mit einem beschränkten Dateisystem benutzt, muss halt mit
dessen Einschränkungen rechnen. Das überrascht doch niemanden.

[toc] | [prev] | [next] | [standalone]

#129793

Mahlzeit!

Sorry für die späte Antwort.

Martin Vaeth <martin@mvath.de> wrote:
> Christian Garbs <mitch@cgarbs.de> wrote:
>> Mahlzeit!
>>
>> Martin Vaeth <martin@mvath.de> wrote:
>>
>>> Wohlgemerkt: Für Sourcecode ist git gut geeignet, und da benutze ich
>>> es auch gerne. Nur hat man leider eben "ohne Not" den
>>> Nicht-Sourcecode-Fall sehr schwierig gemacht: Es wäre kein
>>> großes Ding, den Zeitstempel mit einer geeigneten Option
>>> mitzusichern bzw. wiederherzustellen und das Datei-orientierte
>>> Arbeiten etwas übersichtlicher zu machen.
>>
>> Ich wette mit Dir, dass das eben nicht "kein großes Ding" ist, schon
>> hunderte Male auf der git-ML diskutiert worden ist und es handfeste
>> Gründe (z.B. irgendwelche git-Innereien, die dazu inkompatibel sind)
>> gibt, die dagegen sprechen.
 
> Mag sein, dass git intern mittlerweile so vermurkst ist, dass
> einfache Erweiterungen schwer einzubauen sind - da habe ich keinen
> Einblick.

Du schreibst, dass Du keinen Einblick in den Sourcecode hast, legst
aber im gleichen Satz als Tatsache fest, dass das eine einfache
Erweiterung sei.

Das kommt ziemlich anmaßend rüber – wenn Du in der Art mit einem
Request bei einem meiner Projekte anfragen würdest, wäre meine
Motivation, mir das mal anzugucken, direkt weg.

Ich bin bestimmt kein Kuschelsprache-Verfechter, aber an der Stelle
wäre ein "meiner Meinung nach einfache Erweiterung" oder eine ähnliche
Einschränkung angebracht.

(Ich bin Programmierer – ich hab mir angewöhnt, keine absoluten
Aussagen zu machen, wo sie nicht hingehören, wie z.B. "das wird so
funktionieren" oder "dieses Programm hat keinen Fehler".)

> Der Grund scheint mir aber eher zu sein, dass es eben kein Feature
> ist, das für *Softwareentwicklung* nützlich ist, und es deshalb eben
> "aus Prinzip" nicht unterstützt werden soll, weil git dafür nicht
> gedacht ist.

Wie gesagt, tippe ich da auf den Grund "ist nicht so einfach, wenn man
in die Details geht".

Wer fragt jetzt auf der git-Mailingliste?

Oder besser: Wer durchforstet da mal das Mailarchiv?
Wir sind bestimmt nicht die ersten, die darüber mal nachdenken.


Die alte git-FAQ sagt grob "ist Absicht, weil Buildsysteme":
https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/Git_FAQ.html#Why_isn.27t_Git_preserving_modification_time_on_files.3F

Damit können wir dann eigentlich aufhören, darüber zu diskutieren :)


Mini-Lösung für das Mitführen der Timestamps:
https://gist.github.com/andris9/1978266
Das lässt sich bestimmt irgendwie automatisieren über .git/hooks


>> 1. Wie sieht Dein Merge-Workflow aus, wenn zwei Dateien inhaltlich
>> gleich sind, aber einen unterschiedlichen Zeitstempel haben?
> 
> Viele Möglichkeiten. Eine wäre, das Verhalten bei Änderungen von
> anderen Metadaten (z.B. dem X-Bit, es gibt vermutlich noch mehr)
> zu imitieren.

Da wirfst Du einen guten Punkt auf: Wie merged man eigentlich X-Bits?
Das ist mir tatsächlich noch nie passiert und ich wüsste auch nicht,
wie der Merge-Workflow das darstellen kann.

Allerdings könnte das sogar unnötig sein, denn…

>> Wenn Du die Zeitstempel in einer getrennten Datei führst, ist das
>> trivial mit den Standard-Mitteln zu bearbeiten
> 
> Das macht man bei anderen Metadaten wie dem X-Bit auch nicht.

…meiner Meinung kann beim X-Bit gar keine Merge-Konflikte geben, weil
das Bit ja nur 2 Zustände hat:

- beide Seiten haben keine Änderung -> Bit bleibt wie vorher

- nur eine Seite hat eine Änderung -> die Änderung wird übernommen

- beide Seiten haben eine Änderung -> die Änderung wird übernommen,
  da sie ja auf beiden Seiten _exakt die gleiche_ Änderung sein muss

Mit dem Zeitstempel hast Du mehr Möglichkeiten, da kann die eine Seite
den Zeitstempel auf "Montag" geändert haben und die andere auf
"Dienstag", da musst Du irgendwie nachfragen.


> Konsequenz in der Logik ist in solchen Fällen halt unpraktisch
> für den Benutzer.

Das dürfte auch ein grundsätzliches Problem geben :)

Git ist von Entwicklern für Entwickler geschrieben, da steht
"Konsequenz in der Logik" hoffentlich weit oben auf der Feature-Liste.


>> 2. (ältere?) unter Windows genutzte Dateisysteme haben eine Auflösung
>> von 2 Sekunden oder so.  Das macht unter make schon regelmäßig
>> Probleme.  Da kannst Du die ausgecheckten Dateien gar nicht auf den
>> Zeitstempel setzen, den die Datei haben müsste.
> 
> Diese älteren Dateisysteme haben auch kein X-Bit. Und?

Auch ein guter Punkt, auch hier bin ich überfragt – wenn ich git unter
Windows benutze, dann auf NTFS(?) unter Cygwin, da wird das x-Bit
irgendwie nachgebaut.  Ob und wie sich das unter FAT32 und/oder
außerhalb von Cygwin verhalten würde: Keine Ahnung, wäre mal
interessant.

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
X-no-sig: yes

[toc] | [prev] | [next] | [standalone]

#129795

Am 05.04.2023 um 15:08 schrieb Christian Garbs:
> Martin Vaeth <martin@mvath.de> wrote:
>>> 2. (ältere?) unter Windows genutzte Dateisysteme haben eine Auflösung
>>> von 2 Sekunden oder so.  Das macht unter make schon regelmäßig
>>> Probleme.  Da kannst Du die ausgecheckten Dateien gar nicht auf den
>>> Zeitstempel setzen, den die Datei haben müsste.
>>
>> Diese älteren Dateisysteme haben auch kein X-Bit. Und?
> 
> Auch ein guter Punkt, auch hier bin ich überfragt – wenn ich git unter
> Windows benutze, dann auf NTFS(?) unter Cygwin, da wird das x-Bit
> irgendwie nachgebaut.  Ob und wie sich das unter FAT32 und/oder
> außerhalb von Cygwin verhalten würde: Keine Ahnung, wäre mal
> interessant.

Ich hab das gelegentlich noch. (git-Checkout auf einem VirtualBox Shared
Folder.)

Kurz gesagt: das x-Bit wird im Wesentlichen unbenutzbar. git zeigt immer
alle Dateien als verändert an. Das würde dann wohl mit einer mtime als
versioniertes Attribut genauso.

Man kann durchaus die Frage stellen, warum nun ausgerechnet das x-Bit
mit archiviert wird (die anderen Dateiattribute werden nicht archiviert,
obwohl im Datenformat dafür Platz wäre). Das wird dann wohl daher
kommen, dass andere SCMs das auch so machen. Und weil Programmierer aus
Gewohnheit `./configure` statt `sh configure` schreiben wollen.


  Stefan

[toc] | [prev] | [next] | [standalone]

#129802

Christian Garbs <mitch@cgarbs.de> wrote:
>Die alte git-FAQ sagt grob "ist Absicht, weil Buildsysteme":
>https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/Git_FAQ.html#Why_isn.27t_Git_preserving_modification_time_on_files.3F
>
>Damit können wir dann eigentlich aufhören, darüber zu diskutieren :)

Man könnte das immer noch optional einschaltbar machen. Dann muss man
sich nur noch über den Default streiten.

>Mini-Lösung für das Mitführen der Timestamps:
>https://gist.github.com/andris9/1978266
>Das lässt sich bestimmt irgendwie automatisieren über .git/hooks

Hooks sind auch so ein Thema, das m.E. nicht zuende gedacht ist.
Manche Hooks möchte man in jedem clone eines Repos haben, manche eben
nicht. Das so überhaupt nicht zu unterstützen ist für mich immer
wieder ein wtf-Moment.

>Mit dem Zeitstempel hast Du mehr Möglichkeiten, da kann die eine Seite
>den Zeitstempel auf "Montag" geändert haben und die andere auf
>"Dienstag", da musst Du irgendwie nachfragen.

Das würde ich abhängig machen von der Art und Weise wie die Konflikte
der Inhalte gelöst wurden: 100 % Übernahme aus A, Zeitstempel von A.
100 % Übernahme von B, Zeitstempel von B. Teilweise Übernahme aus A
und B, Zeitstempel des Merges, da zu diesem Zeitpunkt dieser Inhalt
entstanden ist.

In git blame wird das sowieso für jede Zeile einzeln mitgeführt, da
ist die Übernahme des Zeitstempels von A oder B trivial; die
Zeitstempel der unveränderten Zeilen dürften dann davon abhängen, ob
hier A in B oder B in A gemergt wurde.

Und schwupps, sind zwei gleiche Dateien wieder nicht gleich und das
Problem schon nach zwei Minuten Weiterdenken VIEL komplexer geworden.

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#129821

Am 06.04.2023 um 09:41 schrieb Marc Haber:
> Christian Garbs <mitch@cgarbs.de> wrote:
>> Mini-Lösung für das Mitführen der Timestamps:
>> https://gist.github.com/andris9/1978266
>> Das lässt sich bestimmt irgendwie automatisieren über .git/hooks
> 
> Hooks sind auch so ein Thema, das m.E. nicht zuende gedacht ist.
> Manche Hooks möchte man in jedem clone eines Repos haben, manche eben
> nicht. Das so überhaupt nicht zu unterstützen ist für mich immer
> wieder ein wtf-Moment.

Das ist halt wieder so ein Komfort <-> Sicherheit Ding.

Wenn beim Klonen jedes Mal ein Hook mitkommt, obwohl man einfach nur mal
kucken will, müsste man also nach jedem Klonen schauen, was für
ausführbaren Code man sich da eingetreten hat.

Und wenn man eh dem Repo soweit vertraut, dass man darin enthaltene
Skripte ausführt (`./configure`), kann man auch noch ein `setup-hook.sh`
ausführen.


  Stefan

[toc] | [prev] | [next] | [standalone]

#129831

Stefan Reuther <stefan.news@arcor.de> wrote:
>Wenn beim Klonen jedes Mal ein Hook mitkommt, obwohl man einfach nur mal
>kucken will, müsste man also nach jedem Klonen schauen, was für
>ausführbaren Code man sich da eingetreten hat.

git clone --nocode (gibt's nicht die Option, wäre aber
implementierbar).

>Und wenn man eh dem Repo soweit vertraut, dass man darin enthaltene
>Skripte ausführt (`./configure`), kann man auch noch ein `setup-hook.sh`
>ausführen.

Wieviele Repositories bringen sowas mit?

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#129833

Am 10.04.2023 um 09:02 schrieb Marc Haber:
> Stefan Reuther <stefan.news@arcor.de> wrote:
>> Wenn beim Klonen jedes Mal ein Hook mitkommt, obwohl man einfach nur mal
>> kucken will, müsste man also nach jedem Klonen schauen, was für
>> ausführbaren Code man sich da eingetreten hat.
> 
> git clone --nocode (gibt's nicht die Option, wäre aber
> implementierbar).

Das ist irgendwie das Gegenteil von "security by default". Da wäre man
dann da, wo man mit den Browsern vor 15 Jahren war, "wenn du das sicher
außerhalb eines kontrollierten Intranets betreiben willst, stell erst
mal folgende Optionen ein: ..."

>> Und wenn man eh dem Repo soweit vertraut, dass man darin enthaltene
>> Skripte ausführt (`./configure`), kann man auch noch ein `setup-hook.sh`
>> ausführen.
> 
> Wieviele Repositories bringen sowas mit?

Das könnte ein Indiz für den fehlenden Bedarf sein, das _genau so_ zu lösen.

Gerrit braucht u.a. einen commit-hook, und ich glaubte mich zu erinnern,
die hätten eine Lösung dafür, aber die empfehlen auch nur ein manuelles
Kopieren:
https://gerrit-review.googlesource.com/Documentation/user-changeid.html

Ansonsten muss man die Hooks sowieso auf dem Server ausführen, wenn man
bestimmte Eigenschaften sicherstellen will. Und als lokaler Nutzer will
ich beliebig kleinteilig und beliebig unsinnig committen können. Der
Server sieht dann nur das Ergebnis eines Rebase/Squash.

Damit ist lokal dann nur eine Frage des Komforts. Und wer den haben
will, baut sich ein `setup-hook.sh`.


  Stefan

[toc] | [prev] | [next] | [standalone]

#129839

Stefan Reuther <stefan.news@arcor.de> wrote:
>Ansonsten muss man die Hooks sowieso auf dem Server ausführen, wenn man
>bestimmte Eigenschaften sicherstellen will.

Ich möchte aber gerne schon beim Commit und nicht erst beim Push
wissen dass der Server das so nicht akzeptieren wird. Von mir aus
gerne als Warnung, dass das Commit trotzdem angenommen wird.

>Damit ist lokal dann nur eine Frage des Komforts. Und wer den haben
>will, baut sich ein `setup-hook.sh`.

Das ist leider unrealistisch.

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#129896

Marc Haber <mh+usenetspam1118@zugschl.us> wrote:

>>Ansonsten muss man die Hooks sowieso auf dem Server ausführen, wenn man
>>bestimmte Eigenschaften sicherstellen will.

> Ich möchte aber gerne schon beim Commit und nicht erst beim Push
> wissen dass der Server das so nicht akzeptieren wird. Von mir aus
> gerne als Warnung, dass das Commit trotzdem angenommen wird.

>>Damit ist lokal dann nur eine Frage des Komforts. Und wer den haben
>>will, baut sich ein `setup-hook.sh`.

> Das ist leider unrealistisch.

Beispielsweise GNU Emacs bietet dies in dem Rahmen von
autogen.sh.

Allerdings hätte eine solche Lösung, wie sie Dir vorstrebt,
einen erheblichen Charme: Jedes Mal, wenn ich in einem Py-
thon-Projekt irgendeine triviale Änderung vornehmen möchte
und dieses eine Testsuite beinhaltet, werde ich danach mit
der für mich schwierigen Frage konfrontiert, ob man jene nun
mit „tox“, „nosetests“, „py.test“ oder noch etwas anderem
ausführen muss und wie das noch einmal genau geht.

Da offensichtlich „./configure && make && make check“ nicht
mehr in Mode ist, könnte man vielleicht über den Umweg von
„Git Coding Standards“ Entwickler dazu anhalten, ein aus-
führbares Script zu Verfügung zu stellen, das Tests & Co.
vornimmmt.

Tim

[toc] | [prev] | [next] | [standalone]

#129800

Martin Vaeth <martin@mvath.de> wrote:
>Der Grund scheint mir aber eher zu sein, dass es eben
>kein Feature ist, das für *Softwareentwicklung* nützlich ist,
>und es deshalb eben "aus Prinzip" nicht unterstützt werden soll,
>weil git dafür nicht gedacht ist.

Das passt ja auch auf die Einstellung, dass die git-Autoren
mantraartig sagen, dass git kein Tool zum Verteilen von Dateien ist,
auch wenn es auf ganz breiter Front dafür genutzt wird (und den Job
wegen der Hartleibigkeit der Entwickler eher schlecht als recht macht)

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web