git: Dateidatum der neusten Datei erhalten?

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Mittwoch 21. April 2010, 13:32

jens hat geschrieben:Bisher offensichtlich nicht ;)
Git ist Neuland...
Dann brauchst du dich auch nicht wundern, denn ``git describe`` gibt ja ``NEUESTER_TAG-REVISIONS_SEIT_TAG-LETZTER_COMMIT_HASH`` aus. Wenn es keinen Tag gibt, wo sollte dann ``NEUESTER_TAG`` herkommen?
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
cofi
Moderator
Beiträge: 4432
Registriert: Sonntag 30. März 2008, 04:16
Wohnort: RGFybXN0YWR0

Mittwoch 21. April 2010, 13:40

jens hat geschrieben:Bin noch nicht so eingearbeitet in git. Aber 'master' ist der Name des branches und kann sich ändern, oder nicht?
Ja. Aehnlich `default` bei Hg.
lunar

Mittwoch 21. April 2010, 16:50

Der aktuelle Entwicklungszweig kann sich natürlich ändern, insofern ist es eigentlich nicht wirklich sinnvoll, "master" hart zu kodieren. Sinnvoller ist eigentlich "HEAD", denn das bezieht sich immer auf den Commit, auf dem die Änderungen des Arbeitsverzeichnisses basieren, also der Vater des nächsten Commits.

"git describe" ist natürlich das beste.
Benutzeravatar
jens
Moderator
Beiträge: 8487
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 21. April 2010, 17:32

Ah. Dann nehme ich ersrnal HEAD statt master,

Wenn "describe" auch ohne tags funktionieren würde, dann wäre ich dabei ;)
Zuletzt geändert von jens am Montag 26. April 2010, 09:44, insgesamt 1-mal geändert.

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Mittwoch 21. April 2010, 18:55

jens hat geschrieben:Wenn "describe" auch ohne tags funktionieren würde, dann wäre ich dabei ;)
Tuts doch auch, siehe dessen Dokumentation.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
jens
Moderator
Beiträge: 8487
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Freitag 27. August 2010, 15:46

So, hab das ganze nochmal geändert. Vorher hatte ich ja den Anfang vom letzten git commit hash an die Versionsnummer geheftet...

Aber was sagt schon eine "zufällige" Zeichenfolge aus? Man kann nicht wirklich leicht erkennen, auf welchen Stand man denn nun ist...

Also nehme ich nun lieber das Datum des letzten commits. Damit kann man doch wesentlich mehr anfangen.

Die Versionsnummer sieht dann z.B. so aus: v0.9.0.RC7.20100827.1442 (Format ist: %Y%m%d.%H%M)
vorher so: v0.9.0.RC6.git-ab3d422

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Freitag 27. August 2010, 21:56

Also ich find ja git Hashes jetzt gar nicht so schlecht, ist schließlich die Standardmethode in der Git-Welt einen Zustand des Trees zu markieren.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
jens
Moderator
Beiträge: 8487
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Montag 6. September 2010, 08:56

Da hast du schon recht. Mir geht es allerdings mit dem Zusatz in erster Linie darum, schnell zu wissen, auf welchem Stand man so ist. Also wie weit ist die aktuelle Version vom letzten git commit entfernt.

Beim Hash muss man erst mal umständlich recherchieren. Beim Datum hat man direkt eine Vorstellung wie neu oder alt die Version wohl ist...

Da aber sowas wie v0.9.0.RC7.20100827.1442 schon recht lang list, hänge ich seit neustem nur noch Monat und Tag an... Das reicht IMHO aus... Ist beim Jahreswechsel evtl. etwas verwirrend, aber was soll's...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
DasIch
User
Beiträge: 2512
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Montag 6. September 2010, 15:34

Das Datum ist aber nicht eindeutig, du solltest auf jedenfall den Hash drin haben.
lunar

Montag 6. September 2010, 15:51

@DasIch: Bei kleinen Projekten eindeutig genug, um zumindest den groben Stand zu beschreiben.
Benutzeravatar
jens
Moderator
Beiträge: 8487
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 25. Juli 2012, 08:30

Also ich mache es immer noch so, das ich bei all meinen Projekten das Datum an die Version hänge, siehe: https://github.com/jedie/PyLucid/blob/5 ... _init__.py

Nun hat jemand angemerkt das es Probleme mit pip und "requirements file" gibt: https://github.com/jedie/django-tools/issues/1
Das ist eigentlich ein Bug in pip: https://github.com/pypa/pip/issues/145

Das ganze kommt IMHO daher, das die Versionnummer immer nur das letzte git commit Datum erhält, wenn die sourcen überhaupt noch unter git Verwaltung stehen. Wenn also jemand das Package von PyPi installiert, gibt es kein Datum mehr an die Versionsnummer.

Nun hab ich herraus gefunden, das man doch sowas ähnliches wie svn:keywords und $LastChangedDate$ in git realisieren kann. Stichwörter: .gitattributes clean smudge

Das ganze hier bei http://git-scm.com/book/de/Customizing- ... -Erweitern erklärt.

So müßte man eine "hardcoded" __version__ hin bekommen, oder nicht?

Was haltet ihr davon?

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
lunar

Mittwoch 25. Juli 2012, 08:35

@jens: Gar nichts. Ich halte schon die Idee, automatisiert Versionsnummern – oder zumindest Teile davon – für veröffentlichte Versionen zu vergeben, für falsch. Veröffentliche Versionen müssen stabil sein, und dürfen keinesfalls von der Existenz irgendeines VCS abhängen. Ich halte auch wenig davon, Dateien unter der Kontrolle des VCS automatisch durch das VCS zu verändern, um Versionsnummern einzufügen.

Füge das Datum manuell in die Versionsnummer ein, wenn Du eine neue Version Deines Pakets veröffentlichst. Dann weißt Du, was passiert, und vergibst Versionsnummern bewusst und absichtlich.
Benutzeravatar
jens
Moderator
Beiträge: 8487
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 25. Juli 2012, 10:08

Es ist keine automatisiert Versionsnummer, sondern nur eine Erweiterung um das letzte commit Datum. Das ist IMHO hilfreich, damit User einordnen können wie alt/neu die Software ist. Das klappt besser als den git SHA-Hash Wert an die Versionsnummer zu hängen.

Ich hab mal was gebastelt: https://github.com/jedie/python-code-sn ... ippets/git

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Moderator
Beiträge: 8487
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 25. Juli 2012, 11:34

So, mit django-tools v0.24.3.0725 bzw. diesen commit: https://github.com/jedie/django-tools/c ... 2e0ec7f75c nutzte ich nun das neue Verfahren um das commit Datum an die versionsnummer zu hängen.

Eigentlich ist es ja sowas wie ein built Datum.

Ich hab nochmal ein paar Bugs gefixed und mehr Informationen in die README gepackt:

https://github.com/jedie/python-code-sn ... ippets/git

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Moderator
Beiträge: 8487
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 25. Juli 2012, 11:47

Ach, wo ich ein wenig unsicher bin ist die Änderung in der setup.py: https://github.com/jedie/django-tools/c ... f75c#L3R13

Also der Teil:

Code: Alles auswählen

if "sdist" in sys.argv or "--version" in sys.argv:
    # update the version string via gitattribute filter
    import subprocess
    subprocess.call(["rm", "django_tools/__init__.py"])
    subprocess.call(["/usr/bin/git", "checkout", "django_tools/__init__.py"])
Ich denke das muß sein, damit auch wirklich das Datum aktuell ist. Denn die Änderungen werden erst nach einem checkout gemacht und dazu muß die Datei am besten auch vorher nicht vorhanden sein...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Antworten