Wechsel von CVS zu Git: $ Id $ Äquivalent?

Ich habe eine Reihe von Fragen zu einfachen Tools zur Quellcodeverwaltung gelesen und Git schien mir eine vernünftige Wahl zu sein. Ich habe es in Betrieb und es funktioniert soweit gut. Ein Aspekt, den ich an CVS mag, ist die automatische Inkrementierung einer Versionsnummer.

Ich verstehe, dass dies in einem verteilten Repository weniger sinnvoll ist, aber als Entwickler möchte / brauche ich so etwas. Lassen Sie mich erklären, warum:

Ich benutze Emacs. In regelmäßigen Abständen suche ich nach neuen Versionen der Lisp-Quelldateien für Pakete von Drittanbietern. Angenommen, ich habe eine Datei, foo.el, die laut Header Version 1.3 ist. Wenn ich nach der neuesten Version schaue und sehe, dass es 1.143 oder 2.6 oder was auch immer ist, weiß ich, dass ich ziemlich weit zurück bin.

Wenn ich stattdessen ein paar Hashes mit 40 Zeichen sehe, weiß ich nicht, welche später sind, oder bekomme keine Vorstellung davon, wie viel später es ist. Ich würde es absolut hassen, wenn ich ChangeLogs manuell überprüfen müsste, um eine Vorstellung davon zu bekommen, wie veraltet ich bin.

Als Entwickler möchte ich diese Höflichkeit, wie ich sie sehe, auf die Leute ausdehnen, die meine Ausgabe verwenden (und vielleicht mache ich mir selbst etwas vor, aber das lassen wir für einen Moment beiseite). Ich möchte nicht daran denken müssen, die verdammte Zahl jedes Mal selbst zu erhöhen, oder einen Zeitstempel oder ähnliches. Das ist eine echte PITA, und das weiß ich aus Erfahrung.

Welche Alternativen habe ich? Wenn ich kein $ Id: $ -Äquivalent erhalten kann, wie kann ich sonst das angeben, wonach ich suche?

Ich sollte erwähnen, dass meine Erwartung ist, dass der Endbenutzer Git NICHT installiert hat und selbst wenn dies der Fall ist, kein lokales Repository hat (in der Tat erwarte ich, dass es nicht auf diese Weise verfügbar gemacht wird).

Die SHA ist nur eine Darstellung einer Version (wenn auch kanonisch). Der git describeBefehl bietet anderen und tut dies ganz gut.

Wenn ich beispielsweise git describein meinem Hauptzweig meiner zwischengespeicherten Java-Client-Client- Quelle ausgeführt werde, wird Folgendes angezeigt :

2.2-16-gc0cd61a

Das sagt zwei wichtige Dinge:

1. In diesem Baum wurden seit 2.2 genau 16 Commits ausgeführt
2. Der genaue Quellbaum kann auf dem Klon eines anderen Benutzers angezeigt werden.

Angenommen, Sie haben eine versionDatei mit der Quelle gepackt (oder sogar den gesamten Inhalt für die Verteilung neu geschrieben), um diese Nummer anzuzeigen. Angenommen, die gepackte Version war 2.2-12-g6c4ae7a(keine Version, aber eine gültige Version).

Sie können jetzt genau sehen, wie weit Sie hinter sich sind (4 Commits), und Sie können genau sehen, welche 4 Commits:

# The RHS of the .. can be origin/master or empty, or whatever you want.
% git log --pretty=format:"%h %an %s" 2.2-12-g6c4ae7a..2.2-16-gc0cd61a
c0cd61a Dustin Sallings More tries to get a timeout.
8c489ff Dustin Sallings Made the timeout test run on every protocol on every bui
fb326d5 Dustin Sallings Added a test for bug 35.
fba04e9 Valeri Felberg Support passing an expiration date into CAS operations.

Inzwischen gibt es Unterstützung für $ Id: $ in Git. Um es für die Datei README zu aktivieren, würden Sie "README ident" in .gitattributes einfügen . Platzhalter für Dateinamen werden unterstützt. Siehe man gitattributes für Details.

Dies ist keine unangemessene Anfrage des OP.

Mein Anwendungsfall ist:

1. Ich benutze Git für meinen persönlichen Code, daher keine Zusammenarbeit mit anderen.
2. Ich behalte dort System-Bash-Skripte, die möglicherweise verwendet werden, /usr/local/binwenn sie fertig sind.

