LibGit2

LibGit2.Buffer

Ein Datenpuffer zum Exportieren von Daten aus libgit2. Entspricht der git_buf Struktur.

Beim Abrufen von Daten aus LibGit2 würde eine typische Verwendung wie folgt aussehen:

buf_ref = Ref(Buffer())
@check ccall(..., (Ptr{Buffer},), buf_ref)
# Operation auf buf_ref
free(buf_ref)

Insbesondere ist zu beachten, dass LibGit2.free anschließend auf dem Ref-Objekt aufgerufen werden sollte.

LibGit2.CheckoutOptions

Entspricht der git_checkout_options Struktur.

Die Felder repräsentieren:

• version: Version der verwendeten Struktur, für den Fall, dass sich dies später ändert. Für jetzt immer 1.
• checkout_strategy: Bestimmt, wie mit Konflikten umgegangen werden soll und ob der Checkout/das Wiederherstellen fehlender Dateien erzwungen werden soll.
• disable_filters: Wenn ungleich null, keine Filter wie CLRF anwenden (um Zeilenumbrüche zwischen UNIX und DOS zu konvertieren).
• dir_mode: Lese-/Schreib-/Zugriffsmodus für alle Verzeichnisse, die am Checkout beteiligt sind. Standard ist 0755.
• file_mode: Lese-/Schreib-/Zugriffsmodus für alle Dateien, die am Checkout beteiligt sind. Standard ist 0755 oder 0644, abhängig vom Blob.
• file_open_flags: Bitflags, die verwendet werden, um Dateien während des Checkouts zu öffnen.
• notify_flags: Flags, für welche Art von Konflikten der Benutzer benachrichtigt werden sollte.
• notify_cb: Eine optionale Callback-Funktion, um den Benutzer zu benachrichtigen, wenn ein Checkout-Konflikt auftritt. Wenn diese Funktion einen Wert ungleich null zurückgibt, wird der Checkout abgebrochen.
• notify_payload: Payload für die Benachrichtigungs-Callback-Funktion.
• progress_cb: Eine optionale Callback-Funktion, um den Fortschritt des Checkouts anzuzeigen.
• progress_payload: Payload für den Fortschritts-Callback.
• paths: Wenn nicht leer, beschreibt, welche Pfade während des Checkouts durchsucht werden sollen. Wenn leer, erfolgt der Checkout über alle Dateien im Repository.
• baseline: Erwarteter Inhalt des workdir, erfasst in einem (Zeiger auf ein) GitTree. Standardmäßig der Zustand des Baums bei HEAD.
• baseline_index: Erwarteter Inhalt des workdir, erfasst in einem (Zeiger auf ein) GitIndex. Standardmäßig der Zustand des Index bei HEAD.
• target_directory: Wenn nicht leer, Checkout in dieses Verzeichnis anstelle des workdir.
• ancestor_label: Im Falle von Konflikten der Name der gemeinsamen Vorfahren-Seite.
• our_label: Im Falle von Konflikten der Name der "unseren" Seite.
• their_label: Im Falle von Konflikten der Name der "deren" Seite.
• perfdata_cb: Eine optionale Callback-Funktion, um Leistungsdaten anzuzeigen.
• perfdata_payload: Payload für den Leistungs-Callback.

LibGit2.CloneOptions

Entspricht der git_clone_options Struktur.

Die Felder repräsentieren:

• version: Version der verwendeten Struktur, für den Fall, dass sich dies später ändert. Für jetzt immer 1.
• checkout_opts: Die Optionen für das Auschecken des Remotes im Rahmen des Klonens.
• fetch_opts: Die Optionen für das Vorab-Abrufen des Remotes im Rahmen des Klonens.
• bare: Wenn 0, klonen Sie das vollständige Remote-Repository. Wenn ungleich null, führen Sie ein Bare-Klon durch, bei dem es keine lokale Kopie der Quelldateien im Repository gibt und die gitdir und workdir gleich sind.
• localclone: Flag, ob eine lokale Objekt-Datenbank geklont oder ein Abruf durchgeführt werden soll. Der Standardwert ist, git entscheiden zu lassen. Es wird den git-bewussten Transport für ein lokales Klon nicht verwenden, aber für URLs, die mit file:// beginnen.
• checkout_branch: Der Name des Branches, der ausgecheckt werden soll. Wenn eine leere Zeichenfolge, wird der Standardbranch des Remotes ausgecheckt.
• repository_cb: Ein optionaler Callback, der verwendet wird, um das neue Repository zu erstellen, in das das Klonen erfolgt.
• repository_cb_payload: Die Nutzlast für den Repository-Callback.
• remote_cb: Ein optionaler Callback, der verwendet wird, um das GitRemote zu erstellen, bevor das Klonen von ihm erfolgt.
• remote_cb_payload: Die Nutzlast für den Remote-Callback.

LibGit2.DescribeOptions

Entspricht der git_describe_options Struktur.

Die Felder repräsentieren:

• version: Version der verwendeten Struktur, für den Fall, dass sich dies später ändert. Für jetzt immer 1.
• max_candidates_tags: Berücksichtige so viele der aktuellsten Tags in refs/tags, um einen Commit zu beschreiben. Standardmäßig 10 (so dass die 10 aktuellsten Tags untersucht werden, um zu sehen, ob sie einen Commit beschreiben).
• describe_strategy: ob alle Einträge in refs/tags (entspricht git-describe --tags) oder alle Einträge in refs/ (entspricht git-describe --all) berücksichtigt werden sollen. Der Standard ist, nur annotierte Tags anzuzeigen. Wenn Consts.DESCRIBE_TAGS übergeben wird, werden alle Tags, annotiert oder nicht, berücksichtigt. Wenn Consts.DESCRIBE_ALL übergeben wird, wird jeder Ref in refs/ berücksichtigt.
• pattern: Berücksichtige nur Tags, die mit pattern übereinstimmen. Unterstützt Glob-Erweiterung.
• only_follow_first_parent: Beim Finden der Distanz von einem übereinstimmenden Verweis zum beschriebenen Objekt, nur die Distanz vom ersten Elternteil berücksichtigen.
• show_commit_oid_as_fallback: Wenn kein übereinstimmender Verweis gefunden werden kann, der einen Commit beschreibt, zeige den Commit's GitHash anstelle eines Fehlers (das Standardverhalten).

LibGit2.DescribeFormatOptions

Entspricht der git_describe_format_options Struktur.

Die Felder repräsentieren:

• version: Version der verwendeten Struktur, für den Fall, dass sich dies später ändert. Zurzeit immer 1.
• abbreviated_size: untere Grenze für die Größe des abgekürzten GitHash, die verwendet werden soll, standardmäßig 7.
• always_use_long_format: auf 1 setzen, um das lange Format für Strings zu verwenden, auch wenn ein kurzes Format verwendet werden kann.
• dirty_suffix: Wenn gesetzt, wird dies am Ende des Beschreibungsstrings angehängt, wenn das workdir schmutzig ist.

LibGit2.DiffDelta

Beschreibung der Änderungen an einem Eintrag. Entspricht der git_diff_delta Struktur.

Die Felder repräsentieren:

• status: Eines von Consts.DELTA_STATUS, das angibt, ob die Datei hinzugefügt/modifiziert/gelöscht wurde.
• flags: Flags für das Delta und die Objekte auf jeder Seite. Bestimmt, ob die Datei(en) als binär/text behandelt werden, ob sie auf jeder Seite des Diffs existieren und ob die Objekt-IDs als korrekt bekannt sind.
• similarity: Wird verwendet, um anzuzeigen, ob eine Datei umbenannt oder kopiert wurde.
• nfiles: Die Anzahl der Dateien im Delta (zum Beispiel, wenn das Delta auf eine Submodul-Commit-ID angewendet wurde, kann es mehr als eine Datei enthalten).
• old_file: Eine DiffFile, die Informationen über die Datei(en) vor den Änderungen enthält.
• new_file: Eine DiffFile, die Informationen über die Datei(en) nach den Änderungen enthält.

LibGit2.DiffFile

Beschreibung einer Seite eines Deltas. Entspricht der git_diff_file Struktur.

Die Felder repräsentieren:

• id: der GitHash des Elements im Diff. Wenn das Element auf dieser Seite des Diffs leer ist (zum Beispiel, wenn das Diff die Entfernung einer Datei betrifft), wird dies GitHash(0) sein.
• path: ein mit NULL terminiertem Pfad zum Element relativ zum Arbeitsverzeichnis des Repositories.
• size: die Größe des Elements in Bytes.
• flags: eine Kombination der git_diff_flag_t Flags. Das ite Bit dieser Ganzzahl setzt das ite Flag.
• mode: der stat Modus für das Element.
• id_abbrev: nur vorhanden in LibGit2-Versionen, die neuer oder gleich 0.25.0 sind. Die Länge des id-Feldes, wenn es mit string konvertiert wird. Üblicherweise gleich OID_HEXSZ (40).

LibGit2.DiffOptionsStruct

Entspricht der git_diff_options Struktur.

Die Felder repräsentieren:

• version: Version der verwendeten Struktur, für den Fall, dass sich dies später ändert. Derzeit immer 1.
• flags: Flags, die steuern, welche Dateien im Diff erscheinen. Standardmäßig DIFF_NORMAL.
• ignore_submodules: ob Dateien in Submodulen betrachtet werden sollen oder nicht. Standardmäßig SUBMODULE_IGNORE_UNSPECIFIED, was bedeutet, dass die Konfiguration des Submoduls steuert, ob es im Diff erscheint oder nicht.
• pathspec: Pfad zu Dateien, die im Diff enthalten sein sollen. Standard ist die Verwendung aller Dateien im Repository.
• notify_cb: optionale Callback-Funktion, die den Benutzer über Änderungen am Diff informiert, während Dateideltas hinzugefügt werden.
• progress_cb: optionale Callback-Funktion, die den Fortschritt des Diffs anzeigt. Nur relevant bei libgit2-Versionen, die mindestens so neu sind wie 0.24.0.
• payload: die Nutzlast, die an notify_cb und progress_cb übergeben wird.
• context_lines: die Anzahl der unveränderten Zeilen, die verwendet werden, um die Ränder eines Hunk zu definieren. Dies ist auch die Anzahl der Zeilen, die vor/nach einem Hunk angezeigt werden, um Kontext bereitzustellen. Standard ist 3.
• interhunk_lines: die maximale Anzahl von unveränderten Zeilen zwischen zwei separaten Hunks, die erlaubt sind, bevor die Hunks kombiniert werden. Standard ist 0.
• id_abbrev: legt die Länge des abgekürzten GitHash fest, die gedruckt werden soll. Standard ist 7.
• max_size: die maximale Dateigröße eines Blobs. Über dieser Größe wird es als binärer Blob behandelt. Der Standardwert beträgt 512 MB.
• old_prefix: das virtuelle Verzeichnis, in dem alte Dateien auf einer Seite des Diffs platziert werden. Der Standardwert ist "a".
• new_prefix: das virtuelle Verzeichnis, in dem neue Dateien auf einer Seite des Diffs platziert werden. Der Standardwert ist "b".

LibGit2.FetchHead

Enthält die Informationen über HEAD während eines Fetch, einschließlich des Namens und der URL des Branches, von dem abgerufen wurde, der oid des HEAD und ob der abgerufene HEAD lokal zusammengeführt wurde.

Die Felder repräsentieren:

• name: Der Name in der lokalen Referenzdatenbank des Fetch-Head, zum Beispiel "refs/heads/master".
• url: Die URL des Fetch-Head.
• oid: Der GitHash des Tipps des Fetch-Head.
• ismerge: Boolean-Flag, das angibt, ob die Änderungen am Remote bereits in die lokale Kopie zusammengeführt wurden oder nicht. Wenn true, ist die lokale Kopie mit dem Remote-Fetch-Head auf dem neuesten Stand.

LibGit2.FetchOptions

Entspricht der git_fetch_options Struktur.

Die Felder repräsentieren:

