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

Groups > de.comp.os.unix.linux.misc > #129249

Re: git

Show all headers | View raw

On Sat, 11 Mar 2023 23:23:03 +0100
"Peter J. Holzer" <hjp-usenet3@hjp.at> wrote:

> On 2023-03-11 20:19, Andreas Dehmel
> <blackhole.8.zarquon42@spamgourmet.com> wrote:
> > On Sat, 11 Mar 2023 20:33:17 +0100
> > "Peter J. Holzer" <hjp-usenet3@hjp.at> wrote:  
> >> On 2023-03-11 17:15, Andreas Dehmel  
> > [...]  
> >> > 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.  
> >
> > Ich verwende es seit Jahren zwangsläufig in meiner täglichen Arbeit
> > und finde es immer noch beschissen (damit bin ich auch bei weitem
> > nicht der einzige). Allein die Tatsache, daß es n-1 Sandboxen
> > inkonsistent machen und schlimmstenfalls schrotten kann, wenn ein
> > Entwickler Mist push'd, wird für mich immer ein KO-Kriterium
> > bleiben; etwas derartiges ist unter svn nie passiert.  
> 
> Ich weiß nicht, was ihr da macht und was in dem Kontext mit "Sandbox"
> und "inkonsistent" gemeint ist, aber Subversion war meiner Erfahrung
> nach nicht besser darin, zu verhindern, dass irgendwer Blösinn
> committet. Eher im Gegenteil - da Branching und Merging so umständlich
> war, haben alle immer im Master gearbeitet und sind sich entsprechend
> auf die Zehen gestiegen.

Ich rede nicht von den üblichen Problemen wie falschen merges, die beim
Arbeiten mit jeder Quellcodeverwaltung auftreten und überall genau
gleich schwer zu behandeln sind. Sondern von den Dingen, die passieren,
wenn Leute, die wesentlich weniger Ahnung haben, als sie sich
einbilden, mit Aktionen wie z.B. rebase anfangen und dann u.U. einen
Zustand committen (und v.a. committen _dürfen_), auf den sich der Rest
der Entwicklung nicht mehr ohne manuelle Anpassungen aktualisieren
kann, da widersprüchlich. Eine Quellcodeverwaltung wüßte sowas zu
verhinden. git ist... irgendwas anderes, aber die Kinder stehen voll
drauf.

> Es gibt natürlich immer ein paar Spezialisten, die ein Git Repo in
> einen Zustand bringen können, wo man sich fragt, wie sie denn das
> geschafft haben: Aber die haben das auch mit Subversion geschafft,
> und da war es schwerer zu reparieren.

Falsch. Die ganzen Rebase-Folgeprobleme kannst du unter svn aus
offensichtlichen Gründen generell nicht erzeugen. Inkonsistente
Repos sind mir in all den Jahren der svn Entwicklung auch nie
untergekommen, während man bei git schon bei einem unfangreicheren
merge schnell in die Situation kommt, daß Repo wegschmeißen und von
vorne anfangen schneller geht, weil man erst mal weder vor- noch
rückwärts kommmt. Und dann sind da noch die unzähligen Perlen, wie daß
das pushen eines neuen Branches ohne nachvollziehbare Gründe
fehlschlägt, bis man einen purge macht, dann geht's auf wundersame
Weise plötzlich, die mein Vertrauen in diese "Quellcodeverwaltung"
nicht gerade steigern.



Andreas

Back to de.comp.os.unix.linux.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web