@GambaJo wie gesagt, meiner Meinung nach ist das Wichtigste das man alte Stände zu 100% wieder herstellen kann. Um auch nachvollziehen zu können wer was wann und warum getan hat.

Mit git kann man die Dateien zurücksetzen, viele Metadaten sind aber verloren. Branches und Tags werden nicht auf die alten Stände zurückgesetzt wenn man einen alten Commit auscheckt. Bei komplexen Projekten, ohne Krücken wie strenge Mergeregeln im Projekt, kann git die Historie nicht komplett wieder herstellen

Damit versagt git in der Kernaufgabe jedes VCS.

Kommt noch dazu das 99% meiner Kollegen sich nie die Mühe machen die Interna der Tools zu lernen, merken die nicht einmal das sie ständig Metadaten vernichten... git macht das aber halt sehr einfach, weil es der default ist.

@GambaJo in der Mitte der Page mal nach "Git is not really about branches" suchen

https://stackoverflow.com/questions/61936264/understanding-the-git-graph

@GambaJo ja ne. Git ist nicht flexibler. Alles was Git da kann, kann hg auch.

Wenn du von Rechner A auf Rechner B pushst (wie gesagt inzw. deaktiviert) kannst da git dazu zwingen Daten auf B zu ändern die nicht commited sind. bei HG gibts einfach einen 2ten Head im Branch - sieht unschön aus ist aber sicher.

"Bei git braucht man keine zentralen Repros." theoretisch nicht, aber selbst die Git Doku redet von nix anderem mehr, weil nur so funktioniert git auch für DAUs die sich nicht mit den Interna beschäftigen.

Auch speichert Git bestimmte Dinge nur in deinem lokalen Reflog. D.h. man kann bestimmte Schritte der Vergangenheit nur an dem Rechner nachvollziehen an dem sie gemacht wurden. bei hg haben alle Repros die volle Info.

@GambaJo Das war das D in DVCS.

hg hingegen hat echte branches, jeder commit weis auf welchem branch er erzeugt wurde. du kannst also Historie zu 100% wieder herstellen. Auch ist das manipulieren des Repros per default abgeschalten. Normale User sollten das auch nicht tun dürfen.

für dich lokal bietet hg auch Wegwerfbranches wie git (die Bookmarks...).

Da hg eine saubere Architektur hat, brauchst du keine zentralen Repros - die sind optional.

Ach ja und shelfs und die Patchqueue von hg sind viel leistungsfähiger als gits staging und stashes...

@GambaJo Git hat ein defektes Branching - branches bei git sind nur Pointer die man bel. manipulieren kann. Commits wissen nicht auf welchem Branch sie erzeugt wurden (hg kann das auch, nennt sich da bookmarks).
Damit gibt es bei git detached heads - das gibts bei hg nicht, je nach dem wie man merged und branches manipuliert kannst bei git nach einiger Zeit nicht mehr sagen wo und warum ein commit erzeugt wurde - git kann dir nur sagen welche aktuellen branchpointer durch den graph eltern eines alten commits sind. Daher gibts so krücken das bestimmte tools immer den branchnamen mit in die Commitmessage schreiben oder sowas wie diese gitflows.

Außerdem kannst du daten zerstören wenn du nicht über ein zentrales repro synchst - daher ist das inzw. per default abgeschalten.

@GambaJo das Wichtigste, was man bei Git verstehen muss, sind die grundlegenden Architekturfehlentscheidungen und warum es daher kein DVCS ist und eigentlich ein ziemlich mieses Tool - verstehen aber nur Leute, die mercurial kennen, dass das alles richtig macht... [und auch als DVCS funktioniert]

Seit wir in der Firma von hg auf git gewechselt sind, hat sich mein zeitlicher Aufwand beim Hantieren mit den Repositorys grob ver50facht.

@nocci wie viel zigtausend Leute glaubst du nutzen Mastodon hier aktiv?

@GambaJo Politiker erzählen ja auch immer noch der Marshall-Plan hätte das Ziel gehabt Deutschland wieder auf zu bauen... Also zu unserem Wohl.