• version: Version der verwendeten Struktur, für den Fall, dass sich dies später ändert. Für jetzt immer 1.
• callbacks: Remote-Callbacks, die während des Fetch verwendet werden sollen.
• prune: ob nach dem Fetch ein Prune durchgeführt werden soll oder nicht. Der Standard ist, die Einstellung aus der GitConfig zu verwenden.
• update_fetchhead: ob das FetchHead nach dem Fetch aktualisiert werden soll. Der Standard ist, das Update durchzuführen, was das normale Git-Verhalten ist.
• download_tags: ob Tags, die am Remote vorhanden sind, heruntergeladen werden sollen oder nicht. Der Standard ist, die Tags für Objekte anzufordern, die ohnehin vom Server heruntergeladen werden.
• proxy_opts: Optionen für die Verbindung zum Remote über einen Proxy. Siehe ProxyOptions. Nur vorhanden in libgit2-Versionen, die neuer oder gleich 0.25.0 sind.
• custom_headers: alle zusätzlichen Header, die für den Fetch benötigt werden. Nur vorhanden in libgit2-Versionen, die neuer oder gleich 0.24.0 sind.

GitAnnotated(repo::GitRepo, commit_id::GitHash)
GitAnnotated(repo::GitRepo, ref::GitReference)
GitAnnotated(repo::GitRepo, fh::FetchHead)
GitAnnotated(repo::GitRepo, committish::AbstractString)

Ein annotierter Git-Commit enthält Informationen darüber, wie er gefunden wurde und warum, sodass Rebase- oder Merge-Operationen mehr Informationen über den Kontext des Commits haben. Konfliktdateien enthalten Informationen über die Quell-/Zielzweige im Merge, die Konflikte aufweisen. Ein annotierter Commit kann sich beispielsweise auf die Spitze eines Remote-Zweigs beziehen, wenn ein FetchHead übergeben wird, oder auf einen Zweigkopf, der mit GitReference beschrieben wird.

GitBlame(repo::GitRepo, path::AbstractString; options::BlameOptions=BlameOptions())

Konstruiere ein GitBlame-Objekt für die Datei unter path, wobei Änderungsinformationen aus der Historie von repo verwendet werden. Das GitBlame-Objekt zeichnet auf, wer welche Teile der Datei wann und wie geändert hat. options steuert, wie der Inhalt der Datei getrennt wird und welche Commits untersucht werden sollen - siehe BlameOptions für weitere Informationen.

GitBlob(repo::GitRepo, hash::AbstractGitHash)
GitBlob(repo::GitRepo, spec::AbstractString)

Gibt ein GitBlob-Objekt aus repo zurück, das durch hash/spec angegeben ist.

• hash ist ein vollständiger (GitHash) oder teilweiser (GitShortHash) Hash.
• spec ist eine textuelle Spezifikation: siehe die git-Dokumentation für eine vollständige Liste.

GitCommit(repo::GitRepo, hash::AbstractGitHash)
GitCommit(repo::GitRepo, spec::AbstractString)

Gibt ein GitCommit-Objekt aus repo zurück, das durch hash/spec angegeben ist.

• hash ist ein vollständiger (GitHash) oder teilweiser (GitShortHash) Hash.
• spec ist eine textuelle Spezifikation: siehe die git-Dokumentation für eine vollständige Liste.

GitConfig(path::AbstractString, level::Consts.GIT_CONFIG=Consts.CONFIG_LEVEL_APP, force::Bool=false)

Erstellen Sie eine neue GitConfig, indem Sie Konfigurationsinformationen aus der Datei unter path laden. Siehe addfile für weitere Informationen zu den Optionen level, repo und force.

GitConfig(repo::GitRepo)

Holen Sie sich die gespeicherte Konfiguration für das Git-Repository repo. Wenn repo keine spezifische Konfigurationsdatei festgelegt hat, wird die Standard-Git-Konfiguration verwendet.

GitConfig(level::Consts.GIT_CONFIG=Consts.CONFIG_LEVEL_DEFAULT)

Holen Sie sich die Standard-Git-Konfiguration, indem Sie die globalen und systemweiten Konfigurationsdateien in eine priorisierte Konfiguration laden. Dies kann verwendet werden, um auf Standardkonfigurationsoptionen außerhalb eines bestimmten Git-Repositorys zuzugreifen.

GitHash

Ein Git-Objektbezeichner, basierend auf dem sha-1-Hash. Es ist eine 20-Byte-Zeichenkette (40 hexadezimale Ziffern), die verwendet wird, um ein GitObject in einem Repository zu identifizieren.

GitObject(repo::GitRepo, hash::AbstractGitHash)
GitObject(repo::GitRepo, spec::AbstractString)

Gibt das angegebene Objekt (GitCommit, GitBlob, GitTree oder GitTag) aus repo zurück, das durch hash/spec angegeben ist.

• hash ist ein vollständiger (GitHash) oder teilweiser (GitShortHash) Hash.
• spec ist eine textuelle Spezifikation: siehe die git-Dokumentation für eine vollständige Liste.

GitRemote(repo::GitRepo, rmt_name::AbstractString, rmt_url::AbstractString) -> GitRemote

Suchen Sie ein entferntes Git-Repository anhand seines Namens und seiner URL. Verwendet die Standard-Fetch-Refspec.

Beispiele

repo = LibGit2.init(repo_path)
remote = LibGit2.GitRemote(repo, "upstream", repo_url)

GitRemote(repo::GitRepo, rmt_name::AbstractString, rmt_url::AbstractString, fetch_spec::AbstractString) -> GitRemote

Suchen Sie ein entferntes Git-Repository anhand des Namens und der URL des Repositories sowie der Spezifikationen, wie von dem Remote abgerufen werden soll (z. B. welcher Remote-Zweig abgerufen werden soll).

Beispiele

repo = LibGit2.init(repo_path)
refspec = "+refs/heads/mybranch:refs/remotes/origin/mybranch"
remote = LibGit2.GitRemote(repo, "upstream", repo_url, refspec)

GitRemoteAnon(repo::GitRepo, url::AbstractString) -> GitRemote

Suchen Sie ein entferntes Git-Repository nur mit seiner URL, nicht mit seinem Namen.

Beispiele

repo = LibGit2.init(repo_path)
remote = LibGit2.GitRemoteAnon(repo, repo_url)

LibGit2.GitRepo(path::AbstractString)

Öffne ein Git-Repository unter path.

LibGit2.GitRepoExt(path::AbstractString, flags::Cuint = Cuint(Consts.REPOSITORY_OPEN_DEFAULT))

Öffnen Sie ein Git-Repository unter path mit erweiterten Steuerungen (zum Beispiel, wenn der aktuelle Benutzer Mitglied einer speziellen Zugriffsgruppe sein muss, um path zu lesen).

GitRevWalker(repo::GitRepo)

Ein GitRevWalker geht durch die Revisionen (d.h. Commits) eines Git-Repositorys repo. Es ist eine Sammlung der Commits im Repository und unterstützt Iteration sowie Aufrufe von LibGit2.map und LibGit2.count (zum Beispiel könnte LibGit2.count verwendet werden, um zu bestimmen, welcher Prozentsatz der Commits in einem Repository von einem bestimmten Autor erstellt wurde).

cnt = LibGit2.with(LibGit2.GitRevWalker(repo)) do walker
    LibGit2.count((oid,repo)->(oid == commit_oid1), walker, oid=commit_oid1, by=LibGit2.Consts.SORT_TIME)
end

Hier findet LibGit2.count die Anzahl der Commits entlang des Weges mit einem bestimmten GitHash. Da der GitHash einzigartig für einen Commit ist, wird cnt 1 sein.

GitShortHash(hash::GitHash, len::Integer)

Ein verkürzter Git-Objektbezeichner, der verwendet werden kann, um ein Git-Objekt zu identifizieren, wenn es eindeutig ist, und der aus den ersten len hexadezimalen Ziffern von hash besteht (die verbleibenden Ziffern werden ignoriert).

LibGit2.GitSignature

Dies ist ein Julia-Wrapper um einen Zeiger auf ein git_signature Objekt.

LibGit2.GitStatus(repo::GitRepo; status_opts=StatusOptions())

Sammeln Sie Informationen über den Status jeder Datei im Git-Repository repo (z. B. ob die Datei geändert, gestaged usw. ist). status_opts kann verwendet werden, um verschiedene Optionen festzulegen, zum Beispiel, ob untracked Dateien betrachtet werden sollen oder ob Submodule einbezogen werden sollen oder nicht. Siehe StatusOptions für weitere Informationen.

GitTag(repo::GitRepo, hash::AbstractGitHash)
GitTag(repo::GitRepo, spec::AbstractString)

Gibt ein GitTag-Objekt aus repo zurück, das durch hash/spec angegeben ist.

• hash ist ein vollständiger (GitHash) oder teilweiser (GitShortHash) Hash.
• spec ist eine textuelle Spezifikation: siehe die git-Dokumentation für eine vollständige Liste.

GitTree(repo::GitRepo, hash::AbstractGitHash)
GitTree(repo::GitRepo, spec::AbstractString)

Gibt ein GitTree-Objekt aus repo zurück, das durch hash/spec angegeben ist.

• hash ist ein vollständiger (GitHash) oder teilweiser (GitShortHash) Hash.
• spec ist eine textuelle Spezifikation: siehe die git-Dokumentation für eine vollständige Liste.

LibGit2.IndexEntry

In-Memory-Darstellung eines Dateieintrags im Index. Entspricht der git_index_entry Struktur.

LibGit2.IndexTime

Entspricht der git_index_time Struktur.

LibGit2.BlameOptions

Entspricht der git_blame_options Struktur.

Die Felder repräsentieren:

• version: Version der verwendeten Struktur, für den Fall, dass sich dies später ändert. Für jetzt immer 1.
• flags: eines von Consts.BLAME_NORMAL oder Consts.BLAME_FIRST_PARENT (die anderen Blame-Flags sind von libgit2 noch nicht implementiert).
• min_match_characters: die minimale Anzahl von alphanumerischen Zeichen, die sich in einem Commit ändern müssen, damit die Änderung mit diesem Commit assoziiert wird. Der Standardwert ist 20. Hat nur Wirkung, wenn eines der Consts.BLAME_*_COPIES-Flags verwendet wird, die libgit2 noch nicht implementiert.
• newest_commit: der GitHash des neuesten Commits, von dem aus Änderungen betrachtet werden sollen.
• oldest_commit: der GitHash des ältesten Commits, von dem aus Änderungen betrachtet werden sollen.
• min_line: die erste Zeile der Datei, von der aus mit dem Blamen begonnen werden soll. Der Standardwert ist 1.
• max_line: die letzte Zeile der Datei, die geblamet werden soll. Der Standardwert ist 0, was die letzte Zeile der Datei bedeutet.

LibGit2.MergeOptions

Entspricht der git_merge_options Struktur.

Die Felder repräsentieren:

• version: Version der verwendeten Struktur, falls sich dies später ändert. Für jetzt immer 1.

• flags: ein enum für Flags, die das Merge-Verhalten beschreiben. Definiert in git_merge_flag_t. Das entsprechende Julia-Enum ist GIT_MERGE und hat folgende Werte:

  • MERGE_FIND_RENAMES: erkennen, ob eine Datei zwischen dem gemeinsamen Vorfahren und der "unseren" oder "deren" Seite des Merges umbenannt wurde. Ermöglicht Merges, bei denen eine Datei umbenannt wurde.
  • MERGE_FAIL_ON_CONFLICT: sofort beenden, wenn ein Konflikt gefunden wird, anstatt zu versuchen, ihn zu lösen.
  • MERGE_SKIP_REUC: die REUC-Erweiterung nicht im Index zu schreiben, der aus dem Merge resultiert.
  • MERGE_NO_RECURSIVE: wenn die zusammengeführten Commits mehrere Merge-Basen haben, die erste verwenden, anstatt zu versuchen, die Basen rekursiv zu mergen.

• rename_threshold: wie ähnlich zwei Dateien sein müssen, um eine als Umbenennung der anderen zu betrachten. Dies ist eine Ganzzahl, die die prozentuale Ähnlichkeit festlegt. Der Standardwert ist 50.

• target_limit: die maximale Anzahl von Dateien, mit denen verglichen werden soll, um nach Umbenennungen zu suchen. Der Standardwert ist 200.

