5 ms·

I think git gets a bad rep because no one can agree how to use it. GitHub PRs vs pushing a branch, rebase vs merge are just two examples of tools that do ident

I think git gets a bad rep because no one can agree how to use it. GitHub PRs vs pushing a branch, rebase vs merge are just two examples of tools that do identical things in fundamentally different ways. And the problem is none of them are wrong. Rebasing minor commits simplifies unnecessary complexity in your history. Merging preserves what actually happened which can provide insight into why changes occurred. Of course reverse merges are the worst but that is a can of worms... When pushing to a branch you can never force push but you always force push a PR branch... Hell sometimes the easiest things create unsolvable rifts. I know of the main repo as origin and fork for my fork. Some have learned that the main repo is upstream and origin is your fork. Neither is necessarily wrong but good luck being clear when origin can refer to two locations with such extreme use cases.

ozim 3y ago
To paraphrase Bjarne Stroustrup, there are only two kinds of version control systems: the ones people complain about and the ones nobody uses.
- jorvi 3y ago
  Reminds me of what Bungie said in one of their GDCs. They don’t mind it (too much) if people get heated on their forum or subreddit, because people who care about Destiny are the ones that get worked up. It’s when most stop complaining or praising that they get worried, because it means apathy has set in.
  - samtho 3y ago
    This is a bit of wisdom that is easy to miss when you are developing a product. When people are getting worked about something and are very vocal, positive or negative, it means they care in some way. Instead of going into the doom spiral of “nobody likes what I’m building,” you can reframe it to be, “people are very passionate about what I’m building,” which is a better way to start the discussion of how to make what you have better. The opposite of love is not hate, it’s apathy.
  - worrycue 3y ago
    YoshiP director/producer of FFXIV from Square Enix said the same thing. "3. Learn to listen and adapt. A complaint is worth twice a compliment. The silent always leave first. If citizens are complaining, it means they still care."
- tialaramex 3y ago
  It's very much a "glass half full" perspective, which gets tiresome from somebody like Bjarne who is very resistant to the idea that he's made mistakes. It excuses lots of bad mistakes because hey, if people really felt that way they wouldn't use C++ right? But of course increasingly they aren't using C++ because it sucks, which is why they were complaining. Unlike C++, Git has put considerable work into responding to complaints, understanding that while yes, they wouldn't complain if they didn't use it, they also wouldn't complain if there weren't so many things to complain about. Lots of things we use every day don't get many complaints because there's nothing much wrong with them. Even the brutal Git command line is less hostile today than it was originally.
  - Guvante 3y ago
    I feel like you are being a bit unfair to Bjarne to to my knowledge isn't so much saying "we didn't make mistakes" as much as "we didn't make mistakes we should fix". C++ is the juggernaut it is because it just works. Your antient C++ codebase doesn't need many changes to get up to date on a language level. That doesn't mean it is painless to update toolchains but it does mean that the language isn't making that pain worse. As part of maintaining this the bar for breaking old code isn't "we shouldn't have done that" or "we wouldn't have don't that" but something more like "almost all code using this is wrong anyway". Most critiques of C++ do not raise to that level and so aren't fundamentally needing to be fixed.
    - tialaramex 3y ago
      Bjarne is quite happy to admit that we made mistakes, but that wasn't my criticism was it? I'm saying that Bjarne doesn't like to admit that Bjarne made mistakes.
      - Guvante 3y ago
        You can't be vague and make your point here. I explained a category of "mistakes" and you simply repeated your point. To be clear my point wasn't about who made the mistake but that some categories of mistake aren't fixable. Oftentimes people conflate "don't change it" with "it wasn't a mistake". Found an "I made a mistake" that is very explicitly self owned. Finding counterfactuals is nearly impossible so going to leave it at that without more specificity. > Unified function call: The notational distinction between x.f(y) and f(x,y) comes from the flawed OO notion that there always is a single most important object for an operation. I made a mistake adopting that. It was a shallow understanding at the time (but extremely fashionable). Even then, I pointed to sqrt(2) and x+y as examples of problems caused by that view. With generic programming, the x.f(y) vs. f(x,y) distinction becomes a library design and usage issue (an inflexibility). With concepts, such problems get formalized. Again, the issues and solutions go back decades. Allowing virtual arguments for f(x,y,z) gives us multimethods.