Ich benutze drei separate Maschinen mit demselben Git-Repository. Es wäre schön zu wissen, in welcher "Version" der Datei ich mich gerade /usr/local/binbefinde, ohne ein Handbuch "diff -u <Repo-Version> <Version in / usr / local / bin>" erstellen zu müssen.

Wenn Sie negativ sind, denken Sie daran, dass es andere Anwendungsfälle gibt. Nicht jeder verwendet Git für die Zusammenarbeit, wobei die Dateien im Git-Repository ihr "endgültiger" Speicherort sind.

Wie auch immer, ich habe eine Attributdatei im Repository wie folgt erstellt:

cat .git/info/attributes
# see man gitattributes
*.sh ident
*.pl ident
*.cgi ident

Dann füge $ Id $ irgendwo in die Datei ein (ich setze es gerne nach dem Schebang).

Das Commit. Beachten Sie, dass dies nicht automatisch die erwartete Erweiterung bewirkt. Sie müssen die Datei beispielsweise neu zusammenstellen, z.

git commit foo.sh
rm foo.sh
git co foo.sh

Und dann sehen Sie die Erweiterung zum Beispiel:

$ head foo.sh
#!/bin/sh

# $Id: e184834e6757aac77fd0f71344934b1cd774e6d4 $

Einige gute Informationen finden Sie unter Wie aktiviere ich die Ident-Zeichenfolge für ein Git-Repository? .

Ich bin mir nicht sicher, ob dies jemals in Git sein wird. Um Linus zu zitieren :

"Der gesamte Begriff der Keyword-Ersetzung ist einfach völlig idiotisch. Es ist trivial," außerhalb "des eigentlichen Content-Trackings zu arbeiten, wenn Sie dies möchten, wenn Sie Bäume als Teerbälle usw. freigeben."

Es ist jedoch ziemlich einfach, das Protokoll zu überprüfen. Wenn Sie den stabilen Zweig von foo.el verfolgen, können Sie sehen, welche neuen Commits im Protokoll des stabilen Zweigs enthalten sind, die nicht in Ihrer lokalen Kopie enthalten sind. Wenn Sie die interne Versionsnummer von CVS simulieren möchten, können Sie den Zeitstempel des letzten Commits vergleichen.

Bearbeiten: Sie sollten dafür die Skripte eines anderen schreiben oder verwenden, natürlich nicht manuell.

Wie ich geschrieben habe vor :

Mit DSCM-Tools wie Bazaar ist es unmöglich, automatisch ID-Tags zu generieren, die eine sinnvolle Versionsnummer anzeigen, da sich die Entwicklungslinie aller von allen anderen unterscheiden kann. Jemand könnte sich also auf die Version „1.41“ einer Datei beziehen, aber Ihre Version „1.41“ dieser Datei ist anders.

Grundsätzlich macht $ Id $ mit Bazaar, Git und anderen Tools zur Verwaltung verteilten Quellcodes keinen Sinn.

Ich hatte das gleiche Problem. Ich brauchte eine Version, die einfacher als eine Hash-Zeichenfolge war und für Benutzer des Tools verfügbar war, ohne eine Verbindung zum Repository herstellen zu müssen.

Ich habe es mit einem Git-Pre-Commit-Hook gemacht und mein Skript geändert, um es automatisch aktualisieren zu können.

Ich stütze die Version auf die Anzahl der durchgeführten Commits. Dies ist eine leichte Rennbedingung, da zwei Personen gleichzeitig eine Verpflichtung eingehen könnten und beide glauben, dass sie dieselbe Versionsnummer festschreiben, aber wir haben nicht viele Entwickler für dieses Projekt.

Als Beispiel habe ich ein Skript, das ich in Ruby einchecke, und ich füge diesen Code hinzu - es ist ein ziemlich einfacher Code, so dass es einfach ist, in verschiedene Sprachen zu portieren, wenn Sie etwas in einer anderen Sprache einchecken (obwohl dies offensichtlich der Fall ist) funktioniert nicht einfach mit nicht ausführbaren Checkins (wie Textdateien). Ich habe hinzugefügt:

MYVERSION = '1.090'
## Call script to do updateVersion from .git/hooks/pre-commit
def updateVersion
  # We add 1 because the next commit is probably one more - though this is a race
  commits = %x[git log #{$0} | grep '^commit ' | wc -l].to_i + 1
  vers = "1.%0.3d" % commits

  t = File.read($0)
  t.gsub!(/^MYVERSION = '(.*)'$/, "MYVERSION = '#{vers}'")
  bak = $0+'.bak'
  File.open(bak,'w') { |f| f.puts t }
  perm = File.stat($0).mode & 0xfff
  File.rename(bak,$0)
  File.chmod(perm,$0)
  exit
end

Und dann füge ich dem Skript eine Befehlszeilenoption (-updateVersion) hinzu. Wenn ich sie also als "tool -updateVersion" bezeichne, ruft sie einfach updateVersion für das Tool auf, das den Wert "MYVERSION" an sich ändert und dann beendet (Sie könnten) Lassen Sie es auch andere Dateien aktualisieren, wenn diese ebenfalls geöffnet werden, wenn Sie dies wünschen.

Sobald das eingerichtet ist, gehe ich zum Git-Kopf und erstelle ein ausführbares einzeiliges Bash-Skript in .git/hooks/pre-commit.

Das Skript wechselt einfach in den Kopf des Git-Verzeichnisses und ruft mein Skript mit auf -updateVersion.

Jedes Mal, wenn ich das Pre-Commit-Skript einchecke, wird es ausgeführt, wodurch mein Skript mit -updateVersion ausgeführt wird. Anschließend wird die Variable MYVERSION basierend auf der Anzahl der Commits aktualisiert. Magie!

Wenn es für Sie wichtig ist, $ Keywords $ zu haben, könnten Sie vielleicht versuchen, stattdessen Mercurial zu betrachten? Es hat eine hgkeyword-Erweiterung, die implementiert, was Sie wollen. Mercurial ist sowieso als DVCS interessant.

Mit Git-Repositorys wird das tagObjekt verwendet. Dies kann verwendet werden, um ein Commit mit einer beliebigen Art von Zeichenfolge zu kennzeichnen, und kann zum Markieren von Versionen verwendet werden. Sie können diese Tags in einem Repository mit dem git tagBefehl sehen, der alle Tags zurückgibt.

Es ist einfach, ein Tag auszuchecken. Wenn beispielsweise ein Tag vorhanden ist v1.1, können Sie dieses Tag in einem Zweig wie diesem auschecken:

git checkout -b v1.1

Da es sich um ein Objekt der obersten Ebene handelt, wird der gesamte Verlauf dieses Commits angezeigt. Außerdem können Sie Diffs ausführen, Änderungen vornehmen und Zusammenführungen durchführen.

Darüber hinaus bleibt ein Tag bestehen, auch wenn der Zweig, in dem es sich befand, gelöscht wurde, ohne wieder in die Hauptzeile eingefügt zu werden.

Wenn ich das richtig verstehe, möchten Sie im Wesentlichen wissen, wie viele Commits für eine bestimmte Datei seit Ihrer letzten Aktualisierung durchgeführt wurden.

Holen Sie sich zuerst die Änderungen im Remote-Ursprung, aber führen Sie sie nicht in Ihrem masterZweig zusammen:

% git fetch

Holen Sie sich dann ein Protokoll der Änderungen, die an einer bestimmten Datei zwischen Ihrem masterZweig und der Fernbedienung vorgenommen wurden origin/master.

% git log master..origin/master foo.el

Dies gibt Ihnen die Log - Meldungen aller Commits, die im Remote - Repository passiert seit dem letzten verschmolzen origin/masterin Ihrem master.

Wenn Sie nur die Anzahl der Änderungen zählen möchten, leiten Sie sie an weiter wc. Sagen Sie so:

% git rev-list master..origin/master foo.el | wc -l

Wenn Sie nur möchten, dass die Leute eine Vorstellung davon bekommen, wie weit sie veraltet sind, kann Git sie auf verschiedene recht einfache Arten darüber informieren. Sie vergleichen beispielsweise die Daten des letzten Commits auf ihrem Trunk und Ihrem Trunk. Sie können verwenden, um git cherryzu sehen, wie viele Commits in Ihrem Trunk aufgetreten sind, die in ihrem nicht vorhanden sind.

Wenn das alles ist, wofür Sie dies möchten, würde ich nach einer Möglichkeit suchen, es ohne Versionsnummer bereitzustellen.

Außerdem würde ich mich nicht darum kümmern, die Höflichkeit auf irgendjemanden auszudehnen, es sei denn, Sie sind sicher, dass sie es wollen. :) :)

