Hallo zusammen,
ich suche ein kleines Plugin, vielleicht kennt ja jemand was in der
Richtung:
Ich nutze GitHub für meine Projekte (zZ STM32, C). Dabei möchte ich,
dass Versionsnummer und vielleicht auch die letzten 3
Änderungs"beschreibungen" in den Files im Header stehen, zB so
1
/**
2
* \file datei1.c
3
*
4
* \Version $hier automatischer Eintrag$
5
* \history $Version $Date $Comment
6
* \history $Version-1 $Date $Comment
7
*/
gerne auch mit Versionsverwaltung.
Hat dafür jemand einen Link für mich?
Hallo,
warum willst du das? Das wuerde doch bedeuten, dass sich der Status
deiner Working Copy mit jedem Commit aendert.
Eventuell kann man ueber einen hook das bei jedem checkout einfuegen und
bei jedem commit wieder rausnehmen, damit diese (veralteten)
Informationen nicht mit in der Aenderungshistorie sind.
MfG
Christopher
Christopher B. schrieb:> Das wuerde doch bedeuten, dass sich der Status> deiner Working Copy mit jedem Commit aendert.
Genau das wird vermieden, wenn man die Mechanismen der
Versionsverwaltung verwendet.
Christopher B. schrieb:> warum willst du das
Weil ich gerne in den Files sehen möchte, welche Version meine lokale
Version ist.
Die History ist da eher Bonus, interessant ist mehr Datum, Autor,
Commit-Message des Commits.
Konrad S. schrieb:> Sowas erledigt normalerweise die Versionsverwaltung. Sprich mit ihr.> (RTFM)
Oh wieder so ein schlauer Beitrag.
AFAIK hat Git aber so eine Funktion nicht.
Falls Git Wildcards in .c/.h ausfüllen kann (mit Commit Message, Author,
Date), sag mir wo es steht ;)
Christopher B. schrieb:> kann git afaik nicht.
Ups! Ich gestehe, dass ich nicht nachgeschaut habe. Ich kenne/nutze
offenbar seit ewigen Zeiten nur die Versionsverwaltungen, die das
unterstützen. Da habe ich git was falsches unterstellt, sorry.
> Diese Information gehoert da m.M.n. auch nicht> hin.
Bei SVN habe ich gerne $Id$ drin. Es zeigt, dass die Datei unter
Versionskontrolle ist und wer sie wann zuletzt in der Mache hatte. Den
Rest kann man sich bei Bedarf von der Versionsverwaltung erfragen.
Edit:
Guter Link, vielen Dank dafür!
Naja wenn man Egit in eclipse als git plugin verwendet, kann man auch
direkt sehen welche Dateien in der Verwaltung sind.
Wie ein aelterer Arbeitskollege erst letztens meinte als ich ihm
Versionsverwaltung nahe legte: "Hab ich dann auch solche Becherchen?"
(s. Bild)
Christopher B. schrieb:> git show -s
Okay, das zeigt mir den aktuellen Commit.
Was für mich aber interessant ist:
Wir arbeiten zu zweit an einem Projet mit Dateien a.c, b.c und c.c.
Am Freitag ändere ich a.c und b.c und weiß am Montag, das mein Partner
einen Commit gemacht hat.
Nun würde ich gerne nach einem Pull schnell in der offenen Datei a.c
sehen, ob er sie noch bearbeitet hat oder nicht.
zZ muss ich dafür auf github bzw per Konsole die "History" von a.c
nachschauen. Da hätte ich gerne was im Header der Datei.
Christopher B. schrieb:> Edit:> http://git-scm.com/book/de/v1/Git-individuell-einrichten-Git-Attribute#Schlüsselworterweiterung
Danke, da werd ich mich mal reinlesen.
Konrad S. schrieb:> Ich kenne/nutze> offenbar seit ewigen Zeiten nur die Versionsverwaltungen, die das> unterstützen.
Gibt es da was freies? Vielleicht lohnt ja der Umstieg?
Christopher B. schrieb:> Naja wenn man Egit in eclipse als git plugin verwendet, kann man auch> direkt sehen welche Dateien in der Verwaltung sind.
Aber nicht (auf einfache Weise), wann von wem bearbeitet. Außer du
kennst ein Untermenü mehr als ich, dann her damit :)
Oliver W. schrieb:> Aber nicht (auf einfache Weise), wann von wem bearbeitet. Außer du> kennst ein Untermenü mehr als ich, dann her damit :)
Rechts klick Team->Show History?
Oliver W. schrieb:> Gibt es da was freies? Vielleicht lohnt ja der Umstieg?
Ich nutze privat und in der Arbeit seit Jahren SVN und bin im
Wesentlichen zufrieden damit. Mir reicht dabei das $Id$ aus.
Zusätzlich gibt es noch ein auf der SVN-Library aufsetzendes
Hilfsprogramm, das aus allen versionierten Quelldateien einer zu
erstellenden Datei Revision-, Zeit- und Statusinformationen
zusammenträgt und damit das Erzeugen eines Timestamps für einen Build
erleichtert. Da dieses Programm für eine andere Versionsverwaltung extra
angepasst werden müsste (was an mir hängenbleiben würde), ist mein
Interesse an nochmal einer neuen Versionsverwaltung nicht sonderlich
stark.
Tec Nologic schrieb:> Oliver W. schrieb:>> Aber nicht (auf einfache Weise), wann von wem bearbeitet. Außer du>> kennst ein Untermenü mehr als ich, dann her damit :)>> Rechts klick Team->Show History?
genau, also nicht auf das Projekt, sondern auf die Datei die du willst.
Ein kleines Zusatzfeature ist, dass du im History View (der ist bei mir
immer eine Registerkarte vom Hauptfenster, also da wo auch der
Sourcecode steht) die Option "Link with Editor and Selection" (sind zwei
gerade Pfeile nach links und rechts). Wenn man dann die History auf hat
und eine Datei im Project Explorer auswaehlt wird nur die History dieser
Datei mit allen Commits, Authoren, etc. angezeigt.
Oliver W. schrieb:> Gibt es da was freies? Vielleicht lohnt ja der Umstieg?
Die drei "modernen" Versionsverwaltungen git, mercurial und bazaar
unterstuetzen dass afaik nicht. Aber da kann ich mich auch irren.
Zumindest fuer mercurial gibt es wohl ein Plugin, aber das wird auch
nicht empfohlen.
https://git.wiki.kernel.org/index.php/GitFaq#Does_Git_have_keyword_expansion.3F>> Does Git have keyword expansion?>> Keyword expansion is not recommended. Keyword expansion causes all sorts>> of strange problems and isn't really useful anyway, especially within>> the context of an SCM. You can perform keyword expansion outside of Git>> using a custom script. ..
Keyword substitution braucht man nicht wenn man es richtig macht.
Git kann die Historie sehr gut aufnehmen und darstellen, es ist
sozusagen dafuer da ;)
$Id etc. pp. ist redundant und verschmutzt doch nur den Quellcode, es
skaliert nicht, zB. tausende Aenderungen an einer Datei fuehren dazu das
mehr Historie als Quelltext drinnsteht.
Mit veralteten SCM wie CVS war das mal ein Notnagel mit dem man
versuchte fehlende Funktionen nachzubauen.
Ansonsten sind die Revision hashes schon eindeutig und man nutzt Tags
fuer releases.
Vielen Dank, ich hab mich noch mal ein bisschen mehr in Git bzw eGit
reingearbeitet und komme inzwischen besser klar.
Nutze zur Zeit die Kombi aus eGit und Kommandozeile.
Eine Frage dazu aber noch:
Wie erstelle ich in eGit richtig ein neues Branch und pushe es auf den
Master?
Wenn ich das von eclipse aus mache, meckert er dass das branch (der
branch? die branch?) auf dem Remote fehlt.
Mach ich per Konsole und push mit der -u Option, geht alles?
Thread beobachten
Seitenaufteilung abschalten