Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #129251 > unrolled thread

Re: git

Back to article view | Back to de.comp.os.unix.linux.misc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: git Martin Vaeth <martin@mvath.de> - 2023-03-12 15:15 +0000
    Re: git Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-03-12 15:56 +0000
      Re: git Thomas Hochstein <thh@thh.name> - 2023-03-12 18:07 +0100
        Re: git Martin Vaeth <martin@mvath.de> - 2023-03-13 01:41 +0000
          Re: git Arno Welzel <usenet@arnowelzel.de> - 2023-03-17 17:01 +0100
          Re: git Thomas Hochstein <thh@thh.name> - 2023-03-18 20:24 +0100
            Re: git Martin Vaeth <martin@mvath.de> - 2023-03-21 16:09 +0000
              Re: git Thomas Dorner <dcoulm230321.dorner@spamgourmet.com> - 2023-03-21 19:09 +0100
                Re: git Martin Vaeth <martin@mvath.de> - 2023-03-22 17:45 +0000
                  Re: git Christian Garbs <mitch@cgarbs.de> - 2023-03-22 18:50 +0000
                    Re: git Martin Vaeth <martin@mvath.de> - 2023-03-25 04:38 +0000
                      Re: git Christian Garbs <mitch@cgarbs.de> - 2023-04-05 13:08 +0000
                        Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-04-05 19:40 +0200
                        Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-04-06 09:41 +0200
                          Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-04-07 08:47 +0200
                            Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-04-10 09:02 +0200
                              Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-04-10 09:46 +0200
                                Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-04-10 11:35 +0200
                                  Re: git Tim Landscheidt <tim@tim-landscheidt.de> - 2023-04-14 13:56 +0000
                      Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-04-06 09:35 +0200
                        Re: git Christian Garbs <mitch@cgarbs.de> - 2023-04-06 20:34 +0000
                  Re: git Thomas Dorner <dcoulm230323.dorner@spamgourmet.com> - 2023-03-23 18:56 +0100
                    Re: git Martin Vaeth <martin@mvath.de> - 2023-03-25 05:09 +0000
                      Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-25 10:02 +0100
                        Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-25 11:22 +0100
                          Re: git Martin Vaeth <martin@mvath.de> - 2023-03-26 16:22 +0000
                            Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-27 18:10 +0200
                        Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-25 12:39 +0100
                          Re: git Tim Landscheidt <tim@tim-landscheidt.de> - 2023-03-25 23:59 +0000
                            Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-26 09:04 +0200
                            Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-26 12:59 +0200
                              Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-26 13:18 +0200
                          Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-26 10:41 +0200
                          Re: git Christian Garbs <mitch@cgarbs.de> - 2023-04-05 12:42 +0000
                            Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-04-14 22:17 +0200
                              Re: git Christian Garbs <mitch@cgarbs.de> - 2023-04-15 07:50 +0000
                                Re: git Christian Garbs <mitch@cgarbs.de> - 2023-04-18 07:28 +0000
                                  Re: git Enrik Berkhan <Enrik.Berkhan@inka.de> - 2023-04-18 18:06 +0000
                                    Re: git Christian Garbs <mitch@cgarbs.de> - 2023-04-22 18:06 +0000
                                    Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-17 22:26 +0200
                                      Re: git Christian Garbs <mitch@cgarbs.de> - 2023-07-25 19:45 +0000
                                        Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-08-06 13:45 +0200
                                  Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-17 21:26 +0200
                              Re: git Enrik Berkhan <Enrik.Berkhan@inka.de> - 2023-04-15 12:15 +0000
                        Re: git Martin Vaeth <martin@mvath.de> - 2023-03-26 17:39 +0000
              Re: git Christian Garbs <mitch@cgarbs.de> - 2023-03-21 21:02 +0000
              Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-22 00:56 +0100
                Re: git Martin Vaeth <martin@mvath.de> - 2023-03-22 17:14 +0000
      Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-12 18:51 +0100
        Re: git Martin Vaeth <martin@mvath.de> - 2023-03-13 01:46 +0000
          Re: git Arno Welzel <usenet@arnowelzel.de> - 2023-03-17 17:02 +0100
            Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-18 11:23 +0100
              Re: git Laurenz Trossel <me@example.invalid> - 2023-03-18 12:18 +0000
              Re: git Arno Welzel <usenet@arnowelzel.de> - 2023-03-19 17:15 +0100
            Re: git Martin Vaeth <martin@mvath.de> - 2023-03-21 14:57 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#129816

Mahlzeit!

Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> Martin Vaeth <martin@mvath.de> wrote:

>>Der Grund scheint mir aber eher zu sein, dass es eben
>>kein Feature ist, das für *Softwareentwicklung* nützlich ist,
>>und es deshalb eben "aus Prinzip" nicht unterstützt werden soll,
>>weil git dafür nicht gedacht ist.
> 
> Das passt ja auch auf die Einstellung, dass die git-Autoren
> mantraartig sagen, dass git kein Tool zum Verteilen von Dateien ist,
> auch wenn es auf ganz breiter Front dafür genutzt wird (und den Job
> wegen der Hartleibigkeit der Entwickler eher schlecht als recht macht)

So ein "git ist nicht für XYZ gedacht" finde ich als Abgrenzung
eigentlich nicht schlecht, sonst kommt laufend irgendwas dazu und am
Ende hat man Excel – Endnutzer wollen eigentlich immer Excel ;-)


Ich habe erst "Clean Architecture" von Uncle Bob durchgelesen, der
schreibt da, dass die großen Programmierparadigmen
(z.B. Objektorientierung und Funktionales Programmieren) deshalb für
besser wartbare und verständlichere Programme sorgen, weil sie den
Programmierer Möglichkeiten _wegnehmen_.

Ein anderes ausgiebiges Thema ist, dass man möglichst lose koppeln
soll und die Abhängigkeiten in eine bestimmte Richtung zeigen sollen,
woraus sich dann favorisiert Plugin-Mechanismen ergeben.


Wenn man diese beiden Kriterien an git anlegt, passt das zum Verhalten
der git-Programmierer:

 - sie definieren, was der git-Kern _nicht_ können soll
 
 - es ist möglich, die Zeitstempel-Funktionalität mit Plugins (Hooks,
   Wrapper-Skripten usw.) zu ergänzen, ohne dass git davon etwas
   wissen oder geändert werden muss


Ein wenig geht das auch in die Richtung "one tool, one job", wobei git
so mächtig ist, dass ich "one job" schon schwammig finde – dass
"Versionsverwaltung" nicht klar umrissen ist, sehen wir ja hier im
Thread.


Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
I've finished Legend of Zelda - Ocarina of Time
and didn't even get a kiss from the Princess.

[toc] | [prev] | [next] | [standalone]

#129647

Martin Vaeth <martin@mvath.de> writes:
> Thomas Dorner <dcoulm230321.dorner@spamgourmet.com> wrote:
>> Martin Vaeth <martin@mvath.de> writes:
>>
>>> Eben nur die Änderungen. Wenn Du ein Verzeichnis mit
>>> Dateien 1985-jetzt hast und das in Git eincheckst, hast
>>> Du alle Deine Zeitinformationen auf einen Schlag
>>> verloren.
>>
>> Dann mache halt einzelne commits mit --date.
>
> Für jede einzelne Datei manuell - nein danke. Dass es mit einem
> Skriptverhau möglich ist, wenn man *gegen* git arbeiten will, habe
> ich ja schon geschrieben. Spass hat man dabei aber nicht, weil man
> letztlich ein inadäquates Tool für das Problem benutzt.

Das ist vermutlich (ungetestet) ein Dreizeiller ala

|for f in ...; do
|   git commit --date=$(stat --format=%Y "$f") --message='...' "$f"
|done

Auf ähnliche Weise habe ich bei meinem Ex-Arbeitgeber schon ganze
Projekte unter Beibehaltung der ursprünglichen Historie erst vom RCS
basierten MKS "Integrity" (dessen Merge-Behandlung wohl eher als Witz
gedacht war ;-) nach Mercurial und später nach Git migriert.
(Das waren dann allerdings in der Tag Skriptverhaue, aber die Rettung
der Historie war es mir im Gegensatz zu anderen Kollegen wert.)

Viele Grüße, Thomas
-- 
Adresse gilt nur kurzzeitig!

[toc] | [prev] | [next] | [standalone]

#129689

Thomas Dorner <dcoulm230323.dorner@spamgourmet.com> wrote:
> Martin Vaeth <martin@mvath.de> writes:
>> Thomas Dorner <dcoulm230321.dorner@spamgourmet.com> wrote:
>>> Martin Vaeth <martin@mvath.de> writes:
>>>
>>>> Eben nur die Änderungen. Wenn Du ein Verzeichnis mit
>>>> Dateien 1985-jetzt hast und das in Git eincheckst, hast
>>>> Du alle Deine Zeitinformationen auf einen Schlag
>>>> verloren.
>>>
>>> Dann mache halt einzelne commits mit --date.
>>
>> Für jede einzelne Datei manuell - nein danke. Dass es mit einem
>> Skriptverhau möglich ist, wenn man *gegen* git arbeiten will, habe
>> ich ja schon geschrieben. Spass hat man dabei aber nicht, weil man
>> letztlich ein inadäquates Tool für das Problem benutzt.
>
> Das ist vermutlich (ungetestet) ein Dreizeiller ala
>
>|for f in ...; do
>|   git commit --date=$(stat --format=%Y "$f") --message='...' "$f"
>|done

Und damit hast Du Hunderte von Commits mit der selben Commit-Message
(oder bestenfalls einer trivialen Modifizierung) statt - was
natürlich wäre - ein "Initial commit". Das schafft keine Übersicht.
Ähnliches brauchst Du beim Checkout und bei jedem Checkin, von
merge-Operationen ganz zu schweigen, in denen Du in
der Praxis oft nur einzelne Dateien mergen willst.
Vom Aufräumen ganz zu schweigen, wo Du dann oft gezwungen bist
Hunderte von Commits zu rebasen.
Sicher, das ist alles möglich, aber es entspricht keinem
natürlichen Arbeitsfluss mit git und ist ausgeprochen unpraktisch;
für jede Kleinigkeit brauchst Du neue Hilfsskripte oder musst
Dir mit anderen Notflösungen behelfen.
Das ist das, was ich meinte mit:
Für Verzeichnisse mit Textdateien arbeitet man letztlich die
ganze Zeit *gegen* git.

[toc] | [prev] | [next] | [standalone]

#129700

Am 25.03.2023 um 06:09 schrieb Martin Vaeth:
> Thomas Dorner <dcoulm230323.dorner@spamgourmet.com> wrote:
>> Martin Vaeth <martin@mvath.de> writes:
>>> Für jede einzelne Datei manuell - nein danke. Dass es mit einem
>>> Skriptverhau möglich ist, wenn man *gegen* git arbeiten will, habe
>>> ich ja schon geschrieben. Spass hat man dabei aber nicht, weil man
>>> letztlich ein inadäquates Tool für das Problem benutzt.
>>
>> Das ist vermutlich (ungetestet) ein Dreizeiller ala
>>
>> |for f in ...; do
>> |   git commit --date=$(stat --format=%Y "$f") --message='...' "$f"
>> |done
> 
> Und damit hast Du Hunderte von Commits mit der selben Commit-Message
> (oder bestenfalls einer trivialen Modifizierung) statt - was
> natürlich wäre - ein "Initial commit". Das schafft keine Übersicht.

Wenn du "ein Verzeichnis mit Dateien 1985-jetzt" importieren willst UND
dabei noch aussagefähige Commit-Messages haben willst, kommst du um
Handarbeit sowieso nicht drumherum.

Stünde ich vor dem Problem, würde ich vermutlich 'cvs import -d'
benutzen und das CVS-Repository danach mit 'git cvsimport' nach git
konvertieren. Dann übernimmt 'git cvsimport' das Sortieren der Commits
in die chronologisch richtige Reihenfolge.

Praktisch habe ich bisher meistens einfach 'git add' gemacht und auf die
Timestamps verzichtet. Timestamps sind für mich eh flüchtige
Informationen, die gehen einfach kaputt, wenn man die Dateien mal über
einen nicht ganz geeigneten Transportweg (falsches Packprogramm? HTTP?)
transportiert. Wenn ein Zeitstempel wichtig ist, muss er im Dateiinhalt
stehen. Andererseits muss man gelegentlich daran rumfummeln, um z.B.
einem suboptimalen Makefile auf die Sprünge zu helfen.

> Für Verzeichnisse mit Textdateien arbeitet man letztlich die
> ganze Zeit *gegen* git.

Also ich habe nicht das Gefühl, gegen git zu arbeiten...


  Stefan

[toc] | [prev] | [next] | [standalone]

#129701

On 2023-03-25 09:02, Stefan Reuther <stefan.news@arcor.de> wrote:
> Timestamps sind für mich eh flüchtige Informationen, die gehen einfach
> kaputt, wenn man die Dateien mal über einen nicht ganz geeigneten
> Transportweg (falsches Packprogramm? HTTP?) transportiert.

Zu den "nicht ganz geeigneten Transportwegen" zählt auch "cp" ohne
Optionen. Schon allein deswegen würde ich von einem Unix-User erwarten,
dass er der mtime nicht allzuviel Bedeutung zumisst.

        hp

[toc] | [prev] | [next] | [standalone]

#129719

Peter J. Holzer <hjp-usenet3@hjp.at> schrieb:
> On 2023-03-25 09:02, Stefan Reuther <stefan.news@arcor.de> wrote:
>> Timestamps sind für mich eh flüchtige Informationen, die gehen einfach
>> kaputt, wenn man die Dateien mal über einen nicht ganz geeigneten
>> Transportweg (falsches Packprogramm? HTTP?) transportiert.
>
> Zu den "nicht ganz geeigneten Transportwegen" zählt auch "cp" ohne
> Optionen.

Die meisten Programme bieten Optionen an, den Timestamp
beizubehalten. So natürlich auch "cp", das sogar per
POSIX-Standard die Option -p besitzen muss. git ist eines
der wenigen "Transportwege", die keine solche Option haben.
WIMRE behält sogar wget (http) den timestamp per Default bei,
bei Packprogrammen tun es vermutlich alle per Default.

> Schon allein deswegen würde ich von einem Unix-User erwarten,
> dass er der mtime nicht allzuviel Bedeutung zumisst.

Ich würde von einem Unix-User erwarten, dass er die Tools
mit den Optionen benutzt, die für seine Zwecke korrekt sind.
Für Gedächtnisschwache gibt es genug Möglichkeiten (Hilfswrapper
als Scripte, Funktionen, Aliase, Benutzung anderer Programme,
usw), und wenn man trotz allem einen Fehler gemacht hat, kann
man z.B. touch --reference oder Restauration vom Backup nutzen.

[toc] | [prev] | [next] | [standalone]

#129731

Am 26.03.2023 um 18:22 schrieb Martin Vaeth:
> Peter J. Holzer <hjp-usenet3@hjp.at> schrieb:
>> On 2023-03-25 09:02, Stefan Reuther <stefan.news@arcor.de> wrote:
>>> Timestamps sind für mich eh flüchtige Informationen, die gehen einfach
>>> kaputt, wenn man die Dateien mal über einen nicht ganz geeigneten
>>> Transportweg (falsches Packprogramm? HTTP?) transportiert.
>>
>> Zu den "nicht ganz geeigneten Transportwegen" zählt auch "cp" ohne
>> Optionen.
> 
> Die meisten Programme bieten Optionen an, den Timestamp
> beizubehalten. So natürlich auch "cp", das sogar per
> POSIX-Standard die Option -p besitzen muss. git ist eines
> der wenigen "Transportwege", die keine solche Option haben.
> WIMRE behält sogar wget (http) den timestamp per Default bei,
> bei Packprogrammen tun es vermutlich alle per Default.

Bei HTTP klappt das auch nur, wenn sowohl Server, als auch Downloader
mitspielen. Also im Wesentlichen: nur mit wget, und nur, wenn der Server
tatsächlich Dinge aus dem Filesystem serviert, ohne Skript außenrum.

>> Schon allein deswegen würde ich von einem Unix-User erwarten,
>> dass er der mtime nicht allzuviel Bedeutung zumisst.
> 
> Ich würde von einem Unix-User erwarten, dass er die Tools
> mit den Optionen benutzt, die für seine Zwecke korrekt sind.
> Für Gedächtnisschwache gibt es genug Möglichkeiten (Hilfswrapper
> als Scripte, Funktionen, Aliase, Benutzung anderer Programme,
> usw), und wenn man trotz allem einen Fehler gemacht hat, kann
> man z.B. touch --reference oder Restauration vom Backup nutzen.

Für git natürlich auch: https://gist.github.com/andris9/1978266

Ich verwende so etwas ähnliches: wenn ich vor der Ablieferung den
Featurebranch in die richtige Form bringe ('git rebase -i' Orgie),
sichere ich vorher md5's und Timestamps, und restauriere die hinterher
wieder. Denn wenn der Rebase so tut wie gewünscht, ändert er die
Dateiinhalte effektiv nicht. Ich hab nur zwischendurch ein paar "halbe"
Zustände. Das spart mir den ein oder anderen Komplett-Rebuild, nur weil
der Rebase ein zentrales Headerfile anfasst.

Aber an sich ist genau der Rebase ein gutes Argument *gegen*
Wiederherstellen von Timestamps: wenn man zwei Commits chronologisch
vertauscht, käme man dann in die Situation, dass ein Auschecken eines
per History neueren Commits einer Datei eine ältere (Author-)Timestamp
verpassen müsste. Auch nicht sinnvoll. Alternativ nähme man den
Commiter-Timestamp, aber der ist wenig wert, eben weil der sich ändert,
wenn man einfach nur Commits umsortiert, ohne Inhalte zu ändern.


  Stefan

[toc] | [prev] | [next] | [standalone]

#129703

Stefan Reuther <stefan.news@arcor.de> wrote:
>Wenn du "ein Verzeichnis mit Dateien 1985-jetzt" importieren willst UND
>dabei noch aussagefähige Commit-Messages haben willst, kommst du um
>Handarbeit sowieso nicht drumherum.
>
>Stünde ich vor dem Problem, würde ich vermutlich 'cvs import -d'
>benutzen und das CVS-Repository danach mit 'git cvsimport' nach git
>konvertieren. Dann übernimmt 'git cvsimport' das Sortieren der Commits
>in die chronologisch richtige Reihenfolge.
>
>Praktisch habe ich bisher meistens einfach 'git add' gemacht und auf die
>Timestamps verzichtet. Timestamps sind für mich eh flüchtige
>Informationen, die gehen einfach kaputt, wenn man die Dateien mal über
>einen nicht ganz geeigneten Transportweg (falsches Packprogramm? HTTP?)
>transportiert. Wenn ein Zeitstempel wichtig ist, muss er im Dateiinhalt
>stehen. Andererseits muss man gelegentlich daran rumfummeln, um z.B.
>einem suboptimalen Makefile auf die Sprünge zu helfen.

Ich bin schon mehrmals daran gescheitert, das exim4-Repository mit der
Debian-Paketierung in ein zeitgemäßes Format zu bringen. Damals, in
svn-Zeit, war es üblich, nur das debian/-Verzeichnis unter
Versionskontrolle zu haben und die Build-Tools das Upstream-Tar dazu
auspacken zu lassen. Dieses svn haben wir dann vor ~ 10 Jahren mit git
svn (?) nach git konvertiert und so arbeitet Andreas immer noch. Ich
kann die Tools von damals nicht mehr bedienen :-(

Heute hat man die Upstream-Sourcen in einem eigenen git-Branch, die in
den master¹-Branch hineingemergt werden. Der Unterschied zwischen
upstream und debian-Master  ist das debian/-Verzeichnis, man müsste
den Debian-Master eigentlich auch auf den jeweiligen Upstream rebasen
können.

Ich bin leider bisher daran gescheitert, das Debian-git von exim4 so
weit aufzubauen, dass es diesen Konventionen entspricht UND die 20
Jahre Debian-Develpoment-History UND die Upstream-History korrekt
enthält. Das wurmt mich wirklich, aber vielleicht bin ich inzwischen
mit git so gut, dass ich das vielleicht auch mal hinbekommen könnte.

Wo wir gerade bei solchen Debian-Grundlagen sind: Die Debian-Changes
an den Upstreamsourcen liegen als quilt-Patches in debian/patches und
werden beim Bau angewendet und danach wieder unapplied, dsa machen
aber die Builtools automatisch und eigentlich ist der Prozess ganz
flauschig. Das ganze nennt sich "Source-Format 3.0 (quilt)".

Es gibt immer mal wieder Bewegungen, sich diese quilt-Zwischenstufe zu
sparen und die Änderungen am Upstream direkt mit der Versionskontrolle
mitzuführen ("Source-Format 3.0 (git)"); ich habe mir immer mal wieder
vorgenommen, das mit einem meiner Pakete mal auszuprobieren es aber
bisher noch nicht getan.

Und dann gibt es noch einen Schritt weiter namens dgit, wo man gar
kein Source-Paket mehr baut und hochlädt, sondern einen Tag signiert
und pusht und die Debian-Infrastruktur dann Source- und Binärpaket
selbst extrahiert und baut. Das klingt auf den ersten Blick gar nicht
schlecht, aber die Art wie aggressiv der Autor Ian Jackson seine Idee
pusht ist mir inhärent unsympathisch. Ich denke, gute Lösungen
verbreiten sich von selbst ohne dass man bei jeder Gelegenheit aus dem
Busch springen und für seine Idee Werbung machen muss.

Grüße
Marc

¹ ja, ist politisch inkorrekt, habe aber noch kein Repository gesehen
wo das wirklich in main umbenannt wurde wie das social justice
department von Debian es gerne hätte
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#129713

Marc Haber <mh+usenetspam1118@zugschl.us> wrote:

> […]

> Wo wir gerade bei solchen Debian-Grundlagen sind: Die Debian-Changes
> an den Upstreamsourcen liegen als quilt-Patches in debian/patches und
> werden beim Bau angewendet und danach wieder unapplied, dsa machen
> aber die Builtools automatisch und eigentlich ist der Prozess ganz
> flauschig. Das ganze nennt sich "Source-Format 3.0 (quilt)".

> Es gibt immer mal wieder Bewegungen, sich diese quilt-Zwischenstufe zu
> sparen und die Änderungen am Upstream direkt mit der Versionskontrolle
> mitzuführen ("Source-Format 3.0 (git)"); ich habe mir immer mal wieder
> vorgenommen, das mit einem meiner Pakete mal auszuprobieren es aber
> bisher noch nicht getan.

Sowohl bei dem ersteren als gerade auch bei dem letzteren
schüttelt es mich immer gewaltig. Ich bin mit RPMs „pristine
sources“ aufgewachsen, und schon die Vorstellung, dass man
den Tarball neu baut, tut mir physisch weh.

Aber der Gedanke, dass sowohl die Prüfung der Echtheit der
Ursprungssoftware nicht mit einem Blick erledigt ist, als
auch, dass wichtige Patches bei einem Git-Rebase/-Merge her-
unterfallen könnten, weil ein gutmeinender Maintainer auf
Gits Automatik vertraut statt ein sehr genaues Auge darauf
zu werfen – *brrr*.

> Und dann gibt es noch einen Schritt weiter namens dgit, wo man gar
> kein Source-Paket mehr baut und hochlädt, sondern einen Tag signiert
> und pusht und die Debian-Infrastruktur dann Source- und Binärpaket
> selbst extrahiert und baut. Das klingt auf den ersten Blick gar nicht
> schlecht, aber die Art wie aggressiv der Autor Ian Jackson seine Idee
> pusht ist mir inhärent unsympathisch. Ich denke, gute Lösungen
> verbreiten sich von selbst ohne dass man bei jeder Gelegenheit aus dem
> Busch springen und für seine Idee Werbung machen muss.

Ich glaube, das läuft prinzipiell bei Fedora ja genauso. Das
ist auch einer der Punkte, die mich bei Debian häufig ver-
zweifelt ließen (ich kann zu dem aktuellen Stand nichts sa-
gen): Jedes Paket hatte nicht nur sein eigenes „Repository“,
sondern auch, wie man aus diesem Repository ein Source-Paket
baut, war prinzipiell jedem Paketmaintainer selbst überlas-
sen. Das ist bei Fedora halt idiotensicher: Es gibt eine
zentrale Instanz und exakt einen Weg.

Die beste Erfindung hat Debian jedoch: „Standards-Version“.
Fedoras Idee, dass jeder Maintainer bei einer Änderung der
Packaging Guidelines sofort alle seine Pakete prüft und ge-
gebenenfalls aktualisiert …

Tim

[toc] | [prev] | [next] | [standalone]

#129714

Tim Landscheidt <tim@tim-landscheidt.de> wrote:
>Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>> Wo wir gerade bei solchen Debian-Grundlagen sind: Die Debian-Changes
>> an den Upstreamsourcen liegen als quilt-Patches in debian/patches und
>> werden beim Bau angewendet und danach wieder unapplied, dsa machen
>> aber die Builtools automatisch und eigentlich ist der Prozess ganz
>> flauschig. Das ganze nennt sich "Source-Format 3.0 (quilt)".
>
>> Es gibt immer mal wieder Bewegungen, sich diese quilt-Zwischenstufe zu
>> sparen und die Änderungen am Upstream direkt mit der Versionskontrolle
>> mitzuführen ("Source-Format 3.0 (git)"); ich habe mir immer mal wieder
>> vorgenommen, das mit einem meiner Pakete mal auszuprobieren es aber
>> bisher noch nicht getan.
>
>Sowohl bei dem ersteren als gerade auch bei dem letzteren
>schüttelt es mich immer gewaltig. Ich bin mit RPMs „pristine
>sources“ aufgewachsen, und schon die Vorstellung, dass man
>den Tarball neu baut, tut mir physisch weh.

Den Tarball neu zu bauen habe ich nicht erwähnt. Im Gegenteil: Was
einmal im Archiv ist, verändert sich nicht mehr, auch nicht die
.orig.tar.gz. Es gibt allerdings Mechanismen, die es erlauben, den
Original-Tarball so zu rekonstruieren, dass am Ende die originale
Prüfsumme wieder passt.

>Ich glaube, das läuft prinzipiell bei Fedora ja genauso. Das
>ist auch einer der Punkte, die mich bei Debian häufig ver-
>zweifelt ließen (ich kann zu dem aktuellen Stand nichts sa-
>gen): Jedes Paket hatte nicht nur sein eigenes „Repository“,
>sondern auch, wie man aus diesem Repository ein Source-Paket
>baut, war prinzipiell jedem Paketmaintainer selbst überlas-
>sen. Das ist bei Fedora halt idiotensicher: Es gibt eine
>zentrale Instanz und exakt einen Weg.

Debian lässt dem einzelnen Maintainer die Freiheit seine Tools selbst
wählen zu können. Über die Vor- und Nachteile lässt sich streiten.

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#129716

On 2023-03-25 23:59, Tim Landscheidt <tim@tim-landscheidt.de> wrote:
> Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>> Wo wir gerade bei solchen Debian-Grundlagen sind: Die Debian-Changes
>> an den Upstreamsourcen liegen als quilt-Patches in debian/patches und
>> werden beim Bau angewendet und danach wieder unapplied, dsa machen
>> aber die Builtools automatisch und eigentlich ist der Prozess ganz
>> flauschig. Das ganze nennt sich "Source-Format 3.0 (quilt)".
>
>> Es gibt immer mal wieder Bewegungen, sich diese quilt-Zwischenstufe zu
>> sparen und die Änderungen am Upstream direkt mit der Versionskontrolle
>> mitzuführen ("Source-Format 3.0 (git)"); ich habe mir immer mal wieder
>> vorgenommen, das mit einem meiner Pakete mal auszuprobieren es aber
>> bisher noch nicht getan.
>
> Sowohl bei dem ersteren als gerade auch bei dem letzteren
> schüttelt es mich immer gewaltig. Ich bin mit RPMs „pristine
> sources“ aufgewachsen, und schon die Vorstellung, dass man
> den Tarball neu baut, tut mir physisch weh.

Tut man ja nicht. Ein Source-Paket bei Debian besteht aus dem
Original-Tarball plus Änderungen (Wobei letzteres im Idealfall nur
Metadaten fürs Package-Management enthält, aber in der Praxis auch oft
Patches). Beim Buildvorgang wird dann beides kombiniert.

        hp

[toc] | [prev] | [next] | [standalone]

#129717

"Peter J. Holzer" <hjp-usenet3@hjp.at> wrote:
>On 2023-03-25 23:59, Tim Landscheidt <tim@tim-landscheidt.de> wrote:
>> Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>>> Wo wir gerade bei solchen Debian-Grundlagen sind: Die Debian-Changes
>>> an den Upstreamsourcen liegen als quilt-Patches in debian/patches und
>>> werden beim Bau angewendet und danach wieder unapplied, dsa machen
>>> aber die Builtools automatisch und eigentlich ist der Prozess ganz
>>> flauschig. Das ganze nennt sich "Source-Format 3.0 (quilt)".
>>
>>> Es gibt immer mal wieder Bewegungen, sich diese quilt-Zwischenstufe zu
>>> sparen und die Änderungen am Upstream direkt mit der Versionskontrolle
>>> mitzuführen ("Source-Format 3.0 (git)"); ich habe mir immer mal wieder
>>> vorgenommen, das mit einem meiner Pakete mal auszuprobieren es aber
>>> bisher noch nicht getan.
>>
>> Sowohl bei dem ersteren als gerade auch bei dem letzteren
>> schüttelt es mich immer gewaltig. Ich bin mit RPMs „pristine
>> sources“ aufgewachsen, und schon die Vorstellung, dass man
>> den Tarball neu baut, tut mir physisch weh.
>
>Tut man ja nicht. Ein Source-Paket bei Debian besteht aus dem
>Original-Tarball plus Änderungen (Wobei letzteres im Idealfall nur
>Metadaten fürs Package-Management enthält, aber in der Praxis auch oft
>Patches). Beim Buildvorgang wird dann beides kombiniert.

Das "klassische" Source-Format: 1.0 besteht aus dem orig.tar.gz und
einem .diff.gz, das wirklich ein diff ist.

Das "neuere" Source-Format: 3.0 (quilt) besteht aus dem orig.tar.gz,
einem debian.tar.gz, das stumpf über das ausgepackte orig.tar.gz
hinweg ausgepackt wird und quasi nur das debian/-verzeichnis enthält
(enthalten darf?).

Dazu gehört dann noch das .dsc, das (duplizierte) Metadaten und die
Namen und Checksums der Bestandteildateien enthält.

Beim Bau von Source- und Binary-Paketen entsteht zusätzlich noch ein
.changes File, das weitere Informationen aus dem Changelog enthält und
ein Upload steuert. Das ist dann das File, das vom Maintainer zum
Upload signiert wird.

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#129715

Am 25.03.2023 um 12:39 schrieb Marc Haber:
> Ich bin schon mehrmals daran gescheitert, das exim4-Repository mit der
> Debian-Paketierung in ein zeitgemäßes Format zu bringen. Damals, in
> svn-Zeit, war es üblich, nur das debian/-Verzeichnis unter
> Versionskontrolle zu haben und die Build-Tools das Upstream-Tar dazu
> auspacken zu lassen. Dieses svn haben wir dann vor ~ 10 Jahren mit git
> svn (?) nach git konvertiert und so arbeitet Andreas immer noch. Ich
> kann die Tools von damals nicht mehr bedienen :-(
> 
> Heute hat man die Upstream-Sourcen in einem eigenen git-Branch, die in
> den master¹-Branch hineingemergt werden. Der Unterschied zwischen
> upstream und debian-Master  ist das debian/-Verzeichnis, man müsste
> den Debian-Master eigentlich auch auf den jeweiligen Upstream rebasen
> können.

Ich benutze 'git svn' aktuell eher zaghaft, aber soweit ich das
verstanden hab, ist das für git am Ende ein ganz normaler Remote-Branch.
Es müsste also mit 'git svn fetch' und 'git rebase' genau so gehen.

> Wo wir gerade bei solchen Debian-Grundlagen sind: Die Debian-Changes
> an den Upstreamsourcen liegen als quilt-Patches in debian/patches und
> werden beim Bau angewendet und danach wieder unapplied, dsa machen
> aber die Builtools automatisch und eigentlich ist der Prozess ganz
> flauschig. Das ganze nennt sich "Source-Format 3.0 (quilt)".

Wenn mir jemand mit einem Strauß Patches ankommt, mach ich ja im ersten
Schritt immer git draus, wenn ich damit arbeiten will :)


  Stefan

[toc] | [prev] | [next] | [standalone]

#129792

Mahlzeit!

Marc Haber <mh+usenetspam1118@zugschl.us> wrote:

> Ich bin schon mehrmals daran gescheitert, das exim4-Repository mit der
> Debian-Paketierung in ein zeitgemäßes Format zu bringen. Damals, in
> svn-Zeit, war es üblich, nur das debian/-Verzeichnis unter
> Versionskontrolle zu haben und die Build-Tools das Upstream-Tar dazu
> auspacken zu lassen. Dieses svn haben wir dann vor ~ 10 Jahren mit git
> svn (?) nach git konvertiert und so arbeitet Andreas immer noch. Ich
> kann die Tools von damals nicht mehr bedienen :-(
> 
> Heute hat man die Upstream-Sourcen in einem eigenen git-Branch, die in
> den master¹-Branch hineingemergt werden. Der Unterschied zwischen
> upstream und debian-Master  ist das debian/-Verzeichnis, man müsste
> den Debian-Master eigentlich auch auf den jeweiligen Upstream rebasen
> können.
> 
> Ich bin leider bisher daran gescheitert, das Debian-git von exim4 so
> weit aufzubauen, dass es diesen Konventionen entspricht UND die 20
> Jahre Debian-Develpoment-History UND die Upstream-History korrekt
> enthält. Das wurmt mich wirklich, aber vielleicht bin ich inzwischen
> mit git so gut, dass ich das vielleicht auch mal hinbekommen könnte.

Ich habe mir das gerade mal angeguckt - der git-Teil sollte ungefähr
so funktionieren:


  mkdir exim4-deb
  cd exim4-deb
  git init

  # besser wäre git@salsa.debian.org:exim-team/exim4.git als Quelle,
  # aber das darf ich nicht lesen ;-)
  git remote add debian-upstream https://salsa.debian.org/exim-team/exim4.git
  git pull debian-upstream master

  # Upstream als eigener Branch
  # --orphan, weil der nichts mit unserem Debian-master-Branch zu tun hat
  git checkout --orphan upstream
  git remote add exim-upstream git://git.exim.org/exim.git
  git pull exim-upstream master # oder ein anderer Branch/Tag

  # und jetzt beides zusammenkippen
  # git meckert wegen "unrelated history", aber genau das wollen wir ja
  # der Parameter sollte nur beim allerersten Zusammenfügen relevant sein
  git checkout master
  git merge upstream --allow-unrelated-histories


Sieht dann so aus:

$ ls -lh
total 8,0K
drwxr-xr-x  3 mitch mitch   80  5. Apr 14:37 configs
drwxr-xr-x 10 mitch mitch 2,1K  5. Apr 14:37 debian
drwxr-xr-x  7 mitch mitch  160  5. Apr 14:37 doc
-rw-r--r--  1 mitch mitch 2,3K  5. Apr 14:37 Readme.pod
drwxr-xr-x  3 mitch mitch   80  5. Apr 14:37 release-process
-rw-r--r--  1 mitch mitch 1,1K  5. Apr 14:37 SECURITY.md
drwxr-xr-x  7 mitch mitch  440  5. Apr 14:37 src
drwxr-xr-x 18 mitch mitch  560  5. Apr 14:37 test


Gebaut habe ich das jetzt nicht, da müsste ich mich noch um die
Abhängigkeiten kümmern usw.

Vielleicht bringt Dich das ja schon weiter.

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
Schokolade ist gut gegen Zähne

[toc] | [prev] | [next] | [standalone]

#129910

Christian Garbs <mitch@cgarbs.de> wrote:
>  mkdir exim4-deb
>  cd exim4-deb
>  git init

|[9/4970]mh@drop:~/git/exim4/exim4 $ git init
|Initialized empty Git repository in /home/mh/git/exim4/exim4/.git/

>  # besser wäre git@salsa.debian.org:exim-team/exim4.git als Quelle,
>  # aber das darf ich nicht lesen ;-)
>  git remote add debian-upstream https://salsa.debian.org/exim-team/exim4.git
>  git pull debian-upstream master

|[14/4975]mh@drop:~/git/exim4/exim4 (main #) $ git remote add debian-upstream git@salsa.debian.org:exim-team/exim4.git
|[17/4727]mh@drop:~/git/exim4/exim4 (main #) $ git pull debian-upstream master
|remote: Enumerating objects: 18010, done.
|remote: Counting objects: 100% (2550/2550), done.
|remote: Compressing objects: 100% (288/288), done.
|remote: Total 18010 (delta 2434), reused 2296 (delta 2243), pack-reused 15460
|Receiving objects: 100% (18010/18010), 6.19 MiB | 2.12 MiB/s, done.
|Resolving deltas: 100% (11196/11196), done.
|From salsa.debian.org:exim-team/exim4
| * branch              master     -> FETCH_HEAD
| * [new branch]        master     -> debian-upstream/master

>  # Upstream als eigener Branch
>  # --orphan, weil der nichts mit unserem Debian-master-Branch zu tun hat
>  git checkout --orphan upstream
>  git remote add exim-upstream git://git.exim.org/exim.git
>  git pull exim-upstream master # oder ein anderer Branch/Tag

|[18/4727]mh@drop:~/git/exim4/exim4 (main) $ git checkout --orphan upstream
|Switched to a new branch 'upstream'
|[19/4728]mh@drop:~/git/exim4/exim4 (upstream +) $  git remote add exim-upstream git://git.exim.org/exim.git
|[20/4728]mh@drop:~/git/exim4/exim4 (upstream +) $ git pull exim-upstream master
|fatal: Updating an unborn branch with changes added to the index.
|128 [21/4729]mh@drop:~/git/exim4/exim4 (upstream +) $ git status
|On branch upstream
|
|No commits yet
|
|Changes to be committed:
|  (use "git rm --cached <file>..." to unstage)
|        new file:   debian/EDITME.exim4-heavy.diff
|        new file:   debian/EDITME.exim4-light.diff
|        new file:   debian/EDITME.eximon.diff
|        new file:   debian/EDITME.openssl.exim4-light.diff
|        new file:   debian/NEWS
|        new file:   debian/README.Debian.xml
|        new file:   debian/changelog
[noch viel mehr]

Und nu?

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#129922

Mahlzeit!

Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> Christian Garbs <mitch@cgarbs.de> wrote:

[…]

>>  # Upstream als eigener Branch
>>  # --orphan, weil der nichts mit unserem Debian-master-Branch zu tun hat
>>  git checkout --orphan upstream
>>  git remote add exim-upstream git://git.exim.org/exim.git
>>  git pull exim-upstream master # oder ein anderer Branch/Tag
> 
> |[18/4727]mh@drop:~/git/exim4/exim4 (main) $ git checkout --orphan upstream
> |Switched to a new branch 'upstream'
> |[19/4728]mh@drop:~/git/exim4/exim4 (upstream +) $  git remote add exim-upstream git://git.exim.org/exim.git
> |[20/4728]mh@drop:~/git/exim4/exim4 (upstream +) $ git pull exim-upstream master
> |fatal: Updating an unborn branch with changes added to the index.

Diese Meldung bekomme ich nicht.  Hast Du ein neueres git als ich?
Hier ist's aus stable: 1:2.30.2-1+deb11u2

> |128 [21/4729]mh@drop:~/git/exim4/exim4 (upstream +) $ git status
> |On branch upstream
> |
> |No commits yet
> |
> |Changes to be committed:
> |  (use "git rm --cached <file>..." to unstage)
> |        new file:   debian/EDITME.exim4-heavy.diff
> |        new file:   debian/EDITME.exim4-light.diff
> |        new file:   debian/EDITME.eximon.diff
> |        new file:   debian/EDITME.openssl.exim4-light.diff
> |        new file:   debian/NEWS
> |        new file:   debian/README.Debian.xml
> |        new file:   debian/changelog
> [noch viel mehr]

Das ist bei mir allerdings auch so :/ Hat aber nicht gestört.
Vermutlich ist die neuere Warnung aus dem neueren git gerechtfertigt.

Da ich das bisher nicht gesehen habe, habe ich einfach wie beschrieben
weitergemacht und das Endergebnis hat gepasst.  Ich bin gerade nochmal
so vorgegangen wie von mir gepostet - es funktioniert genau so und am
Ende habe ich im master eine Kombination beider git-Historien und
alles ist eingechect.

Funktioniert "Augen zu und durch" (checkout master, merge upstream)
bei Dir ab der Stelle auch?

Ich werde, wenn ich etwas Zeit habe, das auch nochmal durchgehen und
nach jedem Step "git status" machen und genau hingucken, dass jeder
Step passt.  Vielleicht muss man noch irgendwas manuell machen, was
einer der späteren Befehle mehr oder weniger zufällig mit erledigt.

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
I had a Japanese intern once; I asked him to get some supplies and he never
came back.  In the end I went to look for him and he jumped out waving his
arms and shouted "SUPPLIES!"

[toc] | [prev] | [next] | [standalone]

#129961

Mahlzeit!

Christian Garbs <mitch@cgarbs.de> wrote:

> Ich werde, wenn ich etwas Zeit habe, das auch nochmal durchgehen und
> nach jedem Step "git status" machen und genau hingucken, dass jeder
> Step passt.  Vielleicht muss man noch irgendwas manuell machen, was
> einer der späteren Befehle mehr oder weniger zufällig mit erledigt.

Enrik hat schon den entscheidenen Tipp geliefert:
Mit dem zusätzlichen "git rm -rf debian/" habe ich jetzt an keiner
Stelle mehr komische Dinge herumliegen, "git status" bleibt nach jedem
Schritt sauber.

Damit sollte dann auch die Warnung bei Marks vermutlich neuerem git
verschwinden:

  mkdir exim4-deb
  cd exim4-deb
  git init

  # besser wäre git@salsa.debian.org:exim-team/exim4.git als Quelle,
  # aber das darf ich nicht lesen ;-)
  git remote add debian-upstream https://salsa.debian.org/exim-team/exim4.git
  git pull debian-upstream master

  # Upstream als eigener Branch
  # --orphan, weil der nichts mit unserem Debian-master-Branch zu tun hat
  # rm -rf, damit die Dateien aus dem master uns nicht in die Quere kommen
  git checkout --orphan upstream
  git rm -rf debian/
  git remote add exim-upstream git://git.exim.org/exim.git
  git pull exim-upstream master # oder ein anderer Branch/Tag

  # und jetzt beides zusammenkippen
  # git meckert wegen "unrelated history", aber genau das wollen wir ja
  # der Parameter sollte nur beim allerersten Zusammenfügen relevant sein
  git checkout master
  git merge upstream --allow-unrelated-histories


Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
"One difference between SuSE and Red Hat is that the former operates in
a country where people don't sue each other over coffee being too hot."
                                                       (Linus Torvalds)

[toc] | [prev] | [next] | [standalone]

#129974

Christian Garbs <mitch@cgarbs.de> wrote:
>   mkdir exim4-deb
>   cd exim4-deb
>   git init
> 
>   # besser wäre git@salsa.debian.org:exim-team/exim4.git als Quelle,
>   # aber das darf ich nicht lesen ;-)
>   git remote add debian-upstream https://salsa.debian.org/exim-team/exim4.git
>   git pull debian-upstream master
> 
>   # Upstream als eigener Branch
>   # --orphan, weil der nichts mit unserem Debian-master-Branch zu tun hat
>   # rm -rf, damit die Dateien aus dem master uns nicht in die Quere kommen
>   git checkout --orphan upstream
>   git rm -rf debian/
>   git remote add exim-upstream git://git.exim.org/exim.git
>   git pull exim-upstream master # oder ein anderer Branch/Tag
> 
>   # und jetzt beides zusammenkippen
>   # git meckert wegen "unrelated history", aber genau das wollen wir ja
>   # der Parameter sollte nur beim allerersten Zusammenfügen relevant sein
>   git checkout master
>   git merge upstream --allow-unrelated-histories

Was spricht eigentlich gegen:

#v+
git clone -o debian-upstream https://salsa.debian.org/exim-team/exim4.git exim4-deb
cd exim4-deb
git remote add exim-upstream git://git.exim.org/exim.git
git fetch --all
git merge exim-upstream/master --allow-unrelated-histories
#v-

Gruß,
Enrik

[toc] | [prev] | [next] | [standalone]

#130065

Mahlzeit!

Enrik Berkhan <Enrik.Berkhan@inka.de> wrote:

> Was spricht eigentlich gegen:
> 
> #v+
> git clone -o debian-upstream https://salsa.debian.org/exim-team/exim4.git exim4-deb
> cd exim4-deb
> git remote add exim-upstream git://git.exim.org/exim.git
> git fetch --all
> git merge exim-upstream/master --allow-unrelated-histories
> #v-

Sehr schön aufgeräumt!

Da dürfte auch das Problem mit dem "herumliegenden" debian/
automatisch wegfallen.

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
I always find that when I’m sleepy, it is best to go somewhere quiet and
take a nap.

[toc] | [prev] | [next] | [standalone]

#132850

Enrik Berkhan <Enrik.Berkhan@inka.de> wrote:
>#v+
>git clone -o debian-upstream https://salsa.debian.org/exim-team/exim4.git exim4-deb
>cd exim4-deb
>git remote add exim-upstream git://git.exim.org/exim.git
>git fetch --all
>git merge exim-upstream/master --allow-unrelated-histories
>#v-

das führt zu einem aktuellen kombinierten git mit halbwegs schlüssiger
History, ist aber nicht so ganz das was ich will. Erstens sind die
historischen Debian-Tags weiterhin nur die reinen
"debian"-Verzeichnisse und damit nicht mit den normalen Prozessen
baubar, und zweitens hat man in einem "richtigen" Debian Repository
üblicherweise nicht die volle Upstream-History, sondern nur die
Upstream-Schnappschüsse (gerne aus Release-Tarballs importiert), die
man auch wirklich paketiert hat.

Hier z.B. gensio, mein "neuestes" Paket mit überschaubarer History:
|[89/4684]mh@drop:~/packages/gensio/gensio (master|u=) $ git tag | cat
|debian/2.2.0-1
|debian/2.2.0-2
|debian/2.2.3-1
|debian/2.2.3-2
|debian/2.2.4-1
|debian/2.3.5-1
|debian/2.5.1-1
|debian/2.5.1-2
|debian/2.6.2-1
|debian/2.6.2-2
|debian/2.6.2-3
|debian/2.6.2-4
|debian/2.6.6-1
|upstream/2.2.0
|upstream/2.2.3
|upstream/2.2.4
|upstream/2.3.4
|upstream/2.3.5
|upstream/2.5.1
|upstream/2.6.1
|upstream/2.6.2
|upstream/2.6.6
|[90/4685]mh@drop:~/packages/gensio/gensio (master|u=) $ 

der Upstream-Tarball wird im Upstream-Branch importiert und der
Release getagged. Das macht man mit dem Tool gbp import-orig, und ich
weiß gar nicht genau was das macht, die Doku sagt nur "The sources are
placed on the upstream branch, tagged and merged onto the debian
branch." Die Doku setzt dann fort, dass für ein Paket in 3.0 (quilt)
Format ein neuer Tree aus der neuen upstreamversion plus das
debian-Directory gebaut wird.

Ich hab mich jetzt ein bisschen mit git-buildpackage beschäftigt,
Guido hat da ziemlich viel Hirnschmalz investiert und etliche
python-Klassen gebaut, mit denen man Debian-Repositories bearbeiten
kann. Ich denke, um zu meinem Ziel zu kommen nutze ich am besten diese
Klassen und schreibe meinen eigenen Python-Code.

Im Prinzip könnte man vermutlich auch die ganze Upstream-History in
den upstream-Branch importieren, und an den Stellen wo Upstream
releast hat einen Tag setzen. Dann muss man sich noch durch die
Debian-History durchfräsen und dort, wo ein Debian-Tag gesetzt ist an
die entsprechende Stelle im Upstream-Tree gehen und dort die Übung
"neuer tree, entsprechendes debian-Verzeichnis history-erhaltend
dazunehmen, Debian-Tag setzen" spielen.

Dann habe ich nur noch das Problem, dass ich Andreas' Arbeitsweise,
dass ein neues Debian-Release in aller Regel nur ein Commit ist, das
u.a. auch das Debian-Changelog gleich mit beinhaltet, so gar nicht
schön finde. Aber ich bin auch zu lange aus dem Exim-Maintaining
draußen als dass ich Andreas vorschreiben könnte wie er zu arbeiten
hat. Ich fürchte, der Debian-Exim-Zug ist aus ganz verschiedenen
Gründen für mich abgefahren.

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web