git isn't as solid as people believe.

Yes, it's used by million of companies. But it's not so solid

Not if it's used by a person with a liquid brain.

Git is allegedly the "stupid content tracker", so it is not surprising.

What do you mean by solid?

It maintains very high guarantees of reliability and I've never encountered a bug. It's also not inherently networked so the underlying infrastructure is thin and has similarly high guarantees of reliability.

There are also several failsafes to ensure that when a user mistake produces unintended state, the data is usually recoverable and the user can decide whether their data is important enough to find an expert or they would prefer to experiment further.

If I had to guess what solidity means, stating guarantees in design and meeting them in implementation even with respect to user error would be it, though I don't use this term.

We can all agree that git UX is garbage

@WildOrangutan not if you use a UI client like Fork

@lorentz what about being able to push a different history to remote without `--force` and the previous versions not being recoverable (if not through previous tags)?

@crisz A different history does not include your current history, obviously. The fact that data becomes inaccessible is also why you need --force. If you want to recover it locally, use the reflog. If you want the old history to be accessible on the remote, either create and push a new branch (like devel/legacy) in advance or push the one you've recovered using the reflog after the fact.

I'm not sure whether servers have a reflog, I don't think they do.

@lorentz what if a coworker changes the history by mistake in his own branch and pushes it to remote, then I merge his branch to master?

One would say "well you merged his branch, you should notice that something changed", but no. If you execute "git status" then it will say that there are no changes, since git has no way to calculate the diff.

If I execute "git push" I will push the changed history, with all the different files, to master. And eventually deploy if I have a CI/CD system.

If the other developers execute "git pull" they will also have a changed history, and there will be no way to restore the correct version. "git reflog" is just a command that can save your ass if you messed up your things locally, but it just works locally.

This changed history may have as many different files as you want, and you have no way to merge the changes of your coworker without messing everything up

There's no "rebase", no "cherry-pick", nothing really worked. In the end, after spending something like 6 hours on this problem I just copied and pasted his changes and it worked as a charm

@ALMST
Bad code 429. {
"error": {
"message": "You exceeded your current quota, please check your plan and billing details.",
"type": "insufficient_quota",
"param": null,
"code": null
}
}

I forgot to say: not a single "--force" was involved in the process. I swear. Not a single "--force".

@crisz Interesting, doesn't pull initiate a merge when the two histories diverge?

I've seen pull straight up fail, initiate a merge, and rebase the local branch, in various clients. Never seen it silently drop commits though.

@lorentz let's say it didn't drop any commit. It just inserted some unwanted commit in the middle of the history (which is one decade long, and not pretty easy to manage and spot the unwanted commits)

@crisz If the unwanted commit has no perceiveable effect and the history isn't well managed, it can just stay there. If it causes some problems, the problematic aspects can be filtered for. A lot of GUIs can filter for changes to lines, or on the command line you can use bisect.

I never properly learned bisect but it's a pretty intuitive operation so I did re-implement it once on accident.

I highly disagree with the OP and agree with @lorentz.
Git is a stupid and solid content tracker.
Allowing access and operations that are powerful yet potentially dangerous does not make it less solid. The scenario you describe has nothing to do with the tool but with extra controls you want in place in a specific setup.

You can say the same thing about any database technology. A user can remove the directory that holds all the data. An admin user can clear the database (using drop in SQL for example). That does not say anything about solidity.

If it would fail to do content tracking and introduce corruptions it would be not solid.

@hjk101 Not speaking for OP, but I'd agree it's not "solid" in the sense that "solid" means that it's REALLY easy for people to screw up with it.

And the response that "well, it's always recoverable if you expend enough calories trying" doesn't work for me because a core tenant of good UX - distinct from UI - is that it should be difficult to make mistakes. Git makes it ridiculously easy to make mistakes while simultaneously making it (often) very difficult to recover, so the fact that you ultimately CAN recover doesn't erase the ease with which you had to in the first place.

And I think it all comes down to complexity. The underlying IMPLEMENTATION is indeed pretty simple, but the interface on top of it is anything but. It has WAY too many features, it makes a lot of assumptions that are wrong for a lot of teams (being distributed at the top of the list) and is a house of cards that collapses with just a minor... ahem... push.

Nice to read

@fzammetti git is dependable and reliable. That is one of the meanings of solid. Another meaning has to do with state.

Trying to make solid work here is like arguing that a slab of metal is not solid because if you apply enough --force it will bend! But bend metal is still not gas or liquid... Let's stick to truth here and not redefine words.

Also I still disagree with the what you wrote. The basic usage of git is append only with the hardest thing being merge conflicts. With 4 (no branching) to 6 commands you can have complete nitwits working with it safely. Anything else and you come in the realm of history rewriting. This is an advanced topic and just doing some stuff you don't understand gets you into a hot mess real fast. Just as altering database schemas does. Just as hitting ctrl+a;shift+delete in outlook does.

I would shift the discussion to a more important point.

GIT is a tool.

How you use the tool aka your workflow makes it either simple and efficient or tedious and nefarious.

E.g. pushing a wrong history to remote... I'm not sure how you would be able to do that if the remote only accepts fast forward updates.

So yes, GIT allows a lot of certain, different workflows - some might melt your face off, others not.

Completely right.

You can use a knife to smear butter on bread, you can take a knife and gauge someone's eye balls out.

Use of the tool is entirely dependent on you.

It doesn't make the tool good or bad, imho.

Imho a lot of problems could be avoided if the admins did their job and would set the right settings on the remotes so you can't do certain workflows which might melt your face off.

Rewriting history is exactly a thing that shouldn't be used unless absolutely required. Especially not in productive branches for a CI / CD - as loosing / rewriting history means entirely fucked versioning.

Facebooks sapling goes into the direction of a unified workflow with better UI / UX.

Most likely exactly for the arguments given here: When choice exist, humans tend to be unwilling to compromise... (Not meant offensively, but boy I had the discussion of "No I did it always like that, don't want to change" too many times).

But this is true for anything, really anything.

It's important to restrict workflows in my opinion for the greater good.

Why write a custom code formatting guideline when you can just take an official one... As one example.

GIT allows a lot of things, that never means you should use them all.

Write a workflow that is safe and usable, GIT becomes a breeze.

Use branches.

Fucked up? Checkout from remote, start again.

Don't mess with reflog, don't use force pushing. Just cause it exists doesn't mean it has to be used.

@lorentz no, GUIs just use the above commands under the hoods and present the same problems. Using vscode I just had the correct outgoing files (as git status says), but once I prepared the commit it started showing extra files that in "git status" weren't present (as git diff says). So there's no gain in using a GUI. And I don't understand how "git bisect" would solve this problem, the history got messed up by inserting a lot of random commits in random positions in the history, how is supposed "git bisect" to solve this?

@hjk101 yes but no "--force" was involved, all this mess was caused with the minimum privileges. You can't really trust everyone has a git account with minimum privileges in a large company

@crisz git has no concept of accounts and it doesn't have to. Nor does it have ci:cd. It's just a solid foundation that is simple and stable enough you can set up all kinds of workflows and strategies. Much like @IntrusionCM layed out.
From my first comment I was afraid it was regarding additional controls. And again database technology like sqlite also don't have this. Yet someone replacing data or layout can mess things up seriously. However with databases it's always the Devs fault and for some reason with git is always git's fault.

You say no force was involved but history was rewritten. I highly doubt that but if this was truly the case nobody used force and yet the history got rewritten then you are right. You have encountered a bug and there is a rocky git version in use.

@hjk101 I don't think that I encountered a bug, I think that git is unsafe by design because of historical reasons.

I also think that the solidity of a tool is seen when there are problems, not when everything is alright

the word solid isn't as solid as people believe.

Yes, it's used by million of people. But it's not so clear what that even means.

@fullstackclown after a rather long read, skipping over a fair amount, that was just beautiful... 😂🖖

@crisz I'd like to know what git command inserts a lot of commits in random places, it sounds like a prime trolling device. Also changing history like that "drops" newer commits even if the same diffs are still present under different hashes, so it still requires --force.

I think your coworker screwed up, issued a day's worth of random commands from the internet to try and fix it, and either intentionally or accidentally pushed the result with --force, then denied the whole thing. This still doesn't explain why everyone in a team has a destructive pull policy though. One of git's numerous failsafes is that every developer's instance works as a backup. Throwing this away would be pretty stupid.

@crisz "unsafe by design" is EXACTLY the right way to put it. It's way too easy to get in a bad spot with Git even if you only ever do "simple" things.

@hjk101 Yeah, but if there was a way to bend that slab of metal by applying very little force then we'd say the metal wasn't solid, wouldn't we? I've seen very good professional developers mess things up SO many times with Git at this point that it's almost like there's a cheat code to bend the chunk of metal, and it often doesn't require doing much beyond the 4-5 "basic" commands you alluded to.

I contrast this with my years of experience with SVN before - which to be fair has its own flaws, some of which Git improves upon - and I rarely saw the same level of "oops" that I do with Git.

You know the old joke, right? "How do you recover from a Git problem? You copy out your changes, re-clone, copy in your changes, sacrifice a goat, and try to push again". It's a joke that has a very real basis in truth, so much so that it's almost a best practice at this point.

Someone else said it best: Git is unsafe by design. It's too easy to mess up with, hence it is not "solid".

@fzammetti I can see your point of view, still don't think that git is unreliable (the opposite of solid) but we can simply agree on difference of opinion and perhaps even experiences here.

I do have a problem with the "Git is unsafe by design" quote. This is ripped out of context and does not support your point at all: it is about using git itself as a security model to prevent tampering etc.

@hjk101 That's fair, maybe I did (unintentionally) misappropriate that quote :) I do stand by opinion as it relates to that, but agree to disagree. Good, healthy debate in any case, much appreciated, have a good weekend!

@fzammetti thanks for the interesting discussion! Nice to reflect upon the tools of our trade once in a while and git seems to have created a dominant place. Perhaps it will be overthrown one day based on the gripes many of us have here. Have a happy Easter!

@fzammetti I totally agree. Let's say I consider myself an experienced developer and I've used git for 10 years now. Still get in troubles, especially in edge-cases scenarios like having more remotes (you can easily push the code of a remote into the wrong remote and that problem is not easily recoverable)