eru 3y ago
It's important to distinguish between 'local disagreements' and 'social disagreements'. The former are things that don't affect anyone else. Eg your co-workers don't care if you your remotes 'origin' and 'upstream', or 'fork' and 'origin'. The latter are things you need to coordinate on with other people. Eg how you want your git history to look like in the end.
- Guvante 3y ago
  But my point is even the social disagreements are only social for your repo. For the entirety of git they are local disagreements.
  - eru 3y ago
    For your point, I would introduce another conceptual level. Perhaps named, 'local', 'social per repo', and 'global'. Squishing 'local' and 'social per repo' sweeps away on important distinction, IMHO.
tester756 3y ago
git gets bad rep because its cli is a terrible mess if apple designed git's cli it'd be bilion times better from ux perspective while only 10% less powerful I guess
- deleted 3y ago
  [deleted]
- booleandilemma 3y ago
  Would their git provide file system access?
  - gumby 3y ago
    What a perfect comment: it’s impossible to conclusively declare it snark (unwelcome in HN comments) or a simple observation of fact (desired in HN comments). Shakes head: oh Apple, can’t live with you, can’t live without you.
- masklinn 3y ago
  Eh. Apple’s cli utilities are hot garbage, and with some of the poorest documentation you can find when they’re at all documented. As bad as git is, and god knows it’s bad, launchctl is in an other galaxy of unusability.
  - maccard 3y ago
    At least launchctl is usable as a cli. Look at the xcode command line tools, in particular try to sign a bundle from the command line.
- eitland 3y ago
  > if apple designed git's cli it'd be bilion times better from ux perspective while only 10% less powerful I guess Why then does every dev I am aware of who use Apple start by installing Homebrew? Also, you are talking about the same Apple that has a menu system that closes the menu if you click at a submenu? I mean, it breaks at least two reasonable assumptions: - clicking on a branch node would work on the branch like clicking on a leaf node affects the leaf - clicking the menu works like everywhere else Or the same Apple UX where, if I opened a dialog in my browser I cannot use the same browser to look up in the wiki where on the file server I am supposed to find a certain file I am supposed to upload? Or the same Apple UX where there is a different shortcut depending on whether I want to switch between windows of the same app or windows from different apps? The same Apple UX where I had to learn from application to application which features were in the menu and which were hidden under one or another gear icon? That said, I am considering another for my next laptop. But their UX is well and truly overrated IMNSHO.
Sterm 3y ago
[flagged]
phamilton 3y ago
A philosophy that has helped me: Do what makes sense for your immediate goal and then reassess and adapt. In practice, I actively rebase my commits in a PR with the sole focus of "What will make this easiest to review?". Then, once the review is completely I ask "What will make this easiest to operate and understand in the future?" I might squash everything together, or I might restructure into independently deployable pieces to facilitate rollback. The point is that all these things might have different needs and it's ok to do different things at different times. But that's requires a little more judgement from individuals and is difficult to teach and enforce across larger teams.

ozim 3y ago

To paraphrase Bjarne Stroustrup, there are only two kinds of version control systems: the ones people complain about and the ones nobody uses.

jorvi 3y ago
Reminds me of what Bungie said in one of their GDCs. They don’t mind it (too much) if people get heated on their forum or subreddit, because people who care about Destiny are the ones that get worked up. It’s when most stop complaining or praising that they get worried, because it means apathy has set in.
- samtho 3y ago
  This is a bit of wisdom that is easy to miss when you are developing a product. When people are getting worked about something and are very vocal, positive or negative, it means they care in some way. Instead of going into the doom spiral of “nobody likes what I’m building,” you can reframe it to be, “people are very passionate about what I’m building,” which is a better way to start the discussion of how to make what you have better. The opposite of love is not hate, it’s apathy.
- worrycue 3y ago
  YoshiP director/producer of FFXIV from Square Enix said the same thing. "3. Learn to listen and adapt. A complaint is worth twice a compliment. The silent always leave first. If citizens are complaining, it means they still care."
tialaramex 3y ago
It's very much a "glass half full" perspective, which gets tiresome from somebody like Bjarne who is very resistant to the idea that he's made mistakes. It excuses lots of bad mistakes because hey, if people really felt that way they wouldn't use C++ right? But of course increasingly they aren't using C++ because it sucks, which is why they were complaining. Unlike C++, Git has put considerable work into responding to complaints, understanding that while yes, they wouldn't complain if they didn't use it, they also wouldn't complain if there weren't so many things to complain about. Lots of things we use every day don't get many complaints because there's nothing much wrong with them. Even the brutal Git command line is less hostile today than it was originally.
- Guvante 3y ago
  I feel like you are being a bit unfair to Bjarne to to my knowledge isn't so much saying "we didn't make mistakes" as much as "we didn't make mistakes we should fix". C++ is the juggernaut it is because it just works. Your antient C++ codebase doesn't need many changes to get up to date on a language level. That doesn't mean it is painless to update toolchains but it does mean that the language isn't making that pain worse. As part of maintaining this the bar for breaking old code isn't "we shouldn't have done that" or "we wouldn't have don't that" but something more like "almost all code using this is wrong anyway". Most critiques of C++ do not raise to that level and so aren't fundamentally needing to be fixed.
  - tialaramex 3y ago
    Bjarne is quite happy to admit that we made mistakes, but that wasn't my criticism was it? I'm saying that Bjarne doesn't like to admit that Bjarne made mistakes.
    - Guvante 3y ago
      You can't be vague and make your point here. I explained a category of "mistakes" and you simply repeated your point. To be clear my point wasn't about who made the mistake but that some categories of mistake aren't fixable. Oftentimes people conflate "don't change it" with "it wasn't a mistake". Found an "I made a mistake" that is very explicitly self owned. Finding counterfactuals is nearly impossible so going to leave it at that without more specificity. > Unified function call: The notational distinction between x.f(y) and f(x,y) comes from the flawed OO notion that there always is a single most important object for an operation. I made a mistake adopting that. It was a shallow understanding at the time (but extremely fashionable). Even then, I pointed to sqrt(2) and x+y as examples of problems caused by that view. With generic programming, the x.f(y) vs. f(x,y) distinction becomes a library design and usage issue (an inflexibility). With concepts, such problems get formalized. Again, the issues and solutions go back decades. Allowing virtual arguments for f(x,y,z) gives us multimethods.

eru 3y ago

It's important to distinguish between 'local disagreements' and 'social disagreements'. The former are things that don't affect anyone else. Eg your co-workers don't care if you your remotes 'origin' and 'upstream', or 'fork' and 'origin'. The latter are things you need to coordinate on with other people. Eg how you want your git history to look like in the end.

Guvante 3y ago
But my point is even the social disagreements are only social for your repo. For the entirety of git they are local disagreements.
- eru 3y ago
  For your point, I would introduce another conceptual level. Perhaps named, 'local', 'social per repo', and 'global'. Squishing 'local' and 'social per repo' sweeps away on important distinction, IMHO.

tester756 3y ago

git gets bad rep because its cli is a terrible mess if apple designed git's cli it'd be bilion times better from ux perspective while only 10% less powerful I guess

deleted 3y ago
[deleted]
booleandilemma 3y ago
Would their git provide file system access?
- gumby 3y ago
  What a perfect comment: it’s impossible to conclusively declare it snark (unwelcome in HN comments) or a simple observation of fact (desired in HN comments). Shakes head: oh Apple, can’t live with you, can’t live without you.
masklinn 3y ago
Eh. Apple’s cli utilities are hot garbage, and with some of the poorest documentation you can find when they’re at all documented. As bad as git is, and god knows it’s bad, launchctl is in an other galaxy of unusability.
- maccard 3y ago
  At least launchctl is usable as a cli. Look at the xcode command line tools, in particular try to sign a bundle from the command line.
eitland 3y ago
> if apple designed git's cli it'd be bilion times better from ux perspective while only 10% less powerful I guess Why then does every dev I am aware of who use Apple start by installing Homebrew? Also, you are talking about the same Apple that has a menu system that closes the menu if you click at a submenu? I mean, it breaks at least two reasonable assumptions: - clicking on a branch node would work on the branch like clicking on a leaf node affects the leaf - clicking the menu works like everywhere else Or the same Apple UX where, if I opened a dialog in my browser I cannot use the same browser to look up in the wiki where on the file server I am supposed to find a certain file I am supposed to upload? Or the same Apple UX where there is a different shortcut depending on whether I want to switch between windows of the same app or windows from different apps? The same Apple UX where I had to learn from application to application which features were in the menu and which were hidden under one or another gear icon? That said, I am considering another for my next laptop. But their UX is well and truly overrated IMNSHO.

Sterm 3y ago

[flagged]

phamilton 3y ago

A philosophy that has helped me: Do what makes sense for your immediate goal and then reassess and adapt. In practice, I actively rebase my commits in a PR with the sole focus of "What will make this easiest to review?". Then, once the review is completely I ask "What will make this easiest to operate and understand in the future?" I might squash everything together, or I might restructure into independently deployable pieces to facilitate rollback. The point is that all these things might have different needs and it's ok to do different things at different times. But that's requires a little more judgement from individuals and is difficult to teach and enforce across larger teams.