• metric: optionale benutzerdefinierte Funktion, die verwendet wird, um die Ähnlichkeit zwischen zwei Dateien zur Erkennung von Umbenennungen zu bestimmen.

• recursion_limit: die obere Grenze für die Anzahl der Merges von gemeinsamen Vorfahren, die durchgeführt werden sollen, um zu versuchen, eine neue virtuelle Merge-Basis für den Merge zu erstellen. Der Standardwert ist keine Grenze. Dieses Feld ist nur in libgit2-Versionen neuer als 0.24.0 vorhanden.

• default_driver: der Merge-Treiber, der verwendet werden soll, wenn beide Seiten geändert wurden. Dieses Feld ist nur in libgit2-Versionen neuer als 0.25.0 vorhanden.

• file_favor: wie mit konfliktierenden Dateiinhalten für den text-Treiber umgegangen werden soll.

  • MERGE_FILE_FAVOR_NORMAL: wenn beide Seiten des Merges Änderungen an einem Abschnitt haben, eine Notiz über den Konflikt im Index machen, den git checkout verwenden wird, um eine Merge-Datei zu erstellen, auf die der Benutzer dann verweisen kann, um die Konflikte zu lösen. Dies ist der Standard.
  • MERGE_FILE_FAVOR_OURS: wenn beide Seiten des Merges Änderungen an einem Abschnitt haben, die Version auf der "unseren" Seite des Merges im Index verwenden.
  • MERGE_FILE_FAVOR_THEIRS: wenn beide Seiten des Merges Änderungen an einem Abschnitt haben, die Version auf der "deren" Seite des Merges im Index verwenden.
  • MERGE_FILE_FAVOR_UNION: wenn beide Seiten des Merges Änderungen an einem Abschnitt haben, jede einzigartige Zeile von beiden Seiten in die Datei einfügen, die in den Index aufgenommen wird.

• file_flags: Richtlinien für das Mergen von Dateien.

LibGit2.ProxyOptions

Optionen für die Verbindung über einen Proxy.

Entspricht der git_proxy_options Struktur.

Die Felder repräsentieren:

• version: Version der verwendeten Struktur, falls sich dies später ändert. Für jetzt immer 1.

• proxytype: ein enum für den Typ des zu verwendenden Proxys. Definiert in git_proxy_t. Das entsprechende Julia-Enum ist GIT_PROXY und hat die Werte:

  • PROXY_NONE: keine Verbindung über einen Proxy versuchen.
  • PROXY_AUTO: versuchen, die Proxy-Konfiguration aus der Git-Konfiguration zu ermitteln.
  • PROXY_SPECIFIED: Verbindung unter Verwendung der im url-Feld dieser Struktur angegebenen URL herstellen.

  Standardmäßig wird der Proxytyp automatisch erkannt.

• url: die URL des Proxys.

• credential_cb: ein Zeiger auf eine Callback-Funktion, die aufgerufen wird, wenn der Remote-Server eine Authentifizierung zur Verbindung benötigt.

• certificate_cb: ein Zeiger auf eine Callback-Funktion, die aufgerufen wird, wenn die Zertifikatsüberprüfung fehlschlägt. Dies ermöglicht es dem Benutzer zu entscheiden, ob die Verbindung fortgesetzt werden soll oder nicht. Wenn die Funktion 1 zurückgibt, wird die Verbindung erlaubt. Wenn sie 0 zurückgibt, wird die Verbindung nicht erlaubt. Ein negativer Wert kann verwendet werden, um Fehler zurückzugeben.

• payload: die Nutzlast, die den beiden Callback-Funktionen bereitgestellt werden soll.

Beispiele

julia> fo = LibGit2.FetchOptions(
           proxy_opts = LibGit2.ProxyOptions(url = Cstring("https://my_proxy_url.com")))

julia> fetch(remote, "master", options=fo)

LibGit2.PushOptions

Entspricht der git_push_options Struktur.

Die Felder repräsentieren:

• version: Version der verwendeten Struktur, für den Fall, dass sich dies später ändert. Für jetzt immer 1.
• parallelism: Wenn eine Packdatei erstellt werden muss, legt diese Variable die Anzahl der Arbeits-Threads fest, die vom Packbuilder gestartet werden. Wenn 0, wird der Packbuilder die Anzahl der zu verwendenden Threads automatisch festlegen. Der Standardwert ist 1.
• callbacks: die Rückruffunktionen (z. B. für die Authentifizierung mit dem Remote), die für den Push verwendet werden sollen.
• proxy_opts: nur relevant, wenn die LibGit2-Version größer oder gleich 0.25.0 ist. Legt Optionen für die Verwendung eines Proxys zur Kommunikation mit einem Remote fest. Siehe ProxyOptions für weitere Informationen.
• custom_headers: nur relevant, wenn die LibGit2-Version größer oder gleich 0.24.0 ist. Zusätzliche Header, die für den Push-Vorgang benötigt werden.

LibGit2.RebaseOperation

Beschreibt eine einzelne Anweisung/Operation, die während des Rebase ausgeführt werden soll. Entspricht der git_rebase_operation Struktur.

Die Felder repräsentieren:

• optype: der Typ der Rebase-Operation, die derzeit ausgeführt wird. Die Optionen sind:

  • REBASE_OPERATION_PICK: den betreffenden Commit cherry-picken.
  • REBASE_OPERATION_REWORD: den betreffenden Commit cherry-picken, aber seine Nachricht mit dem Prompt umschreiben.
  • REBASE_OPERATION_EDIT: den betreffenden Commit cherry-picken, aber dem Benutzer erlauben, den Inhalt des Commits und seine Nachricht zu bearbeiten.
  • REBASE_OPERATION_SQUASH: den betreffenden Commit in den vorherigen Commit squashen. Die Commit-Nachrichten der beiden Commits werden zusammengeführt.
  • REBASE_OPERATION_FIXUP: den betreffenden Commit in den vorherigen Commit squashen. Nur die Commit-Nachricht des vorherigen Commits wird verwendet.
  • REBASE_OPERATION_EXEC: keinen Commit cherry-picken. Führen Sie einen Befehl aus und fahren Sie fort, wenn der Befehl erfolgreich beendet wird.

• id: der GitHash des Commits, an dem während dieses Rebase-Schrittes gearbeitet wird.

• exec: falls REBASE_OPERATION_EXEC verwendet wird, der Befehl, der während dieses Schrittes ausgeführt werden soll (zum Beispiel das Test-Suite nach jedem Commit ausführen).

LibGit2.RebaseOptions

Entspricht der git_rebase_options-Struktur.

Die Felder repräsentieren:

• version: Version der verwendeten Struktur, für den Fall, dass sich dies später ändert. Für jetzt immer 1.
• quiet: Informiert andere Git-Clients, die bei der Rebase helfen oder daran arbeiten, dass die Rebase "leise" durchgeführt werden soll. Wird für die Interoperabilität verwendet. Der Standardwert ist 1.
• inmemory: Startet eine In-Memory-Rebase. Aufrufer, die an der Rebase arbeiten, können die Schritte durchlaufen und Änderungen committen, aber HEAD nicht zurücksetzen oder das Repository aktualisieren. Das workdir wird nicht modifiziert. Nur vorhanden in libgit2-Versionen, die neuer oder gleich 0.24.0 sind.
• rewrite_notes_ref: Name des Verweises auf Notizen, die verwendet werden, um die Commit-Notizen beim Abschluss der Rebase umzuschreiben.
• merge_opts: Merge-Optionen, die steuern, wie die Bäume bei jedem Rebase-Schritt zusammengeführt werden. Nur vorhanden in libgit2-Versionen, die neuer oder gleich 0.24.0 sind.
• checkout_opts: Checkout-Optionen zum Schreiben von Dateien beim Initialisieren der Rebase, beim Durchlaufen und beim Abbrechen. Siehe CheckoutOptions für weitere Informationen.

LibGit2.RemoteCallbacks

Callback-Einstellungen. Entspricht der git_remote_callbacks Struktur.

LibGit2.SignatureStruct

Eine Aktionssignatur (z. B. für Committer, Tagger usw.). Entspricht der git_signature Struktur.

Die Felder repräsentieren:

• name: Der vollständige Name des Committers oder Autors des Commits.
• email: Die E-Mail-Adresse, unter der der Committer/Autor kontaktiert werden kann.
• when: eine TimeStruct, die angibt, wann der Commit in das Repository verfasst/committed wurde.

LibGit2.StatusEntry

Bereitstellung der Unterschiede zwischen der Datei, wie sie in HEAD existiert, und dem Index, sowie der Unterschiede zwischen dem Index und dem Arbeitsverzeichnis. Entspricht der Struktur git_status_entry.

Die Felder repräsentieren:

• status: enthält die Statusflags für die Datei, die angeben, ob sie aktuell ist oder in irgendeiner Weise im Index oder Arbeitsbaum geändert wurde.
• head_to_index: ein Zeiger auf ein DiffDelta, das die Unterschiede zwischen der Datei, wie sie in HEAD existiert, und im Index kapselt.
• index_to_workdir: ein Zeiger auf ein DiffDelta, das die Unterschiede zwischen der Datei, wie sie im Index existiert, und im workdir kapselt.

LibGit2.StatusOptions

Optionen zur Steuerung, wie git_status_foreach_ext() Rückrufe ausführt. Entspricht der git_status_opt_t Struktur.

Die Felder repräsentieren:

• version: Version der verwendeten Struktur, für den Fall, dass sich dies später ändert. Zurzeit immer 1.
• show: ein Flag, für welche Dateien untersucht werden sollen und in welcher Reihenfolge. Der Standardwert ist Consts.STATUS_SHOW_INDEX_AND_WORKDIR.
• flags: Flags zur Steuerung von Rückrufen, die in einem Statusaufruf verwendet werden.
• pathspec: ein Array von Pfaden, die für die Pfadübereinstimmung verwendet werden sollen. Das Verhalten der Pfadübereinstimmung variiert je nach den Werten von show und flags.
• Der baseline ist der Baum, der für den Vergleich mit dem Arbeitsverzeichnis und dem Index verwendet wird; standardmäßig HEAD.

LibGit2.StrArrayStruct

Eine LibGit2-Darstellung eines Arrays von Zeichenfolgen. Entspricht der git_strarray Struktur.

Beim Abrufen von Daten aus LibGit2 würde eine typische Verwendung wie folgt aussehen:

sa_ref = Ref(StrArrayStruct())
@check ccall(..., (Ptr{StrArrayStruct},), sa_ref)
res = convert(Vector{String}, sa_ref[])
free(sa_ref)

Insbesondere ist zu beachten, dass LibGit2.free anschließend auf dem Ref-Objekt aufgerufen werden sollte.

Umgekehrt ist es beim Übergeben eines Vektors von Zeichenfolgen an LibGit2 im Allgemeinen am einfachsten, sich auf die implizite Konvertierung zu verlassen:

strs = String[...]
@check ccall(..., (Ptr{StrArrayStruct},), strs)

Beachten Sie, dass kein Aufruf von free erforderlich ist, da die Daten von Julia zugewiesen werden.

LibGit2.TimeStruct

Zeit in einer Signatur. Entspricht der git_time Struktur.

addfile(cfg::GitConfig, path::AbstractString,
        level::Consts.GIT_CONFIG=Consts.CONFIG_LEVEL_APP,
        repo::Union{GitRepo, Nothing} = nothing,
        force::Bool=false)

Fügen Sie eine vorhandene Git-Konfigurationsdatei, die sich unter path befindet, zur aktuellen GitConfig cfg hinzu. Wenn die Datei nicht existiert, wird sie erstellt.

• level legt die Prioritätsstufe der Git-Konfiguration fest und wird durch

Consts.GIT_CONFIG bestimmt.

• repo ist ein optionales Repository, um das Parsen von bedingten Includes zu ermöglichen.
• Wenn force false ist und eine Konfiguration für die gegebene Prioritätsstufe bereits existiert,

wird addfile einen Fehler auslösen. Wenn force true ist, wird die vorhandene Konfiguration durch die im Datei unter path ersetzt.