Um die Erweiterung auf alle Dateien in allen Unterverzeichnissen im Repository anzuwenden, fügen Sie .gitattributesdem Verzeichnis der obersten Ebene im Repository (dh dort, wo Sie normalerweise die .gitignoreDatei ablegen würden) eine Datei hinzu, die Folgendes enthält:

* ident

Um dies zu sehen, müssen Sie zuerst die Datei (en) effektiv auschecken, z. B. löschen oder auf irgendeine Weise bearbeiten. Stellen Sie sie dann wieder her mit:

git checkout .

Und Sie sollten sehen, $Id$ersetzt durch etwas wie:

$Id: ea701b0bb744c90c620f315e2438bc6b764cdb87 $

Von man gitattributes:

ident

Wenn die Attribut-ID für einen Pfad festgelegt ist, ersetzt Git $ Id $ im Blob-Objekt durch $ Id:, gefolgt vom 40-stelligen hexadezimalen Blob-Objektnamen, gefolgt von einem Dollarzeichen $ beim Auschecken. Jede Byte-Sequenz, die mit $ Id: beginnt und in der Arbeitsbaumdatei mit $ endet, wird beim Einchecken durch $ Id $ ersetzt.

Diese ID ändert sich jedes Mal, wenn eine neue Version der Datei festgeschrieben wird.

RCS-IDs eignen sich gut für Projekte mit nur einer Datei, aber für alle anderen Projekte sagt die $ Id $ nichts über das Projekt aus (es sei denn, Sie erzwingen Dummy-Check-Ins in eine Dummy-Versionsdatei).

Dennoch könnte man interessiert sein, wie man die Entsprechungen von $ Author $, $ Date $, $ Revision $, $ RCSfile $ usw. auf Dateiebene oder auf Commit-Ebene erhält (wie man sie dort platziert, wo einige Schlüsselwörter sind, ist eine andere Frage). Ich habe keine Antwort auf diese Fragen, sehe aber die Notwendigkeit, diese zu aktualisieren, insbesondere wenn die Dateien (jetzt in Git) von RCS-kompatiblen Systemen (CVS) stammen.

Solche Schlüsselwörter können interessant sein, wenn die Quellen getrennt von einem Git-Repository verteilt werden (das mache ich auch). Meine Lösung lautet wie folgt:

Jedes Projekt hat ein eigenes Verzeichnis, und im Projektstamm habe ich eine Textdatei mit dem Namen, .versionderen Inhalt die aktuelle Version beschreibt (der Name, der beim Exportieren der Quellen verwendet wird).

Während der Arbeit für die nächste Version extrahiert ein Skript diese .versionNummer, einen Git-Versionsdeskriptor (wie git describe) und eine monotone Build-Nummer .build(plus Host und Datum) in eine automatisch generierte Quelldatei, die mit dem endgültigen Programm verknüpft ist aus welcher Quelle und wann es gebaut wurde.

Ich entwickle neue Funktionen in separaten Zweigen und füge als erstes n(für "next") der .versionZeichenfolge hinzu (mehrere Zweige, die von derselben Wurzel stammen, würden dieselbe temporäre .versionNummer verwenden). Vor der Veröffentlichung entscheide ich, welche Zweige zusammengeführt werden sollen (hoffentlich haben alle die gleichen .version). Vor dem Festschreiben der Zusammenführung aktualisiere ich .versionauf die nächste Nummer (Haupt- oder Nebenaktualisierung, abhängig von den zusammengeführten Funktionen).

Wenn Sie die git wollen Informationen verpflichten zugänglich in den Code, dann Sie haben einen Pre-Build - Schritt zu tun , um es dorthin zu gelangen. In Bash für C / C ++ könnte es ungefähr so ​​aussehen:

prebuild.sh

#!/bin/bash
commit=$(git rev-parse HEAD)
tag=$(git describe --tags --always ${commit})
cat <<EOF >version.c
#include "version.h"
const char* git_tag="${tag}";
const char* git_commit="${commit}";
EOF

mit dem version.hAussehen wie:

#pragma once
const char* git_tag;
const char* git_commit;

Dann, wo immer Sie es in Ihrem Code #include "version.h"und Ihrer Referenz benötigen git_tagoder git_commitnach Bedarf.

Und Makefilevielleicht haben Sie so etwas:

all: package
version:
  ./prebuild.sh
package: version
  # the normal build stuff for your project

Dies hat den Vorteil von:

• Erhalten der aktuell korrekten Werte für diesen Build, unabhängig von Verzweigung, Zusammenführen von Kirschernte und dergleichen.

Diese Implementierung von prepublish.shhat die Nachteile von:

• Erzwingen einer Neukompilierung, auch wenn sich das git_tag/ git_commitnicht geändert hat.
• Lokale geänderte Dateien, die nicht festgeschrieben wurden, werden nicht berücksichtigt, wirken sich jedoch auf den Build aus.
  • Verwenden Sie git describe --tags --always --dirtydiese Option, um diesen Anwendungsfall zu erfassen.
• verschmutzt den globalen Namespace.

Ein Züchter prebuild.sh, der diese Probleme vermeiden könnte, bleibt dem Leser als Übung überlassen.

Ich stimme denen zu, die der Meinung sind, dass das Ersetzen von Token eher zu Build-Tools als zu Tools zur Versionskontrolle gehört.

Sie sollten über ein automatisiertes Release-Tool verfügen, mit dem Sie die Versions-IDs in Ihren Quellen zum Zeitpunkt der Freigabe der Version festlegen können.

Tag-Namen und andere verwandte Informationen können jetzt von Git über die export-substFunktion von automatisch direkt in Dateien bearbeitet werden gitattributes(5). Dies erfordert natürlich die Verwendung von git archive, um Releases zu erstellen, und nur in der resultierenden TAR-Datei sind die Ersetzungsänderungen sichtbar.

Fügen Sie beispielsweise in die .gitattributesDatei die folgende Zeile ein:

* export-subst

Dann können Sie in Quelldateien eine Zeile wie die folgende hinzufügen:

#ident  "@(#)PROJECTNAME:FILENAME:$Format:%D:%ci:%cN:%h$"

Und es wird erweitert, um in einer Version so auszusehen, die zum Beispiel erstellt wurde von git archive v1.2.0.90:

#ident  "@(#)PROJECTNAME:FILENAME:HEAD -> master, tag: v1.2.0.90:2020-04-03 18:40:44 -0700:Greg A. Woods:e48f949"

Da Sie Emacs verwenden, könnten Sie Glück haben :)

Ich bin zufällig auf diese Frage gestoßen, und auch zufällig bin ich vor einigen Tagen auf Lively gestoßen, ein Emacs-Paket, mit dem Sie lebhafte Stücke von Emacs Lisp in Ihrem Dokument haben können. Ich habe es nicht versucht, um ehrlich zu sein, aber es kam mir beim Lesen in den Sinn.

Ich kam auch von SCCS, RCS und CVS ( %W% %G% %U%).

Ich hatte eine ähnliche Herausforderung. Ich wollte wissen, welche Version ein Code auf einem System hat, auf dem er ausgeführt wird. Das System kann mit einem Netzwerk verbunden sein oder nicht. Auf dem System ist möglicherweise Git installiert oder nicht. Auf dem System ist möglicherweise das GitHub-Repository installiert oder nicht.

Ich wollte die gleiche Lösung für verschiedene Codetypen (.sh, .go, .yml, .xml usw.). Ich wollte, dass jede Person ohne Git- oder GitHub-Kenntnisse die Frage "Welche Version läuft?" Beantworten kann.

Also schrieb ich einen Wrapper um ein paar Git-Befehle. Ich benutze es, um eine Datei mit einer Versionsnummer und einigen Informationen zu markieren. Es löst meine Herausforderung. Es kann Ihnen helfen.

https://github.com/BradleyA/markit

git clone https://github.com/BradleyA/markit
cd markit

Um dieses Problem für mich selbst zu beheben, habe ich einen kleinen "Hack" als Post-Commit-Hook erstellt:

echo | tee --append *
git checkout *

Ausführlicher dokumentiert in diesem Beitrag auf meinem Blog .