3 ms·

"I didn't mean to imply you personally are stupid." You implied I wasn't using my brain when using git. What did you want to imply with that if not stupidity?

by phaylon 16y ago

"I didn't mean to imply you personally are stupid." You implied I wasn't using my brain when using git. What did you want to imply with that if not stupidity? "Just that 'one' wanting to use git should effectively concede that it gives you the tools to cut off your hands if that's what you're aiming to do." Not sure I get that. I need to use git, so it's my fault? The thing about a mistake is that I wasn't aiming to do it. "If the rotating blades are meant to be used to amputate limbs and to cut logs in half - then yes, I'd say if you are trying to cut a log in half you shouldn't put your arm in it." Who would build such a thing? And even further, who would build a machine with 100 buttons, two of which look exactly the same, but one cuts wood, one cuts of your arm. What is to gain by having a destructive file operation and a non-destructive branch operation have the same name? Why do people seem to feel hurt when people suggest to name them separately?

thenduks 16y ago
What is to gain by having a destructive file operation and a non-destructive branch operation have the same name? Why do people seem to feel hurt when people suggest to name them separately? Because they are both the semantically correct name for the operation. Check out a file, overwriting my local unstaged changes. Or checkout an entirely new working copy from the point referred to by a branch. I don't feel hurt that you suggest it, though. In fact I mentioned in another comment that I always thought `git branch` could do the switching itself rather than checkout... I just don't think it's a problem. I know I'm working with a file or a branch, so I just know what will happen. It doesn't matter that the name is the same since it's function depends on context.
- phaylon 16y ago
  "Check out a file, overwriting my local unstaged changes. Or checkout an entirely new working copy from the point referred to by a branch." Well, of course they both seem the same if you use the word "checkout" in the explanation for "checkout." But "rolling back changes in a file" and "switching the current branch I'm developing in" aren't that close anymore. The word itself might mean multiple things, but that doesn't imply it's a good idea to use it in both meanings. "In fact I mentioned in another comment that I always thought `git branch` could do the switching itself rather than checkout... I just don't think it's a problem. I know I'm working with a file or a branch, so I just know what will happen." But evidently there are people who do think it's a problem. Also, the argumentation is that this would prevent mistakes from being destructive. When you know what you want to do, and it does it, it's not a mistake. When you want to do one thing, but the other one happens for any reason (bash completion was one of the mentioned ones) you don't know it. "It doesn't matter that the name is the same since it's function depends on context." It depends on the type of its argument. A simple "git checkout foo" is indistinguishable. I'm just a bit astounded by the amount of contra to this simple proposal to an existent problem.