add!(repo::GitRepo, files::AbstractString...; flags::Cuint = Consts.INDEX_ADD_DEFAULT)
add!(idx::GitIndex, files::AbstractString...; flags::Cuint = Consts.INDEX_ADD_DEFAULT)

Fügen Sie alle Dateien mit den in files angegebenen Pfaden zum Index idx (oder dem Index des repo) hinzu. Wenn die Datei bereits vorhanden ist, wird der Indexeintrag aktualisiert. Wenn die Datei noch nicht vorhanden ist, wird sie neu in den Index aufgenommen. files kann Platzhalter enthalten, die erweitert werden, und alle übereinstimmenden Dateien werden hinzugefügt (es sei denn, INDEX_ADD_DISABLE_PATHSPEC_MATCH ist gesetzt, siehe unten). Wenn eine Datei ignoriert wurde (in .gitignore oder in der Konfiguration), wird sie nicht hinzugefügt, es sei denn, sie wird bereits im Index verfolgt, in diesem Fall wird sie aktualisiert. Das Schlüsselwortargument flags ist eine Menge von Bit-Flags, die das Verhalten in Bezug auf ignorierte Dateien steuern:

• Consts.INDEX_ADD_DEFAULT - Standard, oben beschrieben.
• Consts.INDEX_ADD_FORCE - ignoriert die bestehenden Ignorierregeln und erzwingt die Hinzufügung der Datei zum Index, auch wenn sie bereits ignoriert wird.
• Consts.INDEX_ADD_CHECK_PATHSPEC - kann nicht gleichzeitig mit INDEX_ADD_FORCE verwendet werden. Überprüfen Sie, dass jede Datei in files, die auf der Festplatte vorhanden ist, nicht in der Ignorierliste ist. Wenn eine der Dateien ignoriert wird, gibt die Funktion EINVALIDSPEC zurück.
• Consts.INDEX_ADD_DISABLE_PATHSPEC_MATCH - deaktiviert die Platzhalterübereinstimmung und fügt nur Dateien zum Index hinzu, die genau mit den in files angegebenen Pfaden übereinstimmen.

add_fetch!(repo::GitRepo, rmt::GitRemote, fetch_spec::String)

Fügen Sie eine fetch refspec für das angegebene rmt hinzu. Diese refspec enthält Informationen darüber, von welchem(e) Branch(es) abgerufen werden soll.

Beispiele

julia> LibGit2.add_fetch!(repo, remote, "upstream");

julia> LibGit2.fetch_refspecs(remote)
String["+refs/heads/*:refs/remotes/upstream/*"]

add_push!(repo::GitRepo, rmt::GitRemote, push_spec::String)

Fügen Sie eine push refspec für das angegebene rmt hinzu. Diese refspec enthält Informationen darüber, welche(n) Branch(es) gepusht werden sollen.

Beispiele

julia> LibGit2.add_push!(repo, remote, "refs/heads/master");

julia> remote = LibGit2.get(LibGit2.GitRemote, repo, branch);

julia> LibGit2.push_refspecs(remote)
String["refs/heads/master"]

!!! Hinweis Möglicherweise müssen Sie close aufrufen und das betreffende GitRemote nach der Aktualisierung seiner Push-refspecs erneut öffnen, damit die Änderung wirksam wird und Aufrufe von push funktionieren.

LibGit2.addblob!(repo::GitRepo, path::AbstractString)

Liest die Datei unter path und fügt sie als loses Blob zur Objektdatenbank von repo hinzu. Gibt den GitHash des resultierenden Blobs zurück.

Beispiele

hash_str = string(commit_oid)
blob_file = joinpath(repo_path, ".git", "objects", hash_str[1:2], hash_str[3:end])
id = LibGit2.addblob!(repo, blob_file)

author(c::GitCommit)

Gibt die Signature des Autors des Commits c zurück. Der Autor ist die Person, die Änderungen an der betreffenden Datei(en) vorgenommen hat. Siehe auch committer.

authors(repo::GitRepo) -> Vector{Signature}

Gibt alle Autoren von Commits im repo Repository zurück.

Beispiele

repo = LibGit2.GitRepo(repo_path)
repo_file = open(joinpath(repo_path, test_file), "a")

println(repo_file, commit_msg)
flush(repo_file)
LibGit2.add!(repo, test_file)
sig = LibGit2.Signature("TEST", "TEST@TEST.COM", round(time(), 0), 0)
commit_oid1 = LibGit2.commit(repo, "commit1"; author=sig, committer=sig)
println(repo_file, randstring(10))
flush(repo_file)
LibGit2.add!(repo, test_file)
commit_oid2 = LibGit2.commit(repo, "commit2"; author=sig, committer=sig)

# wird ein Vector von [sig, sig] sein
auths = LibGit2.authors(repo)

branch(repo::GitRepo)

Entspricht git branch. Erstellt einen neuen Branch vom aktuellen HEAD.

branch!(repo::GitRepo, branch_name::AbstractString, commit::AbstractString=""; kwargs...)

Wechseln Sie zu einem neuen Git-Zweig im repo-Repository. commit ist der GitHash, in Form eines Strings, der den Start des neuen Zweigs darstellt. Wenn commit ein leerer String ist, wird der aktuelle HEAD verwendet.

Die Schlüsselwortargumente sind:

• track::AbstractString="": der Name des Remote-Zweigs, den dieser neue Zweig verfolgen soll, falls vorhanden. Wenn leer (der Standard), wird kein Remote-Zweig verfolgt.
• force::Bool=false: wenn true, wird die Erstellung des Zweigs erzwungen.
• set_head::Bool=true: wenn true, wird nach Abschluss der Erstellung des Zweigs der Zweigkopf als HEAD von repo gesetzt.

Entspricht git checkout [-b|-B] <branch_name> [<commit>] [--track <track>].

Beispiele

repo = LibGit2.GitRepo(repo_path)
LibGit2.branch!(repo, "new_branch", set_head=false)

checkout!(repo::GitRepo, commit::AbstractString=""; force::Bool=true)

Entspricht git checkout [-f] --detach <commit>. Wechselt zu dem git-Commit commit (ein GitHash in String-Form) in repo. Wenn force true ist, wird der Checkout erzwungen und alle aktuellen Änderungen verworfen. Beachten Sie, dass dies den aktuellen HEAD abtrennt.

Beispiele

