5 ms·

I used git for years now. I’m comfortable with all of the basic functions. It is my experience that I have had several times where merging/branching has caused

I used git for years now. I’m comfortable with all of the basic functions. It is my experience that I have had several times where merging/branching has caused a repo to “break” It doesn’t happen often, but when it does it’s super frustrating and this I avoid the merging workflows where possible. I’m sure if I educate myself a bit more about git and pay more careful attention to the details, I wouldn’t occasionally have this problem, but Git really shouldn’t be like this.

jayshua 3y ago
What does a broken repo look like? What does broken mean here?
appplication 3y ago
Git could be a lot better in a lot of ways, particularly from a developer experience perspective. I’m a little surprised we haven’t seen a meaningful successor. One example is how git will deceive you and tell you you’re up to date with your remote (e.g. origin/main). What it means is that your local branch is up to date with its local concept of remote, and makes no statement guarantees about the actual state of the remote. Which is really a nonsense concept that does not need to exist. Similarly the whole concept of needing to specify “origin” at all is a bit bonkers and does no favors. Why is it that I can pull from a remote branch, commit some changes, run ‘git push’ and git has no idea what branch I want to push to. Another example: if main is a protected branch, don’t let me accidentally commit to it locally. I could keep going with the examples but I won’t. And yeah you can forgive all this by quibbling that git was written in a time when internet access was not ubiquitous, and of course all these decisions make sense because x, y, or z advanced edge case for advanced users only, and I’m a shitty engineer because all of this complexity secretly makes my life better and I’m just too simpleminded to appreciate it. Really though, if you rewrote git from a principles first approach (with developer experience being one of those principles), it certainly would not look like how it looks today. There is too much complexity, too many ways to do things, and too many bad decisions around defaults. Treat it like a proper distributed system, perhaps even backed by a real database. It’s not special because the data is code. The fact that it’s treated as such is the reason it feels so weird.
- TylerE 3y ago
  Blame the Linus Torvalds personality cult. Only way that terrible UX got traction in the first place. If anyone OTHER than Linus had written it, it would have been mocked, and deservedly so.
  - appplication 3y ago
    Yeah, I originally had some Linus snark in there but deleted it. My above comment is being rapidly downvoted though, which is in some sense validating.
  - Yodel0914 3y ago
    That's a pretty big claim. Git solved real problems at the time in a novel and extremely useful way. Coming from SVN (or god forbid VSS), the power and flexibility of git more than made up for its difficulty to grasp. Why it "won" over alternatives with cleaner UX (eg Hg) is a different question, and I think has a lot to do with github.
    - spaniard89277 3y ago
      Git may solve real problems but honestly, it's a PITA to use. Just for basic tasks needs quite a lot time sink to understand what's going on and what do you need to do. It gets in the way of the workflow IMO.
    - TylerE 3y ago
      Mercurial came out essentially simultaneously, solved the same problems, with a much more coherent UX.
      - Yodel0914 3y ago
        Early on, I was definitely a proponent for hg over git. I assumed it would at the very least remain a peer, given how much more sane the UX is. I was wrong though, and I don't think it's just because of github. Named branches being baked in turned out to actually be a real pain in mercurial. Sure, you can use bookmarks (and we did) but starts to quickly feel like you're swimming against the current.
Yodel0914 3y ago
I've been using git for I guess 15 years, on a variety of server platforms (github, atlassian, MS devops, plain ssh) and branching models, with teams of various sizes, and I've never had a repo "break". Branching and merging is what git is amazing at. The worse thing I've had happen is that someone was lazy when merging and just did a "take mine" on 100s of files, thinking that they'd do a "proper" merge later. Of course git doesn't work like that and their lazy merge had to unwound very carefully.
nonethewiser 3y ago
> It is my experience that I have had several times where merging/branching has caused a repo to “break” What do you mean? Like you resolve the conflict correctly and git stops working? Stops working how? That sounds very strange, and anything else just seems like PEBKAC.
- eru 3y ago
  I wouldn't go so far as the term PEBKAC. It's true that git does not 'break' from a merge; but merge conflicts (and rebase conflicts) can still be frustrating to resolve for ordinary users. And after things get too frustrating, they often do really random stuff that then might accidentally break the repo for real, or at least get it into a state where they don't have enough knowledge to recover. Git's underlying data model is fine, but the user interface can be quite lacking. For example, 'git checkout' is a mess of almost unrelated functionality thrown together under one command. I think the idea behind 'git switch' is a good one, and git could benefit from a complete overhaul of its user interface. Well, at least if you ignore the switching costs. Old farts like you and me have gotten used to the quirks of the bad old interface, and learned all the barely coherent options to 'git reset'.
aliher1911 3y ago
For me git reflog was always a lifesaver when a complicated rebase or merge fails. You can always checkout previous SHA and then just return your HEAD to pre screw-up state. In case of remote repo that already ended up "broken" you can still force push to those branches, but others will have to discard theirs. Otherwise you never force push to anything shared.

jayshua 3y ago

What does a broken repo look like? What does broken mean here?

appplication 3y ago

Git could be a lot better in a lot of ways, particularly from a developer experience perspective. I’m a little surprised we haven’t seen a meaningful successor. One example is how git will deceive you and tell you you’re up to date with your remote (e.g. origin/main). What it means is that your local branch is up to date with its local concept of remote, and makes no statement guarantees about the actual state of the remote. Which is really a nonsense concept that does not need to exist. Similarly the whole concept of needing to specify “origin” at all is a bit bonkers and does no favors. Why is it that I can pull from a remote branch, commit some changes, run ‘git push’ and git has no idea what branch I want to push to. Another example: if main is a protected branch, don’t let me accidentally commit to it locally. I could keep going with the examples but I won’t. And yeah you can forgive all this by quibbling that git was written in a time when internet access was not ubiquitous, and of course all these decisions make sense because x, y, or z advanced edge case for advanced users only, and I’m a shitty engineer because all of this complexity secretly makes my life better and I’m just too simpleminded to appreciate it. Really though, if you rewrote git from a principles first approach (with developer experience being one of those principles), it certainly would not look like how it looks today. There is too much complexity, too many ways to do things, and too many bad decisions around defaults. Treat it like a proper distributed system, perhaps even backed by a real database. It’s not special because the data is code. The fact that it’s treated as such is the reason it feels so weird.

TylerE 3y ago
Blame the Linus Torvalds personality cult. Only way that terrible UX got traction in the first place. If anyone OTHER than Linus had written it, it would have been mocked, and deservedly so.
- appplication 3y ago
  Yeah, I originally had some Linus snark in there but deleted it. My above comment is being rapidly downvoted though, which is in some sense validating.
- Yodel0914 3y ago
  That's a pretty big claim. Git solved real problems at the time in a novel and extremely useful way. Coming from SVN (or god forbid VSS), the power and flexibility of git more than made up for its difficulty to grasp. Why it "won" over alternatives with cleaner UX (eg Hg) is a different question, and I think has a lot to do with github.
  - spaniard89277 3y ago
    Git may solve real problems but honestly, it's a PITA to use. Just for basic tasks needs quite a lot time sink to understand what's going on and what do you need to do. It gets in the way of the workflow IMO.
  - TylerE 3y ago
    Mercurial came out essentially simultaneously, solved the same problems, with a much more coherent UX.
    - Yodel0914 3y ago
      Early on, I was definitely a proponent for hg over git. I assumed it would at the very least remain a peer, given how much more sane the UX is. I was wrong though, and I don't think it's just because of github. Named branches being baked in turned out to actually be a real pain in mercurial. Sure, you can use bookmarks (and we did) but starts to quickly feel like you're swimming against the current.

Yodel0914 3y ago

I've been using git for I guess 15 years, on a variety of server platforms (github, atlassian, MS devops, plain ssh) and branching models, with teams of various sizes, and I've never had a repo "break". Branching and merging is what git is amazing at. The worse thing I've had happen is that someone was lazy when merging and just did a "take mine" on 100s of files, thinking that they'd do a "proper" merge later. Of course git doesn't work like that and their lazy merge had to unwound very carefully.

nonethewiser 3y ago

> It is my experience that I have had several times where merging/branching has caused a repo to “break” What do you mean? Like you resolve the conflict correctly and git stops working? Stops working how? That sounds very strange, and anything else just seems like PEBKAC.

eru 3y ago
I wouldn't go so far as the term PEBKAC. It's true that git does not 'break' from a merge; but merge conflicts (and rebase conflicts) can still be frustrating to resolve for ordinary users. And after things get too frustrating, they often do really random stuff that then might accidentally break the repo for real, or at least get it into a state where they don't have enough knowledge to recover. Git's underlying data model is fine, but the user interface can be quite lacking. For example, 'git checkout' is a mess of almost unrelated functionality thrown together under one command. I think the idea behind 'git switch' is a good one, and git could benefit from a complete overhaul of its user interface. Well, at least if you ignore the switching costs. Old farts like you and me have gotten used to the quirks of the bad old interface, and learned all the barely coherent options to 'git reset'.

aliher1911 3y ago

For me git reflog was always a lifesaver when a complicated rebase or merge fails. You can always checkout previous SHA and then just return your HEAD to pre screw-up state. In case of remote repo that already ended up "broken" you can still force push to those branches, but others will have to discard theirs. Otherwise you never force push to anything shared.