4 ms·

>I'm unable to fathom the notion that if a computer doesn't work the way people want, the answer is for people to adapt to the computer. You don't understand b

by jayd16 6y ago

>I'm unable to fathom the notion that if a computer doesn't work the way people want, the answer is for people to adapt to the computer. You don't understand because you think you're fighting computers but you're actually at odds with other human's desires. If I pull your code, even if it was a mistake I don't want you to later rip the rug out from me and force me to figure out what happened from the history you deleted. You can easily change the history technologically. You just force push what you want. The issue is that is usually disabled because it causes a lot of problems for everyone else on the team.

wpietri 6y ago
That's a plausible reason, but it's definitely not what the person I was responding to said. "There are user reasons that won't work," is a very different answer than scoffing that the person asking the question just doesn't understand the underlying technology. I also don't think what you said is necessarily true. If person A has pushed and nobody else has pulled, then for most situations there's no reason to prevent A from un-pushing. Even if person B has pulled, a propagating un-push might well be what they want. I generally would. There are certainly some cases where B might not want that, but given that undoability is a has become a strong user expectation, I don't have particular reason to believe that balancing users needs would come out in favor of the current behavior.
- jayd16 6y ago
  >I don't have particular reason to believe that balancing users needs would come out in favor of the current behavior. Gitlab and Github (rightfully imo) came to this behavior. It was not random and is not the default git behavior which is to just allow the force push and all the chaos afterward. If you don't like it, mark your master branches as unprotected. However, there's clear reasons for the current defaults.
  - horsawlarway 6y ago
    It's ok, I'm not really convinced the poster above you actually understands how distributed systems work. They seem entirely stuck in the assumption that there's a more powerful entity in the relationship that can arbitrate interactions between individuals.
    - a1369209993 6y ago
      Technically, I think their problem is assuming that it's acceptable for there to be such a entity, not that one necessarily exists. And then misinterpreting/misrepresenting git's semi-intentional exclusion of such a entity as a bug when in fact it's a feature.
      - rakoo 6y ago
        They don't think it's a bug, they think it's something that is desirable (and git might not be the right tool for the job)
      - wpietri 6y ago
        I'm not sure that that such an entity is truly necessary to get a lot of the functionality. However, in the case of git, I'd guess 95% or more of users in effect do have a such an entity. Github is $7.5 billion worth of proof that most people are cool with effectively centralized source code management.

by jayd16 6y ago

wpietri 6y ago

That's a plausible reason, but it's definitely not what the person I was responding to said. "There are user reasons that won't work," is a very different answer than scoffing that the person asking the question just doesn't understand the underlying technology. I also don't think what you said is necessarily true. If person A has pushed and nobody else has pulled, then for most situations there's no reason to prevent A from un-pushing. Even if person B has pulled, a propagating un-push might well be what they want. I generally would. There are certainly some cases where B might not want that, but given that undoability is a has become a strong user expectation, I don't have particular reason to believe that balancing users needs would come out in favor of the current behavior.

jayd16 6y ago
>I don't have particular reason to believe that balancing users needs would come out in favor of the current behavior. Gitlab and Github (rightfully imo) came to this behavior. It was not random and is not the default git behavior which is to just allow the force push and all the chaos afterward. If you don't like it, mark your master branches as unprotected. However, there's clear reasons for the current defaults.
- horsawlarway 6y ago
  It's ok, I'm not really convinced the poster above you actually understands how distributed systems work. They seem entirely stuck in the assumption that there's a more powerful entity in the relationship that can arbitrate interactions between individuals.
  - a1369209993 6y ago
    Technically, I think their problem is assuming that it's acceptable for there to be such a entity, not that one necessarily exists. And then misinterpreting/misrepresenting git's semi-intentional exclusion of such a entity as a bug when in fact it's a feature.
    - rakoo 6y ago
      They don't think it's a bug, they think it's something that is desirable (and git might not be the right tool for the job)
    - wpietri 6y ago
      I'm not sure that that such an entity is truly necessary to get a lot of the functionality. However, in the case of git, I'd guess 95% or more of users in effect do have a such an entity. Github is $7.5 billion worth of proof that most people are cool with effectively centralized source code management.