repo = LibGit2.GitRepo(repo_path)
open(joinpath(LibGit2.path(repo), "file1"), "w") do f
    write(f, "111
")
end
LibGit2.add!(repo, "file1")
commit_oid = LibGit2.commit(repo, "add file1")
open(joinpath(LibGit2.path(repo), "file1"), "w") do f
    write(f, "112
")
end
# würde ohne force=true fehlschlagen
# da es Änderungen an der Datei gibt
LibGit2.checkout!(repo, string(commit_oid), force=true)

clone(repo_url::AbstractString, repo_path::AbstractString, clone_opts::CloneOptions)

Klonen Sie das Remote-Repository unter repo_url (das eine Remote-URL oder einen Pfad im lokalen Dateisystem sein kann) nach repo_path (das ein Pfad im lokalen Dateisystem sein muss). Optionen für den Klon, wie z.B. ob ein Bare-Klon durchgeführt werden soll oder nicht, werden durch CloneOptions festgelegt.

Beispiele

repo_url = "https://github.com/JuliaLang/Example.jl"
repo = LibGit2.clone(repo_url, "/home/me/projects/Example")

clone(repo_url::AbstractString, repo_path::AbstractString; kwargs...)

Klonen Sie ein entferntes Repository, das sich unter repo_url befindet, in den lokalen Dateispeicherort repo_path.

Die Schlüsselwortargumente sind:

• branch::AbstractString="": welcher Branch des Remotes geklont werden soll, wenn nicht der Standard-Repository-Branch (normalerweise master).
• isbare::Bool=false: wenn true, klonen Sie das Remote als ein Bare-Repository, was bedeutet, dass repo_path selbst das Git-Verzeichnis anstelle von repo_path/.git sein wird. Das bedeutet, dass kein Arbeitsbaum ausgecheckt werden kann. Spielt die Rolle des Git-CLI-Arguments --bare.
• remote_cb::Ptr{Cvoid}=C_NULL: ein Callback, das verwendet wird, um das Remote zu erstellen, bevor es geklont wird. Wenn C_NULL (der Standard), wird kein Versuch unternommen, das Remote zu erstellen - es wird angenommen, dass es bereits existiert.
• credentials::Creds=nothing: bietet Anmeldeinformationen und/oder Einstellungen beim Authentifizieren gegen ein privates Repository.
• callbacks::Callbacks=Callbacks(): vom Benutzer bereitgestellte Callbacks und Payloads.

Entspricht git clone [-b <branch>] [--bare] <repo_url> <repo_path>.

Beispiele

repo_url = "https://github.com/JuliaLang/Example.jl"
repo1 = LibGit2.clone(repo_url, "test_path")
repo2 = LibGit2.clone(repo_url, "test_path", isbare=true)
julia_url = "https://github.com/JuliaLang/julia"
julia_repo = LibGit2.clone(julia_url, "julia_path", branch="release-0.6")

commit(repo::GitRepo, msg::AbstractString; kwargs...) -> GitHash

Wrapper um git_commit_create. Erstelle einen Commit im Repository repo. msg ist die Commit-Nachricht. Gibt die OID des neuen Commits zurück.

Die Schlüsselwortargumente sind:

• refname::AbstractString=Consts.HEAD_FILE: wenn nicht NULL, der Name der Referenz, die aktualisiert werden soll, um auf den neuen Commit zu zeigen. Zum Beispiel wird "HEAD" den HEAD des aktuellen Branches aktualisieren. Wenn die Referenz noch nicht existiert, wird sie erstellt.
• author::Signature = Signature(repo) ist eine Signature, die Informationen über die Person enthält, die den Commit verfasst hat.
• committer::Signature = Signature(repo) ist eine Signature, die Informationen über die Person enthält, die den Commit im Repository vorgenommen hat. Nicht unbedingt die gleiche wie author, zum Beispiel, wenn author einen Patch an committer gesendet hat, der ihn dann committed hat.
• tree_id::GitHash = GitHash() ist ein Git-Baum, der verwendet wird, um den Commit zu erstellen, und zeigt seine Abstammung und Beziehung zu anderer Historie. tree muss zu repo gehören.
• parent_ids::Vector{GitHash}=GitHash[] ist eine Liste von Commits von GitHash, die als Eltern-Commits für den neuen verwendet werden sollen, und kann leer sein. Ein Commit kann mehrere Eltern haben, wenn es sich beispielsweise um einen Merge-Commit handelt.

LibGit2.commit(rb::GitRebase, sig::GitSignature)

Übertrage den aktuellen Patch auf das Rebase rb, wobei sig als Committer verwendet wird. Ist still, wenn der Commit bereits angewendet wurde.

committer(c::GitCommit)

Gibt die Signature des Committers des Commits c zurück. Der Committer ist die Person, die die Änderungen ursprünglich, die vom author verfasst wurden, committet hat, muss jedoch nicht die gleiche Person wie der author sein, zum Beispiel, wenn der author einen Patch an einen committer gesendet hat, der ihn dann committet hat.

LibGit2.count(f::Function, walker::GitRevWalker; oid::GitHash=GitHash(), by::Cint=Consts.SORT_NONE, rev::Bool=false)

Verwenden Sie den GitRevWalker walker, um über jeden Commit in der Historie des Repositories zu "gehen", und finden Sie die Anzahl der Commits, die true zurückgeben, wenn f auf sie angewendet wird. Die Schlüsselwortargumente sind: * oid: Der GitHash des Commits, von dem aus der Walk beginnen soll. Der Standardwert ist die Verwendung von push_head! und damit des HEAD-Commits und aller seiner Vorfahren. * by: Die Sortiermethode. Der Standardwert ist, nicht zu sortieren. Weitere Optionen sind, nach Topologie (LibGit2.Consts.SORT_TOPOLOGICAL) zu sortieren, vorwärts in der Zeit (LibGit2.Consts.SORT_TIME, die ältesten zuerst) oder rückwärts in der Zeit (LibGit2.Consts.SORT_REVERSE, die aktuellsten zuerst) zu sortieren. * rev: Ob die sortierte Reihenfolge umgekehrt werden soll (zum Beispiel, wenn die topologische Sortierung verwendet wird).

Beispiele

cnt = LibGit2.with(LibGit2.GitRevWalker(repo)) do walker
    LibGit2.count((oid, repo)->(oid == commit_oid1), walker, oid=commit_oid1, by=LibGit2.Consts.SORT_TIME)
end

LibGit2.count findet die Anzahl der Commits entlang des Walks mit einem bestimmten GitHash commit_oid1, wobei der Walk von diesem Commit aus beginnt und vorwärts in der Zeit von ihm aus geht. Da der GitHash einzigartig für einen Commit ist, wird cnt 1 sein.

counthunks(blame::GitBlame)

Gibt die Anzahl der unterschiedlichen "Hunks" mit einer Datei zurück. Ein Hunk kann mehrere Zeilen enthalten. Ein Hunk ist normalerweise ein Teil einer Datei, der zusammen hinzugefügt/geändert/entfernt wurde, zum Beispiel eine Funktion, die zu einer Quelldatei hinzugefügt wurde, oder eine innere Schleife, die später aus dieser Funktion optimiert wurde.

LibGit2.create_branch(repo::GitRepo, bname::AbstractString, commit_obj::GitCommit; force::Bool=false)

Erstellt einen neuen Branch im Repository repo mit dem Namen bname, der auf den Commit commit_obj zeigt (der Teil von repo sein muss). Wenn force true ist, wird ein vorhandener Branch mit dem Namen bname überschrieben, falls er existiert. Wenn force false ist und bereits ein Branch mit dem Namen bname existiert, wird diese Funktion einen Fehler auslösen.

credential_callback(...) -> Cint

Eine LibGit2-Anmeldeinformationen-Callback-Funktion, die unterschiedliche Funktionen zur Beschaffung von Anmeldeinformationen in Bezug auf ein Verbindungsprotokoll bereitstellt. Der payload_ptr muss ein LibGit2.CredentialPayload-Objekt enthalten, das den Zustand und die Einstellungen verfolgt.

Die allowed_types enthält eine Bitmaske von LibGit2.Consts.GIT_CREDTYPE-Werten, die angeben, welche Authentifizierungsmethoden versucht werden sollen.

Die Authentifizierung der Anmeldeinformationen erfolgt in der folgenden Reihenfolge (sofern unterstützt):

• SSH-Agent
• SSH-Privat-/Öffenschlüssel-Paar
• Benutzername/Passwort im Klartext

Wenn ein Benutzer mit einer Eingabeaufforderung für Anmeldeinformationen konfrontiert wird, kann er die Eingabeaufforderung abbrechen, indem er ^D eingibt (die Steuerungstaste zusammen mit der d-Taste drückt).

Hinweis: Aufgrund der Besonderheiten des Authentifizierungsverfahrens von libgit2 wird diese Funktion erneut aufgerufen, wenn die Authentifizierung fehlschlägt, ohne dass angezeigt wird, ob die Authentifizierung erfolgreich war oder nicht. Um eine Endlosschleife zu vermeiden, die durch die wiederholte Verwendung der gleichen fehlerhaften Anmeldeinformationen verursacht wird, werden wir den Zustand mithilfe des Payloads verfolgen.

Für weitere Details siehe den LibGit2-Leitfaden zum Authentifizieren gegen einen Server.

C-Funktionszeiger für credentials_callback

Geben Sie das Signaturobjekt zurück. Befreien Sie es nach der Verwendung.

LibGit2.delete_branch(branch::GitReference)

Löschen Sie den Branch, auf den branch zeigt.

diff_files(repo::GitRepo, branch1::AbstractString, branch2::AbstractString; kwarg...) -> Vector{AbstractString}

Zeigt an, welche Dateien im Git-Repository repo zwischen den Branches branch1 und branch2 geändert wurden.

Das Schlüsselwort-Argument ist:

• filter::Set{Consts.DELTA_STATUS}=Set([Consts.DELTA_ADDED, Consts.DELTA_MODIFIED, Consts.DELTA_DELETED])), und es legt Optionen für den Diff fest. Der Standardwert zeigt hinzugefügte, geänderte oder gelöschte Dateien an.

Gibt nur die Namen der Dateien zurück, die sich geändert haben, nicht deren Inhalte.

Beispiele

LibGit2.branch!(repo, "branch/a")
LibGit2.branch!(repo, "branch/b")
# füge eine Datei zum Repo hinzu
open(joinpath(LibGit2.path(repo),"file"),"w") do f
    write(f, "hello repo
")
end
LibGit2.add!(repo, "file")
LibGit2.commit(repo, "add file")
# gibt ["file"] zurück
filt = Set([LibGit2.Consts.DELTA_ADDED])
files = LibGit2.diff_files(repo, "branch/a", "branch/b", filter=filt)
# gibt [] zurück, weil bestehende Dateien nicht geändert wurden
filt = Set([LibGit2.Consts.DELTA_MODIFIED])
files = LibGit2.diff_files(repo, "branch/a", "branch/b", filter=filt)

Entspricht git diff --name-only --diff-filter=<filter> <branch1> <branch2>.

entryid(te::GitTreeEntry)

Gibt den GitHash des Objekts zurück, auf das te verweist.

entrytype(te::GitTreeEntry)

Gibt den Typ des Objekts zurück, auf das te verweist. Das Ergebnis wird einer der Typen sein, die objtype zurückgibt, z. B. ein GitTree oder GitBlob.

fetch(rmt::GitRemote, refspecs; options::FetchOptions=FetchOptions(), msg="")

Holen Sie von dem angegebenen rmt Remote-Git-Repository ab, wobei refspecs verwendet wird, um zu bestimmen, welche Remote-Branch(es) abgerufen werden sollen. Die Schlüsselwortargumente sind:

• options: bestimmt die Optionen für den Abruf, z. B. ob danach bereinigt werden soll. Siehe FetchOptions für weitere Informationen.
• msg: eine Nachricht, die in die Reflogs eingefügt werden soll.

fetch(repo::GitRepo; kwargs...)

Holt Updates von einem Upstream des Repositories repo.

Die Schlüsselwortargumente sind:

• remote::AbstractString="origin": welcher Remote, angegeben durch den Namen, von repo abgerufen werden soll. Wenn dies leer ist, wird die URL verwendet, um einen anonymen Remote zu erstellen.
• remoteurl::AbstractString="": die URL von remote. Wenn nicht angegeben, wird sie basierend auf dem gegebenen Namen von remote angenommen.
• refspecs=AbstractString[]: bestimmt die Eigenschaften des Abrufs.
• credentials=nothing: bietet Anmeldeinformationen und/oder Einstellungen beim Authentifizieren gegen einen privaten remote.
• callbacks=Callbacks(): vom Benutzer bereitgestellte Rückrufe und Payloads.

Entspricht git fetch [<remoteurl>|<repo>] [<refspecs>].

fetchheads(repo::GitRepo) -> Vector{FetchHead}

Gibt die Liste aller Fetch-Head für repo zurück, wobei jeder als FetchHead dargestellt wird, einschließlich ihrer Namen, URLs und Merge-Status.

Beispiele

julia> fetch_heads = LibGit2.fetchheads(repo);

julia> fetch_heads[1].name
"refs/heads/master"

julia> fetch_heads[1].ismerge
true

julia> fetch_heads[2].name
"refs/heads/test_branch"

julia> fetch_heads[2].ismerge
false

fetch_refspecs(rmt::GitRemote) -> Vector{String}

Holen Sie sich die fetch refspecs für das angegebene rmt. Diese refspecs enthalten Informationen darüber, von welchem Branch(es) abgerufen werden soll.

Beispiele

julia> remote = LibGit2.get(LibGit2.GitRemote, repo, "upstream");

julia> LibGit2.add_fetch!(repo, remote, "upstream");

julia> LibGit2.fetch_refspecs(remote)
String["+refs/heads/*:refs/remotes/upstream/*"]

C-Funktionszeiger für fetchhead_foreach_callback

merge_base(repo::GitRepo, one::AbstractString, two::AbstractString) -> GitHash

Finde einen Merge-Basis (einen gemeinsamen Vorfahren) zwischen den Commits one und two. one und two können beide in String-Form vorliegen. Gib den GitHash der Merge-Basis zurück.

merge!(repo::GitRepo; kwargs...) -> Bool

Führen Sie einen Git-Merge im Repository repo durch, indem Sie Commits mit divergierender Historie in den aktuellen Branch zusammenführen. Gibt true zurück, wenn der Merge erfolgreich war, andernfalls false.

Die Schlüsselwortargumente sind:

• committish::AbstractString="": Führen Sie die benannten Commits in committish zusammen.
• branch::AbstractString="": Führen Sie den Branch branch und alle seine Commits seit der Divergenz vom aktuellen Branch zusammen.
• fastforward::Bool=false: Wenn fastforward true ist, führen Sie nur zusammen, wenn der Merge ein Fast-Forward ist (der aktuelle Branch-Kopf ist ein Vorfahre der zusammenzuführenden Commits), andernfalls verweigern Sie den Merge und geben false zurück. Dies entspricht der Git-CLI-Option --ff-only.
• merge_opts::MergeOptions=MergeOptions(): merge_opts gibt Optionen für den Merge an, wie z.B. die Merge-Strategie im Falle von Konflikten.
• checkout_opts::CheckoutOptions=CheckoutOptions(): checkout_opts gibt Optionen für den Checkout-Schritt an.

Entspricht git merge [--ff-only] [<committish> | <branch>].

!!! Hinweis Wenn Sie einen branch angeben, muss dies im Referenzformat erfolgen, da der String in eine GitReference umgewandelt wird. Wenn Sie beispielsweise den Branch branch_a zusammenführen möchten, würden Sie merge!(repo, branch="refs/heads/branch_a") aufrufen.

merge!(repo::GitRepo, anns::Vector{GitAnnotated}; kwargs...) -> Bool

Mergen Sie Änderungen aus den annotierten Commits (erfasst als GitAnnotated Objekte) anns in den HEAD des Repositories repo. Die Schlüsselwortargumente sind:

• merge_opts::MergeOptions = MergeOptions(): Optionen, wie das Mergen durchgeführt werden soll, einschließlich ob Fast-Forwarding erlaubt ist. Siehe MergeOptions für weitere Informationen.
• checkout_opts::CheckoutOptions = CheckoutOptions(): Optionen, wie der Checkout durchgeführt werden soll. Siehe CheckoutOptions für weitere Informationen.

anns kann sich auf entfernte oder lokale Branch-Köpfe beziehen. Gibt true zurück, wenn das Mergen erfolgreich ist, andernfalls false (zum Beispiel, wenn kein Mergen möglich ist, weil die Branches keinen gemeinsamen Vorfahren haben).

Beispiele

upst_ann = LibGit2.GitAnnotated(repo, "branch/a")

# den Branch mergen
LibGit2.merge!(repo, [upst_ann])

merge!(repo::GitRepo, anns::Vector{GitAnnotated}, fastforward::Bool; kwargs...) -> Bool

Mergen Sie Änderungen aus den annotierten Commits (erfasst als GitAnnotated Objekte) anns in den HEAD des Repositories repo. Wenn fastforward true ist, ist nur ein Fast-Forward-Merge erlaubt. In diesem Fall schlägt der Merge fehl, wenn Konflikte auftreten. Andernfalls, wenn fastforward false ist, kann der Merge eine Konfliktdatei erzeugen, die der Benutzer lösen muss.

Die Schlüsselwortargumente sind:

• merge_opts::MergeOptions = MergeOptions(): Optionen für die Durchführung des Merges, einschließlich ob Fast-Forwarding erlaubt ist. Siehe MergeOptions für weitere Informationen.
• checkout_opts::CheckoutOptions = CheckoutOptions(): Optionen für die Durchführung des Checkouts. Siehe CheckoutOptions für weitere Informationen.

anns kann sich auf lokale oder entfernte Branch-Köpfe beziehen. Gibt true zurück, wenn der Merge erfolgreich ist, andernfalls false (zum Beispiel, wenn kein Merge möglich ist, weil die Branches keinen gemeinsamen Vorfahren haben).

Beispiele

upst_ann_1 = LibGit2.GitAnnotated(repo, "branch/a")

# merge den Branch ein, fastforward
LibGit2.merge!(repo, [upst_ann_1], true)

# Merge-Konflikte!
upst_ann_2 = LibGit2.GitAnnotated(repo, "branch/b")
# merge den Branch ein, versuche fastforward
LibGit2.merge!(repo, [upst_ann_2], true) # wird false zurückgeben
LibGit2.merge!(repo, [upst_ann_2], false) # wird true zurückgeben

ffmerge!(repo::GitRepo, ann::GitAnnotated)

Schnellvorlauf-Merge-Änderungen in den aktuellen HEAD. Dies ist nur möglich, wenn der Commit, auf den sich ann bezieht, von dem aktuellen HEAD abstammt (z. B. wenn Änderungen von einem Remote-Branch abgerufen werden, der einfach vor der Spitze des lokalen Branches liegt).

LibGit2.fullname(ref::GitReference)

Gibt den Namen der Referenz zurück, auf die die symbolische Referenz ref zeigt. Wenn ref keine symbolische Referenz ist, wird ein leerer String zurückgegeben.

features()

Gibt eine Liste der Git-Funktionen zurück, die die aktuelle Version von libgit2 unterstützt, wie z.B. Multithreading oder die Verwendung von HTTPS oder SSH.

filename(te::GitTreeEntry)

Gibt den Dateinamen des Objekts auf der Festplatte zurück, auf das te verweist.

filemode(te::GitTreeEntry) -> Cint

Gibt den UNIX-Dateimodus des Objekts auf der Festplatte zurück, auf das te als Ganzzahl verweist.

LibGit2.gitdir(repo::GitRepo)

Gibt den Speicherort der "git"-Dateien von repo zurück:

• für normale Repositories ist dies der Speicherort des .git-Ordners.
• für bare Repositories ist dies der Speicherort des Repositories selbst.

Siehe auch workdir, path.

LibGit2.git_url(; kwargs...) -> String

Erstellt eine Zeichenkette basierend auf den bereitgestellten URL-Komponenten. Wenn das Schlüsselwort scheme nicht angegeben ist, wird die produzierte URL die alternative scp-ähnliche Syntax verwenden.

Schlüsselwörter

• scheme::AbstractString="": das URL-Schema, das das zu verwendende Protokoll identifiziert. Für HTTP verwenden Sie "http", für SSH "ssh" usw. Wenn scheme nicht angegeben ist, wird das Ausgabeformat "ssh" sein, jedoch unter Verwendung der scp-ähnlichen Syntax.
• username::AbstractString="": der Benutzername, der in der Ausgabe verwendet werden soll, falls angegeben.
• password::AbstractString="": das Passwort, das in der Ausgabe verwendet werden soll, falls angegeben.
• host::AbstractString="": der Hostname, der in der Ausgabe verwendet werden soll. Ein Hostname muss angegeben werden.
• port::Union{AbstractString,Integer}="": die Portnummer, die in der Ausgabe verwendet werden soll, falls angegeben. Kann nicht angegeben werden, wenn die scp-ähnliche Syntax verwendet wird.
• path::AbstractString="": der Pfad, der in der Ausgabe verwendet werden soll, falls angegeben.

Beispiele

julia> LibGit2.git_url(username="git", host="github.com", path="JuliaLang/julia.git")
"git@github.com:JuliaLang/julia.git"

julia> LibGit2.git_url(scheme="https", host="github.com", path="/JuliaLang/julia.git")
"https://github.com/JuliaLang/julia.git"

julia> LibGit2.git_url(scheme="ssh", username="git", host="github.com", port=2222, path="JuliaLang/julia.git")
"ssh://git@github.com:2222/JuliaLang/julia.git"

@githash_str -> AbstractGitHash

Konstruiere ein Git-Hash-Objekt aus dem gegebenen String und gebe einen GitShortHash zurück, wenn der String kürzer als 40 hexadezimale Ziffern ist, andernfalls einen GitHash.

Beispiele

julia> LibGit2.githash"d114feb74ce633"
GitShortHash("d114feb74ce633")

julia> LibGit2.githash"d114feb74ce63307afe878a5228ad014e0289a85"
GitHash("d114feb74ce63307afe878a5228ad014e0289a85")

LibGit2.head(repo::GitRepo) -> GitReference

Gibt ein GitReference auf den aktuellen HEAD von repo zurück.

head(pkg::AbstractString) -> String

Gibt den aktuellen HEAD GitHash des pkg Repos als String zurück.

LibGit2.head!(repo::GitRepo, ref::GitReference) -> GitReference

Setze den HEAD von repo auf das Objekt, auf das ref zeigt.

LibGit2.head_oid(repo::GitRepo) -> GitHash

Suchen Sie die Objekt-ID des aktuellen HEAD des Git-Repositorys repo.

LibGit2.headname(repo::GitRepo)

Suchen Sie den Namen des aktuellen HEAD des Git-Repositorys repo. Wenn repo derzeit abgetrennt ist, geben Sie den Namen des HEAD zurück, von dem es abgetrennt ist.

LibGit2.init(path::AbstractString, bare::Bool=false) -> GitRepo

Öffnen Sie ein neues Git-Repository unter path. Wenn bare false ist, wird der Arbeitsbaum in path/.git erstellt. Wenn bare true ist, wird kein Arbeitsverzeichnis erstellt.

is_ancestor_of(a::AbstractString, b::AbstractString, repo::GitRepo) -> Bool

Gibt true zurück, wenn a, ein GitHash in String-Form, ein Vorfahre von b, einem GitHash in String-Form, ist.

Beispiele

julia> repo = GitRepo(repo_path);

julia> LibGit2.add!(repo, test_file1);

julia> commit_oid1 = LibGit2.commit(repo, "commit1");

julia> LibGit2.add!(repo, test_file2);

julia> commit_oid2 = LibGit2.commit(repo, "commit2");

julia> LibGit2.is_ancestor_of(string(commit_oid1), string(commit_oid2), repo)
true

isbinary(blob::GitBlob) -> Bool

Verwenden Sie eine Heuristik, um zu erraten, ob eine Datei binär ist: Suchen nach NULL-Bytes und Überprüfen eines angemessenen Verhältnisses von druckbaren zu nicht druckbaren Zeichen in den ersten 8000 Bytes.

iscommit(id::AbstractString, repo::GitRepo) -> Bool

Überprüfen, ob der Commit id (der in Form eines GitHash als Zeichenkette vorliegt) im Repository vorhanden ist.

Beispiele

julia> repo = GitRepo(repo_path);

julia> LibGit2.add!(repo, test_file);

julia> commit_oid = LibGit2.commit(repo, "add test_file");

julia> LibGit2.iscommit(string(commit_oid), repo)
true

LibGit2.isdiff(repo::GitRepo, treeish::AbstractString, pathspecs::AbstractString=""; cached::Bool=false)

Überprüft, ob es Unterschiede zwischen dem durch treeish angegebenen Baum und den verfolgten Dateien im Arbeitsbaum (wenn cached=false) oder im Index (wenn cached=true) gibt. pathspecs sind die Spezifikationen für Optionen für den Diff.

Beispiele

repo = LibGit2.GitRepo(repo_path)
LibGit2.isdiff(repo, "HEAD") # sollte false sein
open(joinpath(repo_path, new_file), "a") do f
    println(f, "hier ist meine coole neue Datei")
end
LibGit2.isdiff(repo, "HEAD") # jetzt true

Entspricht git diff-index <treeish> [-- <pathspecs>].

LibGit2.isdirty(repo::GitRepo, pathspecs::AbstractString=""; cached::Bool=false) -> Bool

Überprüfen, ob es Änderungen an verfolgten Dateien im Arbeitsbaum gegeben hat (wenn cached=false) oder im Index (wenn cached=true). pathspecs sind die Spezifikationen für Optionen für den Diff.

Beispiele

repo = LibGit2.GitRepo(repo_path)
LibGit2.isdirty(repo) # sollte false sein
open(joinpath(repo_path, new_file), "a") do f
    println(f, "hier ist meine coole neue Datei")
end
LibGit2.isdirty(repo) # jetzt true
LibGit2.isdirty(repo, new_file) # jetzt true

Entspricht git diff-index HEAD [-- <pathspecs>]. ```

LibGit2.isorphan(repo::GitRepo)

Überprüfen Sie, ob der aktuelle Branch ein "verwaister" Branch ist, d.h. keine Commits hat. Der erste Commit zu diesem Branch wird keine Eltern haben.

isset(val::Integer, flag::Integer)

Überprüfen, ob die Bits von val, die durch flag indiziert sind, gesetzt (1) oder nicht gesetzt (0) sind.

iszero(id::GitHash) -> Bool

Bestimmen Sie, ob alle hexadezimalen Ziffern des gegebenen GitHash null sind.

lookup_branch(repo::GitRepo, branch_name::AbstractString, remote::Bool=false) -> Union{GitReference, Nothing}

Bestimmen Sie, ob der durch branch_name angegebene Branch im Repository repo existiert. Wenn remote true ist, wird angenommen, dass repo ein entferntes Git-Repository ist. Andernfalls ist es Teil des lokalen Dateisystems.

Geben Sie entweder eine GitReference auf den angeforderten Branch zurück, wenn er existiert, oder nothing, wenn nicht.

LibGit2.map(f::Function, walker::GitRevWalker; oid::GitHash=GitHash(), range::AbstractString="", by::Cint=Consts.SORT_NONE, rev::Bool=false)

Mit dem GitRevWalker walker, um über jeden Commit in der Historie des Repositories zu "gehen", wende f auf jeden Commit im Verlauf an. Die Schlüsselwortargumente sind: * oid: Der GitHash des Commits, von dem aus der Verlauf begonnen wird. Der Standardwert ist die Verwendung von push_head! und damit des HEAD-Commits und aller seiner Vorfahren. * range: Ein Bereich von GitHashs im Format oid1..oid2. f wird auf alle Commits zwischen den beiden angewendet. * by: Die Sortiermethode. Der Standardwert ist, nicht zu sortieren. Weitere Optionen sind, nach Topologie zu sortieren (LibGit2.Consts.SORT_TOPOLOGICAL), vorwärts in der Zeit zu sortieren (LibGit2.Consts.SORT_TIME, die ältesten zuerst) oder rückwärts in der Zeit zu sortieren (LibGit2.Consts.SORT_REVERSE, die aktuellsten zuerst). * rev: Ob die sortierte Reihenfolge umgekehrt werden soll (zum Beispiel, wenn die topologische Sortierung verwendet wird).

Beispiele

oids = LibGit2.with(LibGit2.GitRevWalker(repo)) do walker
    LibGit2.map((oid, repo)->string(oid), walker, by=LibGit2.Consts.SORT_TIME)
end

Hier besucht LibGit2.map jeden Commit mit dem GitRevWalker und findet seinen GitHash.

Spiegel-Callback-Funktion

Die Funktion setzt +refs/*:refs/* Ref-Spezifikationen und das mirror-Flag für entfernte Referenzen.

C-Funktionszeiger für mirror_callback

message(c::GitCommit, raw::Bool=false)

Gibt die Commit-Nachricht zurück, die die in Commit c vorgenommenen Änderungen beschreibt. Wenn raw false ist, wird eine leicht "bereinigte" Nachricht zurückgegeben (die alle führenden Zeilenumbrüche entfernt hat). Wenn raw true ist, wird die Nachricht nicht von solchen Zeilenumbrüchen befreit.

merge_analysis(repo::GitRepo, anns::Vector{GitAnnotated}) -> analysis, preference

Führen Sie eine Analyse der Branches durch, auf die durch die annotierten Branch-Spitzen anns verwiesen wird, und bestimmen Sie, unter welchen Umständen sie zusammengeführt werden können. Wenn beispielsweise anns[1] einfach ein Vorfahre von anns[2] ist, wird merge_analysis berichten, dass ein Fast-Forward-Merge möglich ist.

Geben Sie zwei Ausgaben zurück, analysis und preference. analysis hat mehrere mögliche Werte: * MERGE_ANALYSIS_NONE: Es ist nicht möglich, die Elemente von anns zusammenzuführen. * MERGE_ANALYSIS_NORMAL: ein regulärer Merge, wenn HEAD und die Commits, die der Benutzer zusammenführen möchte, alle von einem gemeinsamen Vorfahren abgewichen sind. In diesem Fall müssen die Änderungen gelöst werden und Konflikte können auftreten. * MERGE_ANALYSIS_UP_TO_DATE: Alle Eingabekommit, die der Benutzer zusammenführen möchte, können von HEAD erreicht werden, sodass kein Merge durchgeführt werden muss. * MERGE_ANALYSIS_FASTFORWARD: Das Eingabekommit ist ein Nachkomme von HEAD, sodass kein Merge durchgeführt werden muss - stattdessen kann der Benutzer einfach das Eingabekommit(s) auschecken. * MERGE_ANALYSIS_UNBORN: Der HEAD des Repositories verweist auf ein Commit, das nicht existiert. Es ist nicht möglich, zusammenzuführen, aber es kann möglich sein, die Eingabekommit auszuchecken. preference hat ebenfalls mehrere mögliche Werte: * MERGE_PREFERENCE_NONE: Der Benutzer hat keine Präferenz. * MERGE_PREFERENCE_NO_FASTFORWARD: Keine Fast-Forward-Merges zulassen. * MERGE_PREFERENCE_FASTFORWARD_ONLY: Nur Fast-Forward-Merges zulassen und keine andere Art (die Konflikte einführen könnte). preference kann durch die Repository- oder globale Git-Konfiguration gesteuert werden.

LibGit2.name(ref::GitReference)

Gibt den vollständigen Namen von ref zurück.

name(rmt::GitRemote)

Holen Sie sich den Namen eines Remote-Repositorys, zum Beispiel "origin". Wenn das Remote anonym ist (siehe GitRemoteAnon), ist der Name eine leere Zeichenfolge "".

Beispiele

julia> repo_url = "https://github.com/JuliaLang/Example.jl";

julia> repo = LibGit2.clone(cache_repo, "test_directory");

julia> remote = LibGit2.GitRemote(repo, "origin", repo_url);

julia> name(remote)
"origin"

LibGit2.name(tag::GitTag)

Der Name von tag (z. B. "v0.5").

need_update(repo::GitRepo)

Entspricht git update-index. Gibt true zurück, wenn repo aktualisiert werden muss.

objtype(obj_type::Consts.OBJECT)

Gibt den Typ zurück, der dem Enum-Wert entspricht.

LibGit2.path(repo::GitRepo)

Gibt den Basisdateipfad des Repositories repo zurück.

• Für normale Repositories ist dies typischerweise das übergeordnete Verzeichnis des ".git"-Verzeichnisses (Hinweis: Dies kann sich vom Arbeitsverzeichnis unterscheiden, siehe workdir für weitere Details).
• Für bare Repositories ist dies der Speicherort der "git"-Dateien.

Siehe auch gitdir, workdir.

peel([T,] ref::GitReference)

Rekursiv ref abblättern, bis ein Objekt vom Typ T erhalten wird. Wenn kein T angegeben ist, wird ref abblättern, bis ein Objekt erhalten wird, das kein GitTag ist.

• Ein GitTag wird auf das Objekt abblättern, auf das es verweist.
• Ein GitCommit wird auf einen GitTree abblättern.

peel([T,] obj::GitObject)

Rekursiv obj schälen, bis ein Objekt vom Typ T erhalten wird. Wenn kein T angegeben ist, wird obj geschält, bis sich der Typ ändert.

• Ein GitTag wird zum Objekt geschält, auf das es verweist.
• Ein GitCommit wird zu einem GitTree geschält.

LibGit2.posixpath(path)

Standardisieren Sie den Pfad-String path, um POSIX-Trennzeichen zu verwenden.

push(rmt::GitRemote, refspecs; force::Bool=false, options::PushOptions=PushOptions())

Pushen Sie in das angegebene rmt Remote-Git-Repository, wobei refspecs verwendet wird, um zu bestimmen, in welchen Remote-Branch(es) gepusht werden soll. Die Schlüsselwortargumente sind:

• force: wenn true, wird ein Force-Push durchgeführt, der Konflikte ignoriert.
• options: bestimmt die Optionen für den Push, z. B. welche Proxy-Header verwendet werden sollen. Siehe PushOptions für weitere Informationen.

push(repo::GitRepo; kwargs...)

Überträgt Updates an ein Upstream von repo.

Die Schlüsselwortargumente sind:

• remote::AbstractString="origin": der Name des Upstream-Remotes, zu dem übertragen werden soll.
• remoteurl::AbstractString="": die URL von remote.
• refspecs=AbstractString[]: bestimmt die Eigenschaften des Pushs.
• force::Bool=false: bestimmt, ob der Push ein Force-Push sein wird, der den Remote-Zweig überschreibt.
• credentials=nothing: stellt Anmeldeinformationen und/oder Einstellungen zur Verfügung, wenn gegen ein privates remote authentifiziert wird.
• callbacks=Callbacks(): vom Benutzer bereitgestellte Rückrufe und Payloads.

Entspricht git push [<remoteurl>|<repo>] [<refspecs>].

LibGit2.push!(w::GitRevWalker, cid::GitHash)

Starten Sie den GitRevWalker walker bei dem Commit cid. Diese Funktion kann verwendet werden, um eine Funktion auf alle Commits seit einem bestimmten Jahr anzuwenden, indem der erste Commit dieses Jahres als cid übergeben wird und dann das resultierende w an LibGit2.map übergeben wird.

LibGit2.push_head!(w::GitRevWalker)

Schiebt den HEAD-Commit und seine Vorfahren auf den GitRevWalker w. Dies stellt sicher, dass HEAD und alle seine Vorfahren während des Durchlaufs getroffen werden.

push_refspecs(rmt::GitRemote) -> Vector{String}

Holen Sie sich die push refspecs für das angegebene rmt. Diese refspecs enthalten Informationen darüber, welche(n) Branch(es) gepusht werden sollen.

Beispiele

julia> remote = LibGit2.get(LibGit2.GitRemote, repo, "upstream");

julia> LibGit2.add_push!(repo, remote, "refs/heads/master");

julia> close(remote);

julia> remote = LibGit2.get(LibGit2.GitRemote, repo, "upstream");

julia> LibGit2.push_refspecs(remote)
String["refs/heads/master"]

raw(id::GitHash) -> Vector{UInt8}

Erhalten Sie die rohen Bytes des GitHash als Vektor der Länge 20.

LibGit2.read_tree!(idx::GitIndex, tree::GitTree)
LibGit2.read_tree!(idx::GitIndex, treehash::AbstractGitHash)

Lese den Baum tree (oder den Baum, auf den treehash im vom idx besessenen Repository zeigt) in den Index idx. Der aktuelle Inhalt des Index wird ersetzt.

LibGit2.rebase!(repo::GitRepo, upstream::AbstractString="", newbase::AbstractString="")

Versuchen Sie einen automatischen Merge-Rebase des aktuellen Branches, von upstream, falls angegeben, oder andernfalls vom Upstream-Tracking-Branch. newbase ist der Branch, auf den rebased werden soll. Standardmäßig ist dies upstream.

Wenn Konflikte auftreten, die nicht automatisch gelöst werden können, wird der Rebase abgebrochen, und das Repository sowie der Arbeitsbaum bleiben in ihrem ursprünglichen Zustand, und die Funktion wirft einen GitError. Dies entspricht ungefähr der folgenden Befehlszeile:

git rebase --merge [<upstream>]
if [ -d ".git/rebase-merge" ]; then
    git rebase --abort
fi

LibGit2.ref_list(repo::GitRepo) -> Vector{String}

Holen Sie sich eine Liste aller Referenznamen im repo-Repository.

LibGit2.reftype(ref::GitReference) -> Cint

Gibt einen Cint zurück, der dem Typ von ref entspricht:

• 0, wenn die Referenz ungültig ist
• 1, wenn die Referenz eine Objekt-ID ist
• 2, wenn die Referenz symbolisch ist

LibGit2.remotes(repo::GitRepo)

Gibt einen Vektor der Namen der Remotes von repo zurück.

remove!(repo::GitRepo, files::AbstractString...)
remove!(idx::GitIndex, files::AbstractString...)

Entferne alle Dateien mit den durch files angegebenen Pfaden im Index idx (oder im Index des repo).

reset(val::Integer, flag::Integer)

Setze die Bits von val, die durch flag indiziert sind, zurück und gebe sie auf 0 zurück.

reset!(payload, [config]) -> CredentialPayload

Setzt den Zustand des payload auf die ursprünglichen Werte zurück, damit es innerhalb des Credential-Callbacks erneut verwendet werden kann. Wenn eine config bereitgestellt wird, wird auch die Konfiguration aktualisiert.

Aktualisiert einige Einträge, die durch die pathspecs bestimmt werden, im Index aus dem Ziel-Commit-Baum.

Setzt den aktuellen Head auf die angegebene Commit-OID und setzt optional den Index und den Arbeitsbaum zurück, um übereinzustimmen.

git reset [<committish>] [–] <pathspecs>...

reset!(repo::GitRepo, id::GitHash, mode::Cint=Consts.RESET_MIXED)

Setze das Repository repo auf seinen Zustand bei id zurück, wobei einer der drei Modi verwendet wird, die durch mode festgelegt sind:

1. Consts.RESET_SOFT - bewege HEAD zu id.
2. Consts.RESET_MIXED - Standard, bewege HEAD zu id und setze den Index auf id zurück.
3. Consts.RESET_HARD - bewege HEAD zu id, setze den Index auf id zurück und verwerfe alle Änderungen im Arbeitsverzeichnis.

Beispiele

# Änderungen abrufen
LibGit2.fetch(repo)
isfile(joinpath(repo_path, our_file)) # wird false sein

# Änderungen mit Fast-Forward zusammenführen
LibGit2.merge!(repo, fastforward=true)

# Da es lokal keine Datei gab, aber es eine
# Datei remote gibt, müssen wir den Branch zurücksetzen
head_oid = LibGit2.head_oid(repo)
new_head = LibGit2.reset!(repo, head_oid, LibGit2.Consts.RESET_HARD)

In diesem Beispiel hat das Remote, von dem abgerufen wird, eine Datei namens our_file in seinem Index, weshalb wir zurücksetzen müssen.

Entspricht git reset [--soft | --mixed | --hard] <id>.

Beispiele

repo = LibGit2.GitRepo(repo_path)
head_oid = LibGit2.head_oid(repo)
open(joinpath(repo_path, "file1"), "w") do f
    write(f, "111
")
end
LibGit2.add!(repo, "file1")
mode = LibGit2.Consts.RESET_HARD
# wird die Änderungen an file1 verwerfen
# und es unstagen
new_head = LibGit2.reset!(repo, head_oid, mode)

restore(s::State, repo::GitRepo)

Stellt ein Repository repo auf einen vorherigen State s zurück, zum Beispiel den HEAD eines Branches vor einem Merge-Versuch. s kann mit der snapshot Funktion generiert werden.

LibGit2.revcount(repo::GitRepo, commit1::AbstractString, commit2::AbstractString)

Listet die Anzahl der Revisionen zwischen commit1 und commit2 (committish OIDs in String-Form). Da commit1 und commit2 sich möglicherweise auf verschiedenen Branches befinden, führt revcount eine "links-rechts" Revisionliste (und Zählung) durch und gibt ein Tupel von Ints zurück - die Anzahl der linken und rechten Commits, jeweils. Ein linker (oder rechter) Commit bezieht sich darauf, von welcher Seite einer symmetrischen Differenz in einem Baum der Commit erreichbar ist.

Entspricht git rev-list --left-right --count <commit1> <commit2>.

Beispiele

repo = LibGit2.GitRepo(repo_path)
repo_file = open(joinpath(repo_path, test_file), "a")
println(repo_file, "hello world")
flush(repo_file)
LibGit2.add!(repo, test_file)
commit_oid1 = LibGit2.commit(repo, "commit 1")
println(repo_file, "hello world again")
flush(repo_file)
LibGit2.add!(repo, test_file)
commit_oid2 = LibGit2.commit(repo, "commit 2")
LibGit2.revcount(repo, string(commit_oid1), string(commit_oid2))

Dies wird (-1, 0) zurückgeben.

set_remote_url(repo::GitRepo, remote_name, url)
set_remote_url(repo::String, remote_name, url)

Setzen Sie sowohl die Fetch- als auch die Push-url für remote_name für das GitRepo oder das Git-Repository, das sich im path befindet. Typischerweise verwenden Git-Repos "origin" als Remote-Namen.

Beispiele

repo_path = joinpath(tempdir(), "Example")
repo = LibGit2.init(repo_path)
LibGit2.set_remote_url(repo, "upstream", "https://github.com/JuliaLang/Example.jl")
LibGit2.set_remote_url(repo_path, "upstream2", "https://github.com/JuliaLang/Example2.jl")

LibGit2.shortname(ref::GitReference)

Gibt eine verkürzte Version des Namens von ref zurück, die "menschlich lesbar" ist.

julia> repo = GitRepo(path_to_repo);

julia> branch_ref = LibGit2.head(repo);

julia> LibGit2.name(branch_ref)
"refs/heads/master"

julia> LibGit2.shortname(branch_ref)
"master"

snapshot(repo::GitRepo) -> State

Nehmen Sie einen Snapshot des aktuellen Zustands des Repositories repo, indem Sie den aktuellen HEAD, den Index und alle nicht festgeschriebenen Arbeiten speichern. Der Ausgabe State kann später während eines Aufrufs von restore verwendet werden, um das Repository in den gesnapshotteten Zustand zurückzubringen.

LibGit2.split_cfg_entry(ce::LibGit2.ConfigEntry) -> Tuple{String,String,String,String}

Zerlege den ConfigEntry in die folgenden Teile: Abschnitt, Unterabschnitt, Name und Wert.

Beispiele

Gegeben ist die Git-Konfigurationsdatei, die Folgendes enthält:

[credential "https://example.com"]
    username = me

Der ConfigEntry würde wie folgt aussehen:

julia> entry
ConfigEntry("credential.https://example.com.username", "me")

julia> LibGit2.split_cfg_entry(entry)
("credential", "https://example.com", "username", "me")

Siehe die Git-Konfigurationssyntax-Dokumentation für weitere Details. ```

LibGit2.status(repo::GitRepo, path::String) -> Union{Cuint, Cvoid}

Überprüfen Sie den Status der Datei unter path im Git-Repository repo. Zum Beispiel kann dies verwendet werden, um zu überprüfen, ob die Datei unter path geändert wurde und gestaged und committet werden muss.

stage(ie::IndexEntry) -> Cint

Holen Sie sich die Stufennummer von ie. Die Stufennummer 0 repräsentiert den aktuellen Zustand des Arbeitsbaums, aber andere Zahlen können im Falle eines Merge-Konflikts verwendet werden. In einem solchen Fall beschreiben die verschiedenen Stufennummern in einem IndexEntry, zu welcher Seite(n) des Konflikts der aktuelle Zustand der Datei gehört. Stufe 0 ist der Zustand vor dem versuchten Merge, Stufe 1 sind die Änderungen, die lokal vorgenommen wurden, Stufen 2 und höher sind für Änderungen von anderen Branches (zum Beispiel können im Falle eines Multi-Branch-"Oktopus"-Merges die Stufen 2, 3 und 4 verwendet werden).

LibGit2.tag_create(repo::GitRepo, tag::AbstractString, commit; kwargs...)

Erstellt ein neues Git-Tag tag (z. B. "v0.5") im Repository repo, beim Commit commit.

Die Schlüsselwortargumente sind:

• msg::AbstractString="": die Nachricht für das Tag.
• force::Bool=false: wenn true, werden vorhandene Referenzen überschrieben.
• sig::Signature=Signature(repo): die Signatur des Taggers.

LibGit2.tag_delete(repo::GitRepo, tag::AbstractString)

Entfernt das Git-Tag tag aus dem Repository repo.

LibGit2.tag_list(repo::GitRepo) -> Vector{String}

Holen Sie sich eine Liste aller Tags im Git-Repository repo.

LibGit2.target(tag::GitTag)

Der GitHash des Zielobjekts von tag.

toggle(val::Integer, flag::Integer)

Flippe die Bits von val, die durch flag indiziert sind, sodass ein Bit, das 0 ist, nach dem Umschalten 1 wird und umgekehrt.

transact(f::Function, repo::GitRepo)

Wenden Sie die Funktion f auf das Git-Repository repo an, indem Sie einen snapshot erstellen, bevor Sie f anwenden. Wenn ein Fehler innerhalb von f auftritt, wird repo in seinen Snapshot-Zustand zurückversetzt, indem restore verwendet wird. Der aufgetretene Fehler wird erneut ausgelöst, aber der Zustand von repo wird nicht beschädigt.

treewalk(f, tree::GitTree, post::Bool=false)

Durchlaufe die Einträge in tree und seinen Unterbäumen in post- oder pre-order. Preorder bedeutet, am Wurzelknoten zu beginnen und dann den linksseitigsten Unterbaum zu durchlaufen (und rekursiv weiter durch die linksseitigsten Unterbäume dieses Unterbaums) und sich nach rechts durch die Unterbäume zu bewegen. Postorder bedeutet, am Boden des linksseitigsten Unterbaums zu beginnen, durch ihn nach oben zu traversieren, dann den nächsten rechten Unterbaum zu durchlaufen (wiederum beginnend am Boden) und schließlich den Wurzelknoten des Baumes zuletzt zu besuchen.

Der Funktionsparameter f sollte folgende Signatur haben:

(String, GitTreeEntry) -> Cint

Ein negativer Wert, der von f zurückgegeben wird, stoppt den Baumdurchlauf. Ein positiver Wert bedeutet, dass der Eintrag übersprungen wird, wenn post false ist.

upstream(ref::GitReference) -> Union{GitReference, Nothing}

Bestimmen Sie, ob der Branch, der ref enthält, einen bestimmten Upstream-Branch hat.

Geben Sie entweder eine GitReference auf den Upstream-Branch zurück, wenn er existiert, oder nothing, wenn der angeforderte Branch keinen Upstream-Gegenpart hat.

update!(repo::GitRepo, files::AbstractString...)
update!(idx::GitIndex, files::AbstractString...)

Aktualisiere alle Dateien mit den durch files angegebenen Pfaden im Index idx (oder im Index des repo). Vergleiche den Zustand jeder Datei im Index mit dem aktuellen Zustand auf der Festplatte, entferne sie, wenn sie auf der Festplatte gelöscht wurde, oder aktualisiere ihren Eintrag in der Objektdatenbank.

url(rmt::GitRemote)

Holen Sie sich die Fetch-URL eines Remote-Git-Repositorys.

Beispiele

julia> repo_url = "https://github.com/JuliaLang/Example.jl";

julia> repo = LibGit2.init(mktempdir());

julia> remote = LibGit2.GitRemote(repo, "origin", repo_url);

julia> LibGit2.url(remote)
"https://github.com/JuliaLang/Example.jl"

version() -> VersionNumber

Gibt die Version von libgit2 zurück, die verwendet wird, als VersionNumber.

with(f::Function, obj)

Hilfsfunktion für das Ressourcenmanagement. Wendet f auf obj an und stellt sicher, dass close auf obj aufgerufen wird, nachdem f erfolgreich zurückgegeben hat oder einen Fehler ausgelöst hat. Stellt sicher, dass zugewiesene Git-Ressourcen so schnell wie möglich finalisiert werden, sobald sie nicht mehr benötigt werden.

with_warn(f::Function, ::Type{T}, args...)

Ressourcenverwaltungs-Hilfsfunktion. Wendet f auf args an, indem zuerst eine Instanz des Typs T aus args erstellt wird. Stellt sicher, dass close auf dem resultierenden Objekt aufgerufen wird, nachdem f erfolgreich zurückgegeben hat oder einen Fehler auslöst. Stellt sicher, dass zugewiesene Git-Ressourcen so schnell wie möglich finalisiert werden, sobald sie nicht mehr benötigt werden. Wenn ein Fehler von f ausgelöst wird, wird eine Warnung angezeigt, die den Fehler enthält.

LibGit2.workdir(repo::GitRepo)

Gibt den Speicherort des Arbeitsverzeichnisses von repo zurück. Dies wird einen Fehler für nackte Repositories auslösen.

!!! Hinweis Dies ist typischerweise das übergeordnete Verzeichnis von gitdir(repo), kann aber in einigen Fällen unterschiedlich sein: z. B. wenn entweder die Konfigurationsvariable core.worktree oder die Umgebungsvariable GIT_WORK_TREE gesetzt ist.

Siehe auch gitdir, path.

(::Type{T})(te::GitTreeEntry) where T<:GitObject

Holen Sie das Git-Objekt, auf das te verweist, und geben Sie es als seinen tatsächlichen Typ zurück (der Typ entrytype würde angezeigt), zum Beispiel ein GitBlob oder GitTag.

Beispiele

tree = LibGit2.GitTree(repo, "HEAD^{tree}")
tree_entry = tree[1]
blob = LibGit2.GitBlob(tree_entry)

Anmeldeinformationen, die nur die Parameter user und password unterstützen

SSH-Anmeldeinformationen-Typ

isfilled(cred::AbstractCredential) -> Bool

Überprüft, ob ein Credential bereit zur Verwendung bei der Authentifizierung ist.

Speichert Anmeldeinformationen zur Wiederverwendung

LibGit2.CredentialPayload

Beibehält den Zustand zwischen mehreren Aufrufen des Anmeldeinformationen-Callbacks für dieselbe URL. Eine CredentialPayload-Instanz sollte mit reset! zurückgesetzt werden, wann immer sie mit einer anderen URL verwendet wird.

approve(payload::CredentialPayload; shred::Bool=true) -> Nothing

Speichert die payload-Anmeldeinformationen zur Wiederverwendung bei einer zukünftigen Authentifizierung. Sollte nur aufgerufen werden, wenn die Authentifizierung erfolgreich war.

Das Schlüsselwort shred steuert, ob sensible Informationen im Anmeldeinformationsfeld des Payloads zerstört werden sollen. Sollte nur während des Testens auf false gesetzt werden.

reject(payload::CredentialPayload; shred::Bool=true) -> Nothing

Verwerfen Sie das payload-Credential, um eine Wiederverwendung bei zukünftigen Authentifizierungen zu verhindern. Sollte nur aufgerufen werden, wenn die Authentifizierung nicht erfolgreich war.

Das shred-Schlüsselwort steuert, ob sensible Informationen im Feld des Payload-Credentials zerstört werden sollen. Sollte nur während des Testens auf false gesetzt werden.

Prioritätsstufe einer Konfigurationsdatei.

Diese Prioritätsstufen entsprechen der natürlichen Eskalationslogik (von höher nach niedriger), wenn nach Konfigurationseinträgen in git gesucht wird.

• CONFIG_LEVEL_DEFAULT - Öffnen Sie die globalen, XDG- und Systemkonfigurationsdateien, falls verfügbar.
• CONFIG_LEVEL_PROGRAMDATA - Systemweit unter Windows, zur Kompatibilität mit portablem git
• CONFIG_LEVEL_SYSTEM - Systemweite Konfigurationsdatei; /etc/gitconfig auf Linux-Systemen
• CONFIG_LEVEL_XDG - XDG-kompatible Konfigurationsdatei; typischerweise ~/.config/git/config
• CONFIG_LEVEL_GLOBAL - Benutzerspezifische Konfigurationsdatei (auch als globale Konfigurationsdatei bezeichnet); typischerweise ~/.gitconfig
• CONFIG_LEVEL_LOCAL - Repository-spezifische Konfigurationsdatei; $WORK_DIR/.git/config in nicht-bare Repos
• CONFIG_LEVEL_APP - Anwendungs-spezifische Konfigurationsdatei; frei von Anwendungen definiert
• CONFIG_HIGHEST_LEVEL - Stellt die höchste verfügbare Konfigurationsdatei dar (d.h. die spezifischste Konfigurationsdatei, die tatsächlich geladen wird)