GIT-Submodul version auslesen

[himitsu]

Moin,

mit git show lässt sich Einiges auslesen, auch wenn in den 80.000 Format-Parametern die Zwei für Branchname und Tag fehlen, also wird auch noch git rev-parse und git describe benutzt.
> BranchName, Commit-Hash, Commit-Date und Author-Name

Code:

cd /d my-dir
git rev-parse --abbrev-ref HEAD > my.txt
git describe --tags --always --dirty=* >> my.txt
git show -s --format=format:"%%ci" >> my.txt

Dann noch bissl RegexStringReplace und raus kommt sowas
master e06ff3b02* 2020-04-10 08:15
bzw.
master 1.1.0 +15 e06ff3b02* 2020-04-10 08:15 .

Beim Hauptverzeichnis eines GIT-Submodule bekomme ich aber die Daten vom Push/Commit des leeren Verzeichnis im übergeordneten GIT-Repo, anstatt die des eingebundenen Repositories.
Wie kann man hier nun die "richtigen" Daten des Submodule bekommen?

git submodule status --recursive im Hauptverzeichnis des übergeordneten GIT-Repos, liefert mir zwar eine Liste,
aber muß ich hier nun das Gewünschte aus der Liste raus parsen, mich damit dann an github wenden und dort vom gewünschten Repo mir zum Hash die AbbreviatedHash, CommitDatum und den Tag holen?

Windows (TortoiseGit) kann es doch auch irgendwie.
git show/rev-parse/describe geben mir das Linke, aber ich möchte gern rechts haben. (HEAD als BranchName ist sonst auch sehr ähhhh "informativ")

[himitsu]

[Aviator]

Hilft dir diese SO Antwort eventuell weiter?

[himitsu]

Leider hilft das auch nicht und ich sehe da garkeinen Unterschied.
Es kommen immernoch die Daten vom übergeordneten Repository raus,
also Revision und Datum, als das Submodule hinzugefügt wurde, anstatt Revision und Datum der letzten Änderung im Submodul.

Code:

@echo off
setlocal EnableDelayedExpansion

REM cd /d %1

set gitdir=
if not exist ".git" goto 1
if exist ".git/config" goto 1
  for /f "delims=" %%x in (.git) do ( set "temp=%%x" & goto 2 )
  :2
  set temp=%temp:/=\%
  if "%temp:~0,8%" == "gitdir: "   if exist "%temp:~8%"   set gitdir=--git-dir=%temp:~8%
:1
echo %gitdir%

echo ##################
git rev-parse --abbrev-ref HEAD
git describe --tags --always --dirty=*
git show -s --format=format:"%%ci"

echo ##################
git %gitdir% rev-parse --abbrev-ref HEAD
git %gitdir% describe --tags --always --dirty=*
git %gitdir% show -s --format=format:"%%ci"

if not "%gitdir%" == "" (
  echo ##################
  echo -- & REM git rev-parse --submodule --abbrev-ref HEAD
  echo -- & REM git describe --submodule --tags --always --dirty=*
  git show --submodule=short -s --format=format:"%%ci"

  echo ##################
  echo -- & REM git %gitdir% rev-parse --submodule --abbrev-ref HEAD
  echo -- & REM git %gitdir% describe --submodule --tags --always --dirty=*
  git %gitdir% show --submodule=short -s --format=format:"%%ci"
)

echo ##################
pause

Neben dem --git-dir stand in der Doku auch ein --work-tree, aber auch wenn ich zusätzlich --work-tree=. anhänge, kommt das Selbe raus.

Vom Hauptverzeichnis des Submodule auf eine drinliegende Datei angewendet, also
-- .svn angehängt, ergibt "not in workingtree"
-- eineda.tei angehängt, ergibt keine Fehlermeldung, aber dafür eine leere Ausgabe (nichts) und für einen allgemeinen Code muss ich dann auch erst eine Datei im Verzeichnis suchen lassen.

Selbst wenn ich erstmal komplett raus springe und beide Pfade explizit angebe, wird die Info des übergeordneten Repository genommen.
cd /d C:\
git --git-dir=D:\RootDir\.git\modules\MySubmodule --work-tree=D:\RootDir\MySubmodule show
Aber wenn ich hier das übergeordnete Repository zerstöre, indem ich das .git-Verzeichnis umbennene, dann funktioniert es.
git --git-dir=D:\RootDir\__.git\modules\MySubmodule --work-tree=D:\RootDir\MySubmodule show
bzw. git --git-dir=..\__.git\modules\MySubmodule ohne vorheriges CD
Nur ich glaub das ist keine super Lösung, falls was schief geht und anschließend das Verzeichnis nicht wieder zurück umbenannt wird.
Oder wenn z.B. Tortoise-Git noch offen ist und das Verzeichnis sich nicht umbenennen lässt.


[Info]
Mit dem DelayedExpansion und SubStrings in der ( ) des FOR gab es Probleme (die Variablen mit ! wurden nicht aufgelöst, wenn ein ~ drin ist, und mit % sind sie nicht delayed),
aber zum Glück gibt es ja noch as gute alte GOTO.

[freimatz]

Zitat von himitsu:

Windows (TortoiseGit) kann es doch auch irgendwie.

procmon?

[himitsu]

Außer beim Erstellen eines Repository (wo es eine externe git.exe haben will), nutzt Tortoise eine eigene LibGit2-DLL und (meistens) nicht die Consolenversion.

Die Consolenanwendung verwendet intern ja ebenfalls die gleiche selben Funktionen.
Und da die Linuxjünger doch ALLES nur mit Console machen, sollten dort doch auch sämptliche Funktionen verfügbar sein.

[Assarbad]

Ich liebe Git! Es ist halt so ein einfaches Versionskontrollsystem eine einfache Objektablage. Die wunderbar lesbare Git-Dokumentation hat die Antwort: git-observe-ref mit dem Parameter --seduce-path ist dein Freund!

Okay, Scherz beiseite. It's funny because it's true, wie der gemeine Amerikaner sagt.

Das in NT-Skript/Batch zu machen halte ich jedoch ernsthaft für einen Fehler. Git for Windows liefert Bash mit und das kann und sollte man auch nutzen. Dort hättest du auch noch sed und awk, sowie die eingebaute Parameter Expansion zur Verfügung.

Das was du willst geht mit -C <Verzeichnis>, meine ich (habe es soeben mal mit git -C submod_dir show -s --format=format:"%ci" getestet, getestet auf Version: git version 2.26.2.windows.1). Es sei denn ich habe nicht begriffen was du eigentlich willst.

Ich vermute mal ganz stark, daß du über einen Defekt gestolpert bist, denn im Grunde muß ja der Pfad bei Angabe von --git-dir "berechnet" werden. Also mal lieber melden wenn das reproduzierbar ist. Das kann schonmal schiefgehen. Ohnehin habe ich Submodule bisher in noch keinem VCS zufriedenstellend gelöst gesehen. Mit -C machst du das gleiche wie bei tar -C, also einen Wechsel ins angegebene Verzeichnis (change directory).

Zitat von himitsu:

Außer beim Erstellen eines Repository (wo es eine externe git.exe haben will), nutzt Tortoise eine eigene LibGit2-DLL und (meistens) nicht die Consolenversion.

Eben. Und so machen es auch die ganzen IDEs. Und nebenbei werden noch allerlei redundante, rätselhafte und bescheuerte Konzepte hilfreich für den Benutzer ausgeblendet, so daß die wenigsten Nutzer wirklich Git benutzen, sondern vor allem ein Git-Repo mit einer halbwegs nutzbaren UI. Ja ja, der Siegeszug von "Git" ...

Zitat von himitsu:

Und da die Linuxjünger doch ALLES nur mit Console machen, sollten dort doch auch sämptliche Funktionen verfügbar sein.

In den - ungelogen - knapp 150 Git-Befehlen (146 auf Ubuntu 20.04, ermittelt mit find /usr/share/man -type f -name 'git-*' |wc -l) findet sich garantiert was, gell? Zusammen mit den zwei Dutzend Optionen pro Befehl kann man das auch mal flott auswendig lernen.

[himitsu]

ohh man, SVN ist da aber viel einfacher und besser

Wer hat denn Zeit für Bash? bin ja noch ausgelastet überlastet PowerShell zu lernen.


Das Ding liegt auf Github
und ich glaub das wurde normal mit git submodules add erstellt.

rootdir/.gitmodules hat mehrere solche Einträge

Code:

[submodule "SMODUL"]
   path = SMODUL
   url = [e-mail]:meine/smodul.git

zusätzlich sind im Hauptrepo jeweils diese Verzeichnisse (die schon da, selbst wenn man das Rekursive beim Clone vergessen hat)
rootdir/SMODUL/

im rootdir/SMODUL/.git steht nur gitdir: ../.git/modules/SMODUL drin.

die Dateien aus dem eigentlichen .git-Verzeichnis liegen
unter rootdir/.git/modules/SMODUL

und ich hatte nur versucht von rootdir/SMODUL die Infos zu bekommen.



Nja, mal sehn was ich da aus der zu großen Doku zusammenbekomm.

[Sherlock]

PowerShell ist doch gerade auf dem Weg das zeitliche zu segnen, sei Avantgardist und lerne bash, das in Windows 10 bereits da ist, und immer mehr Unterstützung erfahren wird.

Außerdem soll es doch ein Qualitätsmerkmal eines guten Entwicklers sein, auf 100 Hochzeiten zu tanzen...sagt man mir immer wieder, dann nicke ich weise und mach weiter nur meine zwei bis drei Hochzeiten auf Delphi/Win und Python/Linux.

Sherlock

[Assarbad]

Zitat von himitsu:

Nja, mal sehn was ich da aus der zu großen Doku zusammenbekomm.

Wie, hat -C für dich nicht funktioniert? Das wäre ungewöhnlich. Dann würde ich an deiner Stelle nochmal ein frisches Git for Windows drüberbügeln. Da scheint ja dann mehr im Argen zu liegen.