3 ms·
So this, to me, is not a 'benefit of git' it articulates in some ways how bad it is (although very powerful). Most people can get going with those 99% commands
by jariel 6y ago
So this, to me, is not a 'benefit of git' it articulates in some ways how bad it is (although very powerful).
Most people can get going with those 99% commands quite quickly, the problem with git is any move from the known path creates some pretty amazingly complicated scenarios.
And those '1% of the time' commands blow up into time-consuming rabbit holes of complexity. Often, Stack Exchange has several answers for the same question, highlighting just how much inherent complexity there is in the product.
Managing software versions across repo can be a very, very complicated problem. Git provides you with a pile of tools to do 'almost anything'.
A 'well designed product' would make the toolsets and concepts focus heavily on the 'main operations' and then have clear, clean rational idioms, practices and tools for the odd cases, and 'dangerous cases' wouldn't be allowed without some kind of special command.
They have the 'Golden Rule of Git' which is to not rebase on a public branch - this is an excellent example of poor product design. There should be no 'golden rule' that developers have to understand - it shouldn't be possible (without special admin commands). If branches are named/tagged and managed properly, the system would be smart enough to let you know you can't do that, and why.
Administrators exist for a reason, 'sudo' exists for a reason etc.
People who love powerful things, and have an inclination towards complexity seem to love git, people who have a product orientation see it differently.
- jamienicol 6y agoYou can't push a rebased branch without`--force`, and the server can be configured to disallow it entirely. This is exactly how it should be: I want to be able to rebase my by public branches but not the public branch.
- jariel 6y ago" I want to be able to rebase my by public branches but not the public branch." Already that's a little bit complicated though. Even though yes, this use case probably does exist, it might be a tricky thing to unwind for some people - what would they do when they have already changed the history of 'their' public branch (?) is something they'd have to carefully think about.
- aulin 6y agoyou shouldn't change history once you make it public, how hard is that? that's the golden rule, if you promise something to be immutable, stick to your promise
- outsomnia 6y agoTags are immutable. Branches are mutable. You can add to them and refactor patch series that are on them, equally valid in the eyes of git. For example a development branch has no implied "promise" about stability of its history, it is much better to not only refactor the code but also refactor the history so sub-patches are squashed into the single feature patch that they logically belong to, and not spawn lives of their own. There is no reason to run that kind of development branch like a stable "branch of record".
- jariel 6y ago'Don't shoot yourself in the foot with a gun - how hard can that be to understand'? And yet people do it all the time. The 'rule' is easy enough to understand. But it's not always clear 'why' that is (in many cases, it won't matter), or when exactly it applies. In the lowest common denominator cases, the rule is not so hard to follow, but it can get messy quickly and there are many ways to break the rule.
- lttlrck 6y agoStack exchange has multiple answers for most questions. It's not a useful metric; the domain is inherently complex. git has warts, like c++, go, react, npm, rust and all their cousins. It comes with the territory. We're dealing with tools borne into world where they are, more and more, expected to be suitable for any purpose. Tough mandate, and not the tools fault. One day git will be supplanted with something that has a different set of issues. Progress.