3 ms·

> Git is very easy to fuck up even during normal use (multiple people working on a software). I disagree that git design is responsible for this. If you have e

> Git is very easy to fuck up even during normal use (multiple people working on a software). I disagree that git design is responsible for this. If you have enough people doing something, especially when they all have different subsets of knowledge about the tool they're using. The chance someone will do something incompatible with everyone else rises. Git is clearly more complex than a saw, but give one to enough people who don't understand how to fell a tree, and ask them to build you a deck, oh and you're not allowed to talk to eachother. Something's gonna go badly. > Just because some people wanted a feature, doesn't mean I agree with their estimation of risk/reward. The risk being destroying couple days of other people's work. We were really close one time, didn't happen because my local copy was not yet synced. There's a story here, that I'm interested to hear. But git was kinda designed to avoid this exact thing. There's a reason that your local copy is 100% complete by default. Which means if you really came close to losing a lot of work. All of you were going out of your way to use git in a very not normal way.

Const-me 6y ago
> git design is responsible for this Design of the VCS is almost fine. "Almost" because I would prefer to track renames, but I can live without that. The CLI is horrible. > I'm interested to hear Someone used wrong command-line switch, and the merge commit was made in wrong way, destroying changes made in other branch. Then feature branch was deleted I think. I don't know or care who did that or what was the command-line switch, the point is, the thing is too fragile. People aren't perfect, they make mistakes. Good interfaces are designed in a specific way, to reduce the probability and consequences of these mistakes. In some areas like flight control I think there're even laws about that.
- grayhatter 6y ago
  What you described can't happen. If you merge one branch into another, both branches must exist in the repo. Deleting the feature branch following a merge, wouldn't delete the commits it contained. But even if that weren't the case. That means multiple people would have needed to all delete their feature branch without checking the code they wrote was merged and working. rm can delete code too, would you blame rm for having a confusing interface you just couldn't understand? Come to think about it, git does warn you when you tried to delete a branch that's not merged into any other branch.
  - Const-me 6y ago
    > That means multiple people would have needed to all delete their feature branch That switch might have done something about rewriting history. Or maybe it was rebase, I never do either of these things. Multiple people (except me) have synchronized after that happened. If interested how we fixed — I’ve copy-pasted couple commands from a chat, sent by a co-worker who knows more about git. These commands pushed my local branch under a new name, then people managed to sort it out with a merge.

Const-me 6y ago

> git design is responsible for this Design of the VCS is almost fine. "Almost" because I would prefer to track renames, but I can live without that. The CLI is horrible. > I'm interested to hear Someone used wrong command-line switch, and the merge commit was made in wrong way, destroying changes made in other branch. Then feature branch was deleted I think. I don't know or care who did that or what was the command-line switch, the point is, the thing is too fragile. People aren't perfect, they make mistakes. Good interfaces are designed in a specific way, to reduce the probability and consequences of these mistakes. In some areas like flight control I think there're even laws about that.

grayhatter 6y ago
What you described can't happen. If you merge one branch into another, both branches must exist in the repo. Deleting the feature branch following a merge, wouldn't delete the commits it contained. But even if that weren't the case. That means multiple people would have needed to all delete their feature branch without checking the code they wrote was merged and working. rm can delete code too, would you blame rm for having a confusing interface you just couldn't understand? Come to think about it, git does warn you when you tried to delete a branch that's not merged into any other branch.
- Const-me 6y ago
  > That means multiple people would have needed to all delete their feature branch That switch might have done something about rewriting history. Or maybe it was rebase, I never do either of these things. Multiple people (except me) have synchronized after that happened. If interested how we fixed — I’ve copy-pasted couple commands from a chat, sent by a co-worker who knows more about git. These commands pushed my local branch under a new name, then people managed to sort it out with a merge.