git commit --amend soll hash summe beibehalten

[Felix (Gast)]

Hallo,

ich möchte in git ein commit machen, welcher aber die hash nicht 
verändern soll.

Ziel ist es die Hashnummer im Code in der Version zu hinterlegen und zu 
committen.

Jetzt ist die Hash natürlcih auch von der Zeit abhängig.

Aber auch wenn ich die Zeit vom vorigen commit angebe, wird die Hash 
verändert

git commit --amend --date "Wed May 4 12:53:50 2022 +0200" --no-edit

das Datum habe ich vom vorigen commit kopiert.

trotzdem ändert sich die Hash summe.

[ddd (Gast)]

Der Hash ergibt sich aus dem Inhalt des Objekts.
Somit geht 'gleicher Hash' nicht mit anderem Inhalt.

[Andi (Gast)]

Felix schrieb:
> Ziel ist es die Hashnummer im Code in der Version zu hinterlegen und zu
> committen.
>
> Jetzt ist die Hash natürlcih auch von der Zeit abhängig.

Und vom Inhalt, damit...

> trotzdem ändert sich die Hash summe.

... muss sich der Hash verändern.
Ist auch gut so. Mich würde es jedenfalls beunruhigen wenn jemand ohne 
Spuren zu hinterlassen im Repository Code ändern kann...

[Jim M. (turboj)]

Kannste knicken. Du simuliertst hier einen Angriff auf eine Krypto 
Infrastruktur.

Das ist (oder war bisher) mit SHA1 abgesichert, da brauchst Du ein 
komplettes Amazon Rechenzentum um das in überschaubarer Zeit zu knacken.

Das Git macht sich IIRC auch in die Hosen wenn 2 Commits die gleiche 
SHA1 Summe haben.

[foobar (Gast)]

Mach mal den folgenden Text korrekt:

Der SHA-1-Hash dieses Textes lautet:
  eabf7f17403a0a2943adcc1502bef01e015807ca

Da SHA-1 ja "gebrochen" ist, ist das nur eine kleine Fleißaufgabe ;-)

[Achim M. (minifloat)]

Wie wäre es, einen commit zu machen, der die finalisierte Software 
darstellt. Danach dessen commit-hash per postbuild in das binary 
einpflegen und mit einem commit sofort hinterher eben das binary 
sichern.

Nicht schön, aber funktional.

mfg mf

[Marcel (Gast)]

Ein Tag mit einem Versionsstring setzen und diesen im Code hinterlegen!

[Laborant (Gast)]

Felix schrieb:
> Ziel ist es die Hashnummer im Code in der Version zu hinterlegen und zu
> committen.

Das gehört nicht in das Repository/den Code von dem Projekt. Das ist 
Aufgabe des Packagers. Wenn du bspw. ein DEB/RPM/NIX/... Paket baust, 
kannst du die sourcen patchen oder zusätzliche 
CFLAGS=-DVERSION=v1.2.3-pre3+git.3784678 setzen.

[Jan K. (jan_k776)]

Wie bereits genannt, ein `--amend` ändert, genau so wie ein rebase 
grundsätzlich den hash. Muss man sich dran gewöhnen, dann geht es ;)

Um den SHA oder eine andere Versionsbeschreibung aus git (siehe 
https://git-scm.com/docs/git-describe) in den Code zu bekommen, darf er 
nicht in die sourcen, sondern muss von einem build script z.B. in ein 
DEFINE oder eine header Datei geschrieben werden, die nicht comitted 
wird.
Die Infos daraus werden im build Schritt in die Binary eingebaut, 
nicht als Klartext in die sourcen, die man einchecken müsste und somit 
das Henne/Ei Problem entsteht.

[imonbln (Gast)]

Ich denke, du könntest da was mit Git Attributes bauen 
https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#_keyword_expansion. 
Dann könntest du in deinem Projekt einen Platzhalter einfügen und beim 
Check-out trägt git dort die SHA1 des HEAD Commits ein automatisch ein. 
Wenn nun durch eine TOM (Technisch organisatorische Maßnahme) 
sichergestellt wird, dass die offiziellen Builds immer nur in ein Clean 
Repo gebaut werden, sollte das in etwa deine Anforderung erfüllen.

[Bob (Gast)]

Felix schrieb:

> Ziel ist es die Hashnummer im Code in der Version zu hinterlegen und zu
> committen.

Wozu soll das gut sein? Verwaltet git den Code oder umgekehrt?.....

[Bob (Gast)]

Jan K. schrieb:

> nicht als Klartext in die sourcen, die man einchecken müsste und somit
> das Henne/Ei Problem entsteht.

So kann man es auch ausdrücken... :-)