Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.os.unix.linux.misc > #129224 > unrolled thread
| Started by | Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> |
|---|---|
| First post | 2023-03-11 18:15 +0100 |
| Last post | 2023-03-17 16:41 +0100 |
| Articles | 10 on this page of 50 — 10 participants |
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.
Re: git Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> - 2023-03-11 18:15 +0100
Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-11 20:33 +0100
Re: git Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> - 2023-03-11 21:19 +0100
Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-11 23:23 +0100
Re: git Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> - 2023-03-12 15:04 +0100
Re: git Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-03-12 16:41 +0100
Re: git Thomas Hochstein <thh@thh.name> - 2023-03-12 17:52 +0100
Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-12 19:37 +0100
Re: git Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2023-03-12 19:22 +0000
Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-12 21:05 +0100
Re: git Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2023-03-13 22:02 +0000
Re: git Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-03-13 08:09 +0100
Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-13 19:05 +0100
Re: git Arno Welzel <usenet@arnowelzel.de> - 2023-03-17 16:53 +0100
Re: git Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-03-18 09:17 +0100
Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-19 10:07 +0100
Re: git Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-03-19 10:50 +0100
Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-19 11:23 +0100
Re: git Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-03-19 15:21 +0100
Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-20 07:15 +0100
Re: git Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-03-20 07:34 +0100
Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-20 12:27 +0100
Re: git Enrik Berkhan <Enrik.Berkhan@inka.de> - 2023-03-20 17:31 +0000
Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-17 21:01 +0200
Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-20 18:37 +0100
Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-23 18:05 +0100
Re: git Christian Garbs <mitch@cgarbs.de> - 2023-03-23 20:09 +0000
Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-17 21:00 +0200
Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-24 18:46 +0100
Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-17 20:59 +0200
Re: git Arno Welzel <usenet@arnowelzel.de> - 2023-07-18 00:45 +0200
Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-08-06 13:30 +0200
Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-08-06 15:53 +0200
Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-08-07 18:23 +0200
Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-08-07 18:58 +0200
Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-07-18 18:40 +0200
Re: git Christian Garbs <mitch@cgarbs.de> - 2023-03-20 20:35 +0000
Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-23 18:06 +0100
Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-20 18:41 +0100
Re: git Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-03-21 18:30 +0100
Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-23 17:45 +0100
Re: git Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-03-24 00:11 +0100
Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-25 07:40 +0100
Re: git Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-03-25 08:38 +0100
Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-12 09:57 +0100
Re: git Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-03-12 10:27 +0100
Re: git Thomas Hochstein <thh@thh.name> - 2023-03-12 12:29 +0100
Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-12 14:17 +0100
Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-12 07:34 +0100
Re: git Arno Welzel <usenet@arnowelzel.de> - 2023-03-17 16:41 +0100
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2023-03-23 17:45 +0100 |
| Message-ID | <tvhvo1$ldnn$1@news1.tnib.de> |
| In reply to | #129504 |
Dietz Proepper <dietz.usenet@rotfl.franken.de> wrote: >Stefan Reuther <stefan.news@arcor.de> wrote: > >> Am 18.03.2023 um 09:17 schrieb Dietz Proepper: >> > Arno Welzel <usenet@arnowelzel.de> wrote: >> >> Git ist ein Werkzeug, dass man beherrschen sollte. >> > >> > Nun, ich erlaube mir bei Bewerbern gerne, den Begriff git plumbing >> > oder git porcelain einzuwerfen. "Was ist das?" ist keine gute >> > Antwort. >> >> Ist das noch relevant? > >Wenn sich wer als mit allen Wassern gewaschener git-Profi ausgeben will? Dann würde ich mir von dem wohl lieber erklären lassen, was die verschiedenen Merge-Strategien beim Rebase sind und warum "theirs" und "ours" sowohl als Merge-Strategie als auch als vorgegebene Lösung verwendet wird UND warum das beim rebase genau andersrum anzugeben ist als beim Merge. Und dann noch, welche Strategie und welchen Workflow verwenden sollte, wenn man merge-commits vermeiden möchte und möglichst viel fast-forward merges machen möchte. 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]
| From | Dietz Proepper <dietz.usenet@rotfl.franken.de> |
|---|---|
| Date | 2023-03-24 00:11 +0100 |
| Message-ID | <20230324001111.6d8e423c.dietz.usenet@rotfl.franken.de> |
| In reply to | #129634 |
Marc Haber <mh+usenetspam1118@zugschl.us> wrote: > Dietz Proepper <dietz.usenet@rotfl.franken.de> wrote: > >Stefan Reuther <stefan.news@arcor.de> wrote: > >> Am 18.03.2023 um 09:17 schrieb Dietz Proepper: > >> > Nun, ich erlaube mir bei Bewerbern gerne, den Begriff git > >> > plumbing oder git porcelain einzuwerfen. "Was ist das?" ist > >> > keine gute Antwort. > >> > >> Ist das noch relevant? > > > >Wenn sich wer als mit allen Wassern gewaschener git-Profi ausgeben > >will? > > Dann würde ich mir von dem wohl lieber erklären lassen, was die > verschiedenen Merge-Strategien beim Rebase sind und warum "theirs" und > "ours" sowohl als Merge-Strategie als auch als vorgegebene Lösung > verwendet wird UND warum das beim rebase genau andersrum anzugeben ist > als beim Merge. Ich hatte nicht geschrieben dass dies die einzige Frage sei. Und ja, ein Teil des Zwecks solcher Fragen ist eben auch zu sehen, wie der Kandidat reagiert.
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2023-03-25 07:40 +0100 |
| Message-ID | <tvm50h$vejt$1@news1.tnib.de> |
| In reply to | #129660 |
Dietz Proepper <dietz.usenet@rotfl.franken.de> wrote: >Marc Haber <mh+usenetspam1118@zugschl.us> wrote: > >> Dietz Proepper <dietz.usenet@rotfl.franken.de> wrote: >> >Stefan Reuther <stefan.news@arcor.de> wrote: >> >> Am 18.03.2023 um 09:17 schrieb Dietz Proepper: >> >> > Nun, ich erlaube mir bei Bewerbern gerne, den Begriff git >> >> > plumbing oder git porcelain einzuwerfen. "Was ist das?" ist >> >> > keine gute Antwort. >> >> >> >> Ist das noch relevant? >> > >> >Wenn sich wer als mit allen Wassern gewaschener git-Profi ausgeben >> >will? >> >> Dann würde ich mir von dem wohl lieber erklären lassen, was die >> verschiedenen Merge-Strategien beim Rebase sind und warum "theirs" und >> "ours" sowohl als Merge-Strategie als auch als vorgegebene Lösung >> verwendet wird UND warum das beim rebase genau andersrum anzugeben ist >> als beim Merge. > >Ich hatte nicht geschrieben dass dies die einzige Frage sei. Und ja, >ein Teil des Zwecks solcher Fragen ist eben auch zu sehen, wie der >Kandidat reagiert. Und wieder hab ich eine Gelegenheit verpasst von Dir was über git zu lernen ;-) 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]
| From | Dietz Proepper <dietz.usenet@rotfl.franken.de> |
|---|---|
| Date | 2023-03-25 08:38 +0100 |
| Message-ID | <20230325083826.4388a73c.dietz.usenet@rotfl.franken.de> |
| In reply to | #129690 |
Marc Haber <mh+usenetspam1118@zugschl.us> wrote: > Dietz Proepper <dietz.usenet@rotfl.franken.de> wrote: > >Ich hatte nicht geschrieben dass dies die einzige Frage sei. Und ja, > >ein Teil des Zwecks solcher Fragen ist eben auch zu sehen, wie der > >Kandidat reagiert. > > Und wieder hab ich eine Gelegenheit verpasst von Dir was über git zu > lernen ;-) Oh, mein momentan abrufbares git ist überschaubar - Sachen, die ich mal drei Monate nicht mache vergessen die Finger ;-).
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2023-03-12 09:57 +0100 |
| Message-ID | <tuk7mh.508.1@stefan.msgid.phost.de> |
| In reply to | #129228 |
Am 11.03.2023 um 20:33 schrieb Peter J. Holzer: > On 2023-03-11 17:15, Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> wrote: >> On 10 Mar 2023 12:46:19 GMT >> ram@zedat.fu-berlin.de (Stefan Ram) wrote: >>> Ich möchte "git" einsetzen, aber die üblichen Einführungen in >>> git sind für mich unübersichtlich. >> >> Nachdem du recht einfache Anforderungen hast, würde ich mir eher svn >> anschauen. > > Äh, nein. SVN war im Vergleich zu CVS ein Fortschritt (großteils), aber > ich will dahin nicht zurück, auch für Einpersonenprojekte nicht. Ach komm, SVN kann doch nicht mal Branches oder Tags. Wir lachen darüber, wenn jemand "Diplomarbeit_2023_final_V3_AnmerkungenMM.doc" macht, aber am Ende ist "Taggen" in SVN genau das gleiche. Auf dem Firmen-SVN gibt es zahllose Branches mit einem "trunk"-Verzeichnis drin, denn auf das entsprechende Kommando sagt SVN nicht "den Branch gibt's schon", sondern kopiert das strunzdumm rein. Privat hab ich SVN übersprungen; aus CVS bekomm ich immerhin im Notfall mit einem Editor noch Inhalt raus. >> git hat eigentlich nur Vorteile bei Dingen wie massiv >> parallelem Arbeiten ohne Netzwerkverbindung zum Master-Repo und >> lightweight branching, alles Dinge für eine größere Zahl an Entwicklern, >> als Quellcodeverwaltung ist git eine ziemliche Katastrophe. > > Es gibt eigentlich nichts, was SVN besser kann als Git. Zugegeben, ich > habe ein bisschen gebraucht, um mich daran zu gewöhnen (ich habe mit > SCCS ca. 1988 angefangen, und SCCS -> RCS -> CVS -> SVN war eine recht > natürliche Evolution, Git hat ganz andere Konzepte), aber wenn man es > mal regelmäßig verwendet, lernt man es zu schätzen. Der springende Punkt ist, zu verinnerlichen, dass man in git die Geschichte umschreiben kann und gelegentlich auch muss. Mit CVS oder SVN ist ein Commit endgültig. In git kann ich Commits noch ändern (rebase, commit --amend). Aktionen anderer Leute auf dem Server können mich sogar dazu zwingen, dies zu tun (git rebase origin/master). [was in git nicht geht] > 2) Keyword Expansion. Macht git nicht, wenn man also z.B. die > Versionsnummer in einem Script haben will, muss man das in den > Install-Prozess einbauen. Wenn man einmal mit Mühe und Not einen Merge überlebt hat, will man Keyword Expansion auch eigentlich nicht haben. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Dietz Proepper <dietz.usenet@rotfl.franken.de> |
|---|---|
| Date | 2023-03-12 10:27 +0100 |
| Message-ID | <20230312102741.1ef3daf4.dietz.usenet@rotfl.franken.de> |
| In reply to | #129241 |
Stefan Reuther <stefan.news@arcor.de> wrote: > Am 11.03.2023 um 20:33 schrieb Peter J. Holzer: > [was in git nicht geht] > > 2) Keyword Expansion. Macht git nicht, wenn man also z.B. die > > Versionsnummer in einem Script haben will, muss man das in den > > Install-Prozess einbauen. > > Wenn man einmal mit Mühe und Not einen Merge überlebt hat, will man > Keyword Expansion auch eigentlich nicht haben. Und sollte man doch mal keyword expansion wollen - Precommit-Hooks sind Persons Freund. (Und wenn man das mal eine Zeitlang gemacht hat dann lässt man es freiwillig. Gibt andere Verfahren, dies zu bewerkstelligen.) -- I'm Wally and I identify as a guy who doesn't use the right pronouns.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Hochstein <thh@thh.name> |
|---|---|
| Date | 2023-03-12 12:29 +0100 |
| Message-ID | <dcoulm.20230312122921.336@scatha.ancalagon.de> |
| In reply to | #129241 |
Stefan Reuther schrieb: > Am 11.03.2023 um 20:33 schrieb Peter J. Holzer: > [was in git nicht geht] >> 2) Keyword Expansion. Macht git nicht, wenn man also z.B. die >> Versionsnummer in einem Script haben will, muss man das in den >> Install-Prozess einbauen. > > Wenn man einmal mit Mühe und Not einen Merge überlebt hat, will man > Keyword Expansion auch eigentlich nicht haben. Selbstverständlich kann git Keyword-Expansion; man muss es sich halt bauen, wenn man das braucht. Richtig ist, dass es (außer mit $Id$) nicht out-of-the-box funktioniert; andererseits bieten die Filter mächtige Möglichkeiten. <https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#_keyword_expansion> Üblicherweise wird man Release sowieso via "git archive" erzeugen. Da eröffnet dann <https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#_export_subst> sehr einfache Möglichkeiten, um alles, was "git log --pretty" bietet, einzufügen. Seit git 2.32 (2021) gibt es dort "%(describe)" als Option, also sollte etwas in der Art wie | Version: $Format:%(describe)$ ausreichen, um beim Durchlauf von "git archive" dort die Beschreibung des Commits einzufügen, aus dem man das Release erzeugt. [1] Hat dieser Commit ein Tag mit der Versionsnummer, was sich ja ohnehin anbietet, erscheint genau diese. | thomas@scatha MINGW64 | $ git log -1 --pretty='%(describe)' | 1.5.7 -thh [1] Vorausgesetzt, es gibt eine .gitattributes-Datei, in der allen Dateien, bei denen das passieren soll, das Attribut "export-subst" zugewiesen ist.
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet3@hjp.at> |
|---|---|
| Date | 2023-03-12 14:17 +0100 |
| Message-ID | <slrnu0rk7h.7nk.hjp-usenet3@trintignant.hjp.at> |
| In reply to | #129244 |
On 2023-03-12 11:29, Thomas Hochstein <thh@thh.name> wrote:
> Stefan Reuther schrieb:
>> Am 11.03.2023 um 20:33 schrieb Peter J. Holzer:
>> [was in git nicht geht]
>>> 2) Keyword Expansion. Macht git nicht, wenn man also z.B. die
>>> Versionsnummer in einem Script haben will, muss man das in den
>>> Install-Prozess einbauen.
>>
>> Wenn man einmal mit Mühe und Not einen Merge überlebt hat, will man
>> Keyword Expansion auch eigentlich nicht haben.
>
> Selbstverständlich kann git Keyword-Expansion; man muss es sich halt
> bauen, wenn man das braucht.
Mein Vertrauen, dass das die windows-verwendenden Kollegen hinbekommen,
ist begrenzt.
><https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#_keyword_expansion>
>
> Üblicherweise wird man Release sowieso via "git archive" erzeugen. Da
> eröffnet dann
><https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#_export_subst>
> sehr einfache Möglichkeiten, um alles, was "git log --pretty" bietet,
> einzufügen.
Das ist praktikabler, fällt für mich aber unter "muss man das in den
Install-Prozess einbauen". Und ob ich dort ein Script einbaue, das ein
Source-File erzeugt bzw. modifiziert oder einen Archive-Schritt mit
Substitution macht für mich keinen wesentlichen Unterschied.
> Seit git 2.32 (2021) gibt es dort "%(describe)" als Option,
Das ist in manchen aber nicht allen von mir betreuten Distributionen
schon enthalten. Ich muss mir also bei jedem Repo Gedanken machen, ob
ich es dort schon einsetzen kann.
Aber prinzipiell: Guter Tipp, wird in den Werkzeugkasten aufgenommen und
bei Bedarf (und wenn möglich) eingesetzt.
hp
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2023-03-12 07:34 +0100 |
| Message-ID | <tujrpd$2a6a2$1@news1.tnib.de> |
| In reply to | #129224 |
Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> wrote: >Nachdem du recht einfache Anforderungen hast, würde ich mir eher svn >anschauen. git hat eigentlich nur Vorteile bei Dingen wie massiv >parallelem Arbeiten ohne Netzwerkverbindung zum Master-Repo und >lightweight branching, alles Dinge für eine größere Zahl an Entwicklern, >als Quellcodeverwaltung ist git eine ziemliche Katastrophe. Und man >kann auch svn über file:// server-less betreiben. Git hat als Quellcodeverwaltung einen Marktanteil von nahe 100 %, git MUSS man können wenn man Open Source machen möchte. Und git ist hinreichend unterschiedlich zu allen anderen versionskontrollsystemen, dass es außerordentlich schwer ist, git und ein anderes System wirklich zu beherrschen. Ich empfehle deswegen git zu lernen. 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]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2023-03-17 16:41 +0100 |
| Message-ID | <k7jg1lFnqakU13@mid.individual.net> |
| In reply to | #129224 |
Andreas Dehmel, 2023-03-11 18:15: > On 10 Mar 2023 12:46:19 GMT > ram@zedat.fu-berlin.de (Stefan Ram) wrote: > >> Ich weiß nicht, ob das die richtige Newsgroup ist, >> bitte gegebenenfalls eine bessere vorschlagen. >> >> Ich möchte "git" einsetzen, aber die üblichen Einführungen in >> git sind für mich unübersichtlich. Ich möchte das Repository >> von git praktisch wie eine Sicherungskopie meiner Textdateien >> verwenden, wobei git speicherplatzschonend vorgehen soll. > [...] > > Nachdem du recht einfache Anforderungen hast, würde ich mir eher svn > anschauen. git hat eigentlich nur Vorteile bei Dingen wie massiv > parallelem Arbeiten ohne Netzwerkverbindung zum Master-Repo und > lightweight branching, alles Dinge für eine größere Zahl an Entwicklern, > als Quellcodeverwaltung ist git eine ziemliche Katastrophe. Und man > kann auch svn über file:// server-less betreiben. Was genau ist bei git denn konkret "eine ziemliche Katastrophe"? Ich arbeite damit seit über 10 Jahren und wüsste nicht, was daran so "katastrophal" sein soll. Hast dazu dazu konkrete Beispiele? "Server-less" ist git ja von Haus aus, indem es seine Daten in das Verzeichnis ".git" schreibt. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | de.comp.os.unix.linux.misc
